> know). This results in a severe pressure on port availability as
> closed ports go into time_wait for a period of 60 seconds (system

We experienced this ages back, but in relation to IMAP connections rather
than web ones. A number of IMAP clients are really bad at
disconnecting/reconnecting frequently, causing the same TIME_WAIT problem.

Two solutions we used that both work:
1. On linux, enable tcp_tw_reuse
2. Bind to multiple IPs and distribute connections across them

> achieve the same reduction in apache processes if I simply turn off
> keepalive or reduce it to a very low value (say 1 second). Essentially
> with keepalive off, apache will behave exactly the same way in
> handling clients directly as having nginx in front.

No. You're assuming that your clients are fast and on a local network and
can push/pull data effectively "instantly".

The reality is that clients are at some distance from your server, so
there's time for them to send the requests (especially any large POST ones),
and to read back the results. That's what nginx will hide, because it will
wait until the entire request is available before connecting and pushing it
to apache, and then it will slurp back the entire result and close the
apache connection, and then trickle it to the client, freeing the apache
process for another request. Even with keepalive off, this is quite
different to just having apache directly accept the requests, and with keep
alive on, it's vastly different.

So the point of nginx as a proxy is that it handles the keep alives +
buffering in both directions, which reduces the number of actual apache
processes required to only those actually doing any work, they never have to
handle client network latencies/keepalives.

Rob