Phillip Pearson - web + electronics notes

tech notes and web hackery from a new zealander who was vaguely useful on the web back in 2002 (see: python community server, the blogging ecosystem, the new zealand coffee review, the internet topic exchange).


Slowly learning how to write a reverse proxy

OK, yesterday's reverse proxy was a success in that it took the load off Apache - Apache NEVER needs to spawn more than 5-6 servers any more, which is awesome.

However, it had some problems of its own:

1. If a client sent SOMETHING, but not a complete request, then stopped, it would never time out. So now it kills client connections that don't send anything for 60 seconds when they should be sending HTTP headers or POST data to the server.

2. If a client stopped RECEIVING, it would never time out. It seems that the clients timed themselves out, or the OS did something, though, so as well as an ever-growing list of "current" sessions inside the proxy, I ended up with the kernel keeping track of a lot of sockets in the CLOSE_WAIT state. So now it kills client connections that don't ack anything for 60 seconds.

Those two are OK now. The new problem is that it doesn't support HTTP keepalives, because I'm lazy, so I end up with thousands of sockets in the FIN_WAIT state(s). My server has a FIN_WAIT timeout of 60 seconds, which I hope will be good enough to keep this under control. Failing that, I'm going to have to get this thing to support persistent connections to the clients. I don't think I'll bother with keeping server connections persistent - I might as well just increase MinSpareClients in httpd.conf, as that will fix the main problem with that.

Fingers crossed now - let's see if it'll stay up for longer than 5 hours ...