3 ms·
I see you're using nginx as the reverse proxy. There seem to be a lot of options for reverse HTTP proxying - nginx, apache (mod_proxy), lighttpd, squid, etc. Wo
by pmjordan 17y ago
I see you're using nginx as the reverse proxy. There seem to be a lot of options for reverse HTTP proxying - nginx, apache (mod_proxy), lighttpd, squid, etc. Would you (and/or anyone else) mind talking about choosing the right one? I assume all of them support keeping connections to the backing servers alive to reduce the overhead from opening new TCP connections.
Apache seems overkill if it's not also serving up some of the pages, but other than that I'm a bit lost. I'm mainly after multiplexing requests to different server processes (some in VMs) based on Host: header and/or path. Applying gzip/deflate compression where the backing server doesn't support it would be nice too.
- noss 17y agoThere is no support in nginx to do keep-alive connections to backend servers. Placing nginx and the backend servers on the same LAN should make it less of an issue than high-latency frontend connections. The backend response will also be buffered in nginx until it has received it all before the front-end user is served the request.