http - CouchDB/MochiWeb: efecto negativo de las conexiones persistentes

tcp profiling

Question

Tengo una configuración bastante sencilla de CouchDB en mi caja de Mint / Debian. Mi aplicación Java estaba sufriendo largas demoras al consultar CouchDB, así que comencé a buscar las causas.

EDITAR : El patrón de consulta es un montón de pequeñas consultas y pequeños objetos JSON (como 300 bytes arriba / 1Kbyte abajo).

Los vertederos de Wireshark son bastante buenos, y muestran una respuesta de solicitud de respuesta de entre 3 y 5 milisegundos. El muestreo de marco de JVM me mostró que el código del socket (consultas del lado del cliente al sofá) está algo ocupado, pero nada destacable. Luego traté de perfilar lo mismo con ApacheBench y oops: actualmente veo que keep-alive introduce una demora constante de 39 ms sobre las configuraciones no persistentes.

¿Alguien sabe cómo explicar esto? Tal vez las conexiones persistentes aumentan la ventana de congestión en la capa de TCP y luego están inactivas debido a TCP_WAIT y tamaños pequeños de solicitud / respuesta, o algo así? ¿Debería esta opción (TCP_WAIT) activarse alguna vez para las conexiones loopc 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"}

corriendo con mantener vivo, promedio de 40 millis por solicitud

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)

Sin keepalive, y listo - 1 ms por solicitud, en su mayoría.

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)

De acuerdo, ahora con keep-alive activado pero también pidiendo cerrar la conexión a través del encabezado http. También 1 ms por solicitud o más.

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

Sí, esto está relacionado con las opciones de configuración del zócalo tcp. Esta configuración ahora niveló los tres casos a 1 ms por solicitud.

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

Vea esto para más detalles: http://wiki.apache.org/couchdb/Performance#Network