Hi Benjamin, On Sun, Aug 29, 2010 at 05:47:38PM +0200, Benjamin Pineau wrote: > When one uses haproxy in front of name based virtual hosts - different > websites sharing the same IP:port -, it's hard to prevent one website > from sucking all available backend's and frontend's connexions slots. > > I tried several times but failed due to frontend maxconn also being a > limited resource, shared among all virtualhosts (we could prevent backend > exhaustion the ugly way, by copy-pasting an almost identical backend > definition for each website, but then connexions would probably pile > up enqueued in the frontend up to saturation). > > Now, the shinny new sticky-table features looks like we could approach > resource isolation. But I fail to grok that feature's sophistication, > and don't find any way to implement a counter to store and check the > number of active connexions per http hostname (or is it designed to > store only clients sources IP addresses via track-sc* ?).
It is *designed* to store anything, but right now only IP addresses are supported. The goal is that we can use it to track headers and such things. > The only way I can think of - but didn't tried yet - would be to define > a different backend for each site (albeit with the same servers, each > with maxconn < his real capacity), and filtering on frontend: Indeed, if you don't have too many host names, right now you'll have to have multiple backends even with the stick tables. So if your goal is to protect the frontend against backend abuses, your config is still the most suited for that task. If you have many many hosts and can't afford to have as many backends, then you'll have to wait for the stick table to be able to track headers. (...) > ps: I guess the doc should say "queue(backend) <integer>" instead of that? : > queue(frontend) <integer> > Returns the total number of queued connections of the designated backend, Ah good catch, thanks. Willy
