Haven't gone into production yet, but plan to soon... just been
testing and planning initial configuration and tuning sizes... plan
to start testing of haproxy in production with just one app server
within a week, and assuming all goes well, will order and add
additional app servers soon.
If I use "option hhttpclose", it kills persistent connections. Persistent connections would generally be good for performance. Plus, it helps from collecting tons and tons of TIME_WAIT connections....
I would like some connection throttling as right now the backend is slightly overworked. However I am worried that because persistent connections can be open for awhile with no activity, it can make the maxconn pointless. Too high, and doesn't protect the server, and too low and a bunch of idle sessions can essentially hog the web server.
Obviously I have no real experience with load balancers yet (just been reading off the internet, etc), and the my real problem is in the back-end / not enough application servers, so this may be a totally pointless idea.... Would be nice to have two queues (or probably just two server entries pointing to the same server), where httpclose is forced on only one of the queues. Is this possible? (ie: placing option commands between server lines to turn on/off httpclose for different server entries? Don't recall seeing configurations like that in any of the examples). This is assuming that a client wouldn't get confused is some of it's connections might be allowed to be persistent and some might not.
Ideally, as done in some load balancers, you can do connection pooling where it can have persistent connections between balancer and server, even if not persistent between client and balancer. That would be a major change... and plans for that in the future? Received on 2007/10/03 18:38
This archive was generated by hypermail 2.2.0 : 2007/11/04 19:21 CET