COUCHDB / MOCHIWEB: Effet négatif des connexions persistantes

Question

J'ai une configuration assez simple de Couchdb sur ma boîte menthe / Debian. My Java WebApp souffrait assez de longs retards sur la recherche de Couchdb, alors j'ai commencé à rechercher les causes.

EDIT : Le motif de requête est de nombreuses petites requêtes et de petits objets JSON (comme 300 octets haut / 1kbyle vers le bas).

Les décharges de Wireshark sont plutôt agréables, montrant principalement 3 à 5 millis. L'échantillonnage de cadre JVM m'a montré que le code de la prise (requêtes côté client sur le canapé) est quelque peu occupé, mais rien de remarquable. Ensuite, j'ai essayé de profiler de la même manière avec Apachebench et Oops: Je vois actuellement que la garde-vie introduit un délai de 39 ms stable sur des configurations non persistantes.

Est-ce que quelqu'un sait comment expliquer cela? Peut-être que des connexions persistantes augmentent la fenêtre de congestion sur la couche TCP, puis ralentissez-vous en raison de TCP_WAIT et de petites tailles de demande / de réponse, ou quelque chose comme ça? Si cette option (TCP_WAIT) est déjà allumée pour les connexions TCP de bouclage?

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"}

courir avec garder en vie, moyenne 40 millis par demande

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)

pas de garde et de voile - 1 ms par demande, surtout.

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)

D'accord, maintenant avec conservation, mais demandant également de fermer la connexion via l'en-tête HTTP. Aussi 1 ms par demande ou plus.

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)

Answer 1

Ouais, ceci est lié aux options de configuration de la prise TCP.Cette configuration désormait maintenant les trois cas à 1 ms par demande.

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

Voir ceci pour plus de détails: http://wiki.apache.org/couchdb/performance#network