keepalive and workers

[Max Sevenfold]

>
> You said that I could omit unnecessary TCP handshakes and that's
> exactly what I had in mind. Do you have any idea if this would be a
> big performance gain? It's going to happen in a 1Gb LAN.

I think SSL exchanges keys not only in the beginning but every n seconds 
or every n bytes.

Max

Michał Jaszczyk wrote:
> Thanks for all the answers! I have some new questions though :).
>
> You said that I could omit unnecessary TCP handshakes and that's
> exactly what I had in mind. Do you have any idea if this would be a
> big performance gain? It's going to happen in a 1Gb LAN.
>
> Another issue is that my backend servers (i.e. the ones that my app
> server connects to) will be Nginx servers with mod_wsgi. Therefore I'm
> losing lots of asynchronousness, so I'd like to avoid a situation
> where all my app servers connect to the same worker in the backend
> server, because that would create a bottleneck.
>
> Thanks for all the input,
>
> Mike
>
> 2008/7/7 Mansoor Peerbhoy <mansoor at zimbra.com>:
>   
>> Hi Mike,
>> I didn't completely understand your setup, but answers to some of your questions:
>>
>> - If a connection is kept alive, is it handled by the same Nginx
>> worker when new requests come in?
>>
>> Yes, the worker process that is elected to serve a keep-alive HTTP connection will continue to serve all subsequent HTTP requests over that same connection
>>
>> - Will I have any performance gain if I keep connections from app
>> server to other servers instead of opening/closing them with every
>> request from a user?
>>
>> As Regards "App server to any other server" is concerned, in general, when you are using keep-alive, you should consider how the web server handles keep-alive connections. Some server models would tie down a worker process or thread to a particular connection, and as long as that connection is active (the connection in your case being keep-alive), then that will tie down the server thread, so keep-alive works best if there is a steady stream of web-traffic. If the traffic is sporadic (or in bursts), you may want to consider using Connection:close
>>
>> Regarding NGINX, if NGINX is at the server end, keep-alive or no keep-alive will not make much performance difference to NGINX, because NGINX worker processes handle requests "on-demand", i.e. in an asynchronous manner.
>>
>> NGINX workers do not fork or create new threads upon receipt of a new connection, they simply add the new connection (along with the requisite timeout) to their connection set, and go back to their main select/poll loop.
>>
>> When interesting events happen on the connection (such as HTTP request received, or POP/IMAP connection received), then NGINX workers process the necessary work required for that connection, and go back to their select() loops. So NGINX will not be affected very much by keep-alives versus non-keepalives.
>>
>> Your network, however is a separate issue. non-keepalive (default for HTTP/1.0) implies that the TCP handshake be completed for each HTTP request.
>>
>>
>> HTH
>> Mansoor
>>
>>
>>
>>
>> ----- Original Message -----
>> From: "Michał Jaszczyk" <jasiu85 at gmail.com>
>> To: nginx at sysoev.ru
>> Sent: Monday, July 7, 2008 4:00:05 PM GMT +05:30 Chennai, Kolkata, Mumbai, New Delhi
>> Subject: keepalive and workers
>>
>> Hi,
>>
>> I'm creating a website with Nginx and have some questions. When a user
>> comes with a request, my application server has to connect to many
>> other servers in order to create the response. Due to separation of
>> concerns pattern, application server and all other servers are
>> separate HTTP servers, each built with Nginx. Okay, so this is the
>> situation I'm in (hopefully my description was clear :) ), and now
>> come the questions:
>>
>> - Will I have any performance gain if I keep connections from app
>> server to other servers instead of opening/closing them with every
>> request from a user?
>>
>> - Can I set keepalive in Nginx to last forever?
>>
>> - If a connection is kept alive, is it handled by the same Nginx
>> worker when new requests come in?
>>
>> Regards,
>>
>> Mike
>>
>>
>>
>>