CouchDB/MochiWeb: efecto negativo de las conexiones persistentes

Question

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

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

Los vertederos de Wireshark son bastante bonitos, y muestran principalmente entre 3 y 5 milisegundos de respuesta de solicitud y respuesta. 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 activarse esta opción (TCP_WAIT) 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 vivas, un 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 cada 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) 

Bien, ahora con keep-alive 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 de socket TCP. Esta configuración ahora niveló los tres casos a 1 ms por solicitud.

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

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