私のMint/DebianボックスでCouchDBを簡単にセットアップできました。私のJava WebアプリケーションはCouchDBを照会するのにかなり時間がかかるので、原因を追求し始めました。CouchDB/MochiWeb:永続的な接続による悪影響
EDIT:クエリパターンは多数の小さなクエリと小さなJSONオブジェクト(300バイトアップ/ 1KBダウンなど)です。
Wiresharkのダンプは、大体3〜5ミリ秒の要求応答の処理時間を示しています。 JVMのフレームサンプリングでは、ソケットコード(Couchへのクライアントサイドクエリ)はやや忙しいですが、何も目立っていませんでした。 ApacheBenchとoopsで同じことをプロファイルしようとしました。私は現在、キープアライブが非永続的な設定よりも39ms遅れて安定していることを確認しています。
誰でもこれを説明する方法を知っていますか?たぶん永続的な接続がTCPレイヤー上の輻輳ウィンドウを増やし、TCP_WAITや小さな要求/応答サイズなどのためにアイドル状態になることがありますか? このオプション(TCP_WAIT)はループバックtcp接続のためにオンになるべきですか?
[email protected] ~ $ uname -a
Linux mint 2.6.39-2-486 #1 Tue Jul 5 02:52:23 UTC 2011 i686 GNU/Linux
[email protected] ~ $ curl http://127.0.0.1:5984/
{"couchdb":"Welcome","version":"1.1.1"}
要求
[email protected] ~ $ 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)
なしキープアライブあたりアライブ、平均40ミリ秒を維持し、出来上がりで実行 - 1ミリ秒要求ごと、ほとんど。
さて、キープアライブをオンにして、httpヘッダー経由で接続を閉じるように依頼してください。要求あたり1ms程度です。
[email protected] ~ $ 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)
感謝を。私はすぐにノーディライを考えましたが、それが正しいかどうか、あるいはそれをどう確認するかは分かりませんでした。 – JasonSmith