I am using Nginx to serve static content, and Haproxy to proxy requests to multiple Apache2 backends discovered via Zookeeper.
Nginx -> Haproxy -> Apache2
According to the official Nginx website, it aggregates long-keepalive connections on their way to back ends like this, reducing the number of connections to a minimum.
Therefore, my assumption was that Nginx is where the Keepalive has to be on, and set to a bigger value, in my case "keepalive_timeout 600";
It then hits Haproxy on a local port, with the "httpclose" option on for the Apache backend:
option httpclose Enable or disable passive HTTP connection closing
HAProxy does not yet support the HTTP keep-alive mode. So by default, if a client communicates with a server in this mode, it will only analyze, log, and process the first request of each connection. To workaround this limitation, it is possible to specify "option httpclose". It will check if a "Connection: close" header is already set in each direction, and will add one if missing. Each end should react to this by actively closing the TCP connection after each transfer, thus resulting in a switch to the HTTP close mode. Any "Connection" header different from "close" will also be removed.
This option may be set both in a frontend and in a backend. It is enabled if at least one of the frontend or backend holding a connection has it enabled.
Haproxy then routes connections to Apache2.
So, my assumption is that in this case I will have to turn Apache's keepalive off, since a) Nginx aggregates connections b) Haproxy closes them.
Am I correct in my reasoning and what would be a better way to optimize for keepalive in a chain like this one?
Update: This ServerFault topic notes that it is more beneficial to remove keepalive from Haproxy as well (and thus get rid of httpclose, I presume), as the latency between Haproxy and Apache would be too low to justify removing the handshake anyway.
So that leaves us with Nginx (KA) -> Haproxy (no KA) -> Apache (no KA)
Is that a better option?
