Willy Tarreau a écrit : > What could be possible would be to have two distinct frontends for siteA and > siteB, sharing the same backend containing servers configured with maxconn > 160. > Thus, any of siteA and siteB could make use of the 3*160, but the global limit > will still be 3*160. > > Then if you really want to prevent siteA or siteB from stealing all the > connections, you can still set a maxconn on the frontends, but then the > connections will be queued in the system.
Willy, thank you very much for taking time to answer with such clarity and precision! Even if not perfect, your solution looks better than my current LVS setup, where I came to dispatching most web sites' traffic on "total_nb_servers -1" and sometime to dedicate some servers for the most busy sites, which is far from your solution's fine granularity. On a totally different topic, those per server connexion limitation settings led me to think about my workload, which is probably a very typical apache + php one. We, LAMP sysadmins, are used to approach admission control by fixing hard, constants limits on the number of simultaneous connexions (very much "apache prefork mpm's MaxClient"). But with varyings workloads (varying on time of day, on popular web page of the moment, when images changes and clients cache are empty, when a rss feed is refreshed, ...) we get dynamically varying server capacities in term of number of simultaneous connexions they can handle. Sometime apache childs will spend much of their running time sleeping (waiting for user input, or for dns resolution, slowed by database connexion latency, serving static files to slow clients...). Then we can push lots of connexion to each server. But at other moments/in other situations the scripts may be cpu bound and actively running most of the time, and we shouldn't accept much more connexion than the number of server's cpu cores. Looks like haproxy healtchecking system may be of great value there (assuming stateless web servers, with no need for persistence) : - on each server, a high connexion admission limit - on each server, regularly generate a status page depending on actualy server's (and server's dependencies, like backend database load) available resources, marking the server "down" when we approach exhaustion. - minconn + optimistically high maxconn on haproxy config, per server - haproxy configured to healtcheck on server's generated status page This indeed changes the way haproxy would see resources exhaustion. Not sure how seeing all backend's servers as down instead of maxconn reached would affect connexion queueing smoothness, and if seeing a server down would shut down current connexions? Alternatively we can dynamically generate and reload haproxy config... So I'm on the way to script a dynamic status page enforcing per website limits when resources are tight, maybe I could achieve both QoS (per website connexions) and server's resources maximization ;)
