Re: dynamic weights based on actual server load
Hi On Sun, 18 Oct 2009 08:26:37 +0200, Willy Tarreau wrote: > Hello, > > On Sat, Oct 17, 2009 at 11:18:24AM +0200, Angelo Höngens wrote: > > Just read this thread, and I thought I would give my humble opinion > > on this: > > > > As a hosting provider we use both windows and unix backends, en we > > use haproxy to balance requests across sites on a per-site backend > > (with squid in front of haproxy). What I would love to see, is > > dynamic balancing based on the round-trip time of the health check. > > > > So when a backend is slower to respond, the weight should go down > > (slowly), so the faster servers would get more requests. Now that's > > a feature I'd love to see.. And then there would not be anything to > > configure on the backend (we don't always have control over the > > backend application) > > Having already seen this on another equipment about 5-6 years ago, I > can tell you this does not work at all. The reason is simple : the > health checks should always be fast on a server, and their response > time almost never tells anything about the server's remaining > capacity. Some people even use static files as health checks. > > What is needed though is to measure real traffic's response time. The > difficulty comes from the fact that if you lower the weight too much, > there is too little traffic to measure a reduced response time, and it > is important to be able to bound the window in which the weight > evolves. For healthcheck-based loadbalancing healthchecks had to be something like "make-some-number-crunching then make some-database-reading" and quite long (because shorter requests tend to be more random). So you will have either have long time between checks or, when checks will be more often, lot of load on server thanks to health-checks. I think loadbalancing should be both done by request length and server load, but then it would have to be some kind of long term log analysing of one often used part of page, for example: 1.If server load (simplest measure will be loadavg/cores) is below 80%, increase weigth 2.If average request time of http://example.org/index.php is less than 90% of target_request_time, increase weight a bit. 3.If avg. req. time is more than target_request_time * 1.1 decrease weight a bit 4. every x minutes if weigth will be less than 50 add 1 if more subtract 50 (so values won't be "drifting" to max or 0 over time) target request time would be some predefined value or (better) calculated average from all nodes + 50% so u won't have situation where every node weigth is skyrocketing or falling down because of small load/overload Regards Mariusz -- Mariusz Gronczewski (XANi) GnuPG: 0xEA8ACE64 http://devrandom.pl signature.asc Description: PGP signature
Re: Small patch for the "appsession" feature
On Son 18.10.2009 12:46, Cyril Bonté wrote: Le dimanche 18 octobre 2009 12:05:55, Willy Tarreau a écrit : Cyril, I have merged your two patches. Thanks ! I'm thinking of working on a second patch. The documentation says that appsession looks for the session in the query string but this is not really the case. Currently, it parses the first path parameter (followed by ';'). I would like to add an option to decide if appsession parses path parameters (not only the first one) or the query string parameters so it can work for URLs like "http://website/path?PHPSESSID="; for example. Our need was to catch the jsessionid which comes before the query string and was delimited with '!' => Bea Weblogic Cookie. I have thought to change this but things changes ;-( The idea was: 1.) appsession per server, if necessary 2.) add delimiter, to be able to be more flexible ;-) 3.) tell the engine where to search for the session, path || query string. ATTENTION: What happen when the query string is very long => Performance, Security, ... 4.) add to stat page the appsession to see how much we already have 5.) add to stat page how often (request_count) and how long a appsession exists. Reason: tune the application setup for the session timeout. Maybe this could be also interesting for the 'normal' cookies ;-) 6.) add the appsession hash dump into the sig_dump_state(). BTW: does the SIGHUP is moved to reload the config or will it stay to dump the states? Afaik the most server use HUP for reload. You see there was a lot todos and ideas. I'am happy that anybody have pickedup this feature, thanks Cyril. aleks
Re: Small patch for the "appsession" feature
Le dimanche 18 octobre 2009 12:05:55, Willy Tarreau a écrit : > Cyril, I have merged your two patches. Thanks ! I'm thinking of working on a second patch. The documentation says that appsession looks for the session in the query string but this is not really the case. Currently, it parses the first path parameter (followed by ';'). I would like to add an option to decide if appsession parses path parameters (not only the first one) or the query string parameters so it can work for URLs like "http://website/path?PHPSESSID="; for example. > I applied a very minor change, > I removed the appsession_option field and used the normal proxy options > instead ; it was not necessary to add 32 bits to the proxy while there > were plenty available for that purpose. You're right, this was not useful, I didn't want to conflict with some potential other patches. > I have also added a few lines in the doc about the new keyword Yes, the most important part of the patch was missing :) -- Cyril Bonté
Re: Small patch for the "appsession" feature
On Thu, Oct 15, 2009 at 12:15:40AM +0200, Cyril Bonté wrote: > OK, here comes the 2 patch files for haproxy-1.3.21 and haproxy-1.4-dev4. > Please note 3 minor changes in those versions (proto_http.c / proto_http.h) : Cyril, I have merged your two patches. I applied a very minor change, I removed the appsession_option field and used the normal proxy options instead ; it was not necessary to add 32 bits to the proxy while there were plenty available for that purpose. I have also added a few lines in the doc about the new keyword, and committed with your first mail as a commit message. Thanks ! Willy
