On Fri, Apr 03, 2009 at 01:37:53PM +0800, Jeffrey 'jf' Lim wrote: > > OK. Just so that I get an idea, how many use_backend rules (and how many > > backends) do you have in a large config ? I'm asking because I want to be > > able to support ACL files and rules files, and the way to implement them > > should mostly be driven by large config users. > > > > we're on the way to reaching 100 use_backend rules even as we speak... > :) (and because these rules are largely of the pattern i've > mentioned.. this motivated this patch here)
OK, that's still pretty reasonable. I know configurations with 500 "listen" sections, and fortunately they don't use ACLs ! > > I have no problem with "use" if we only support "use_backend", but > > I was thinking about extending it to support other keywords, and > > thought it would be a bit awkward with keywords such as "redirect" > > or "block". Maybe I'm wrong and "use" fits all usages ? > > > > 'use' is kind of generic, i suppose. I have to admit, though - that > was proposed with my usage situation and tons of 'use_backend' > swimming around in my head! :P But I get your point - you want to > expand this to other keywords. OK maybe "use" is OK in fact, considering the alternatives. > Yeah, I had to cut it in two halves cos of the "overloading" of the > 'use_backend' keyword... Of course if we use a separate keyword, then > nothing like that happens :P I cut acl processing in half too - but of > course, i guess that's only a given since we want to be able to reduce > processing anyway. Well, keep in mind that processing ACLs is rather cheap anyway. Since most of the CPU time is already spent in system, even if you would multiply haproxy's work by 10, you would only cut performance in half. I have memories of something like less than 10-20% performance loss with 1000 ACLs, but I may be wrong. That does not prevent us from optimising for massive usage though ;-) (...) > > While we would have something more like this : > > > > use_backend_block if X or Y > > use B1 if X1 or Y1 or Z1 > > use B2 if X2 or Y2 or Z2 > > > > => foreach acl in X Y; do > > if (acl) > > foreach rule in B1 B2; do > > foreach acl in X1 Y1 Z1; do > > if (acl) use_backend $B > > > > hm... I dunno. I think it's more of like this? (this is great for > dealing with 'and' conditions as well, btw) > > if X or Y; do // or could be 'X and Y'! 'unless X', ... whatever > if X1 or Y1 or Z1 > use_backend B1 > else if X2 or Y2 or Z2 > use_backend B2 Yes, you're right, in fact your "if" above are the call to acl_exec_cond() while my "foreach acl in" was also the call to acl_exec_cond(). I just wanted to emphasize on the fact that we're not scanning ACLs then deciding on an action, but rather check all conditions for an actions and perform it if a rule matches. If we extend the system, we'll have to associate parameters with a condition. But since the entry point is the switching rule here, maybe we'll end up with something very close to what you have implemented in your patch, in the end, and it's just that we want to make it more generic to use the two conditions layers in any ruleset. Regards, Willy
