keepalive and workers

[Mansoor Peerbhoy]

| 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.
| 

>From my experience (fwiw), you shouldn't worry about the tcp handshakes, especially when all this chatter will take place on a lan. You should be more worried about the average turn around times that you will get per http request, when using keep-alive versus non-keepalive. (see below)


| 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.
| 


Ok, so if mod_wsgi is what I think it is (allowing python code to run in an nginx worker process), then the wsgi code is under no obligation to relinquish the processor once its code starts executing. For example, traditional NGINX module development forces a module developer to avoid blocking network calls, and to set up event handlers for socket read()/write()s.

On the other hand, if nginx worker process runs python code in its own process context (think embedded interpreter), then until the python code finishes executing, nginx worker process cannot interrupt it to go and serve some other pending http request.

Therefore, in this case, you would really be better off using non-keepalive connections. In that case, if the python code continues to run synchronously, then you are practically guaranteed that some other nginx worker process will take up your new http request.

However, you should also be worried about the serializiability of the your http requests from the app server standpoint.

For instance, if you have requests { R1, R2, R3, ... Rn } that must be executed, where the input of one request depends on the output of the other, then you anyway will have to wait till R1 finishes before you can do R2. In this case, you are better off using keep-alives for that subset of mutually dependent requests.

For requests which can be made even when the previous request has not finished, then you can use non-keepalives.

Hope I didn't confuse you :) -- of course, I may be completely at a tangent here, if mod_wsgi uses interprocess communication with nginx worker process (with a separate process executing application code), then you can win by using keepalives. 

M




| Thanks for all the input,
| 
| Mike
|