This post originated from an RSS feed registered with Python Buzz
by Phillip Pearson.
Original Post: Slowly learning how to write a reverse proxy
Feed Title: Second p0st
Feed URL: http://www.myelin.co.nz/post/rss.xml
Feed Description: Tech notes and web hackery from the guy that brought you bzero, Python Community Server, the Blogging Ecosystem and the Internet Topic Exchange
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 ...
Previous Topic
