| 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
|
), and now
), and now