7

Mint/Debian ボックスで CouchDB をかなり簡単にセットアップしました。私の Java Web アプリケーションは、CouchDB へのクエリでかなり長い遅延に悩まされていたので、その原因を探し始めました。

EDIT : クエリ パターンは、多数の小さなクエリと小さな JSON オブジェクト (上 300 バイト/下 1K バイトなど) です。

Wireshark のダンプは非常に優れており、ほとんどが 3 ～ 5 ミリ秒の要求と応答のターンアラウンドを示しています。JVM フレーム サンプリングでは、ソケット コード (Couch へのクライアント側のクエリ) が多少ビジーであることがわかりましたが、特に目立ったものはありませんでした。次に、ApacheBench と oops で同じことをプロファイリングしようとしました。現在、キープアライブは、非永続的なセットアップで安定した余分な 39 ミリ秒の遅延を導入していることがわかります。

誰もこれを説明する方法を知っていますか? 永続的な接続が TCP 層の輻輳ウィンドウを増加させ、TCP_WAIT や小さな要求/応答サイズなどのためにアイドル状態になっている可能性がありますか? このオプション (TCP_WAIT) は、ループバック tcp 接続に対してオンにする必要がありますか?

w@mint ~ $ uname -a
Linux mint 2.6.39-2-486 #1 Tue Jul 5 02:52:23 UTC 2011 i686 GNU/Linux
w@mint ~ $ curl http://127.0.0.1:5984/
{"couchdb":"Welcome","version":"1.1.1"}

キープアライブで実行、リクエストあたり平均 40 ミリ秒

w@mint ~ $ ab -n 1024 -c 1 -k http://127.0.0.1:5984/
>>>snip
Server Software:        CouchDB/1.1.1
Server Hostname:        127.0.0.1
Server Port:            5984

Document Path:          /
Document Length:        40 bytes

Concurrency Level:      1
Time taken for tests:   41.001 seconds
Complete requests:      1024
Failed requests:        0
Write errors:           0
Keep-Alive requests:    1024
Total transferred:      261120 bytes
HTML transferred:       40960 bytes
Requests per second:    24.98 [#/sec] (mean)
Time per request:       40.040 [ms] (mean)
Time per request:       40.040 [ms] (mean, across all concurrent requests)
Transfer rate:          6.22 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.0      0       0
Processing:     1   40   1.4     40      48
Waiting:        0    1   0.7      1       8
Total:          1   40   1.3     40      48

Percentage of the requests served within a certain time (ms)
  50%     40
>>>snip
  95%     40
  98%     41
  99%     44
 100%     48 (longest request)

キープアライブはなく、出来上がり - ほとんどの場合、リクエストごとに 1 ミリ秒。

w@mint ~ $ ab -n 1024 -c 1 http://127.0.0.1:5984/
>>>snip
Time taken for tests:   1.080 seconds
Complete requests:      1024
Failed requests:        0
Write errors:           0
Total transferred:      236544 bytes
HTML transferred:       40960 bytes
Requests per second:    948.15 [#/sec] (mean)
Time per request:       1.055 [ms] (mean)
Time per request:       1.055 [ms] (mean, across all concurrent requests)
Transfer rate:          213.89 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.0      0       0
Processing:     1    1   1.0      1      11
Waiting:        1    1   0.9      1      11
Total:          1    1   1.0      1      11

Percentage of the requests served within a certain time (ms)
  50%      1
>>>snip
  80%      1
  90%      2
  95%      3
  98%      5
  99%      6
 100%     11 (longest request)

さて、キープアライブをオンにしましたが、http ヘッダーを介して接続を閉じるように求めています。また、リクエストごとに1ミリ秒程度です。

w@mint ~ $ ab -n 1024 -c 1 -k -H 'Connection: close' http://127.0.0.1:5984/
>>>snip
Time taken for tests:   1.131 seconds
Complete requests:      1024
Failed requests:        0
Write errors:           0
Keep-Alive requests:    0
Total transferred:      236544 bytes
HTML transferred:       40960 bytes
Requests per second:    905.03 [#/sec] (mean)
Time per request:       1.105 [ms] (mean)
Time per request:       1.105 [ms] (mean, across all concurrent requests)
Transfer rate:          204.16 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.0      0       0
Processing:     1    1   1.2      1      14
Waiting:        0    1   1.1      1      13
Total:          1    1   1.2      1      14

Percentage of the requests served within a certain time (ms)
  50%      1
>>>snip
  80%      1
  90%      2
  95%      3
  98%      6
  99%      7
 100%     14 (longest request)
4

1 に答える 1

8

ええ、これは tcp ソケットのセットアップ オプションに関連しています。この構成により、リクエストあたり 1 ミリ秒で 3 つのケースすべてが横ばいになりました。

[httpd]
socket_options = [{nodelay, true}]

詳細については、 http ://wiki.apache.org/couchdb/Performance#Network を参照してください。

于 2012-01-24T21:04:05.643 に答える