Tôi có thiết lập khá đơn giản của CouchDB trên hộp Mint/Debian của tôi. Webapp Java của tôi đã bị trì hoãn khá lâu trong việc truy vấn CouchDB, vì vậy tôi bắt đầu tìm kiếm nguyên nhân.CouchDB/MochiWeb: tác động tiêu cực của các kết nối liên tục
EDIT: Mẫu truy vấn là rất nhiều truy vấn nhỏ và đối tượng JSON nhỏ (như 300 byte lên/1Kbyte xuống).
Bãi Wireshark khá đẹp, hiển thị chủ yếu là 3-5 millis yêu cầu phản hồi. Lấy mẫu khung JVM cho tôi thấy rằng mã socket (các truy vấn phía máy khách đến Couch) hơi bận, nhưng không có gì đáng chú ý. Sau đó, tôi đã cố gắng để hồ sơ tương tự với ApacheBench và oops: Tôi hiện đang thấy rằng giữ sống giới thiệu ổn định thêm 39ms thêm trên các thiết lập không liên tục.
Có ai biết cách giải thích điều này không? Có thể các kết nối liên tục làm tăng cửa sổ nghẽn trên lớp TCP và sau đó không hoạt động do TCP_WAIT và kích thước yêu cầu/phản hồi nhỏ, hoặc một cái gì đó tương tự? Có nên bật tùy chọn này (TCP_WAIT) cho các kết nối tcp lặp lại không?
[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"}
chạy với duy trì sự sống, trung bình 40 millis theo yêu cầu
[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)
Không keepalive, và thì đấy - 1 ms cho mỗi yêu cầu, chủ yếu.
[email protected] ~ $ 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)
Được rồi, hiện tại vẫn tiếp tục nhưng cũng yêu cầu đóng kết nối qua tiêu đề http. Ngoài ra 1 ms cho mỗi yêu cầu hoặc như vậy.
[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)
Cám ơn theo dõi. Tôi ngay lập tức nghĩ đến 'nodelay' nhưng tôi không chắc liệu đó là đúng hay cách xác nhận nó. – JasonSmith