Hi Joe! I like the idea! You also implemented it pretty quick! I tested you're implementation(not production) and it seems to work quite good. The only thing I wonder is, why not choose a property which you can deterministically extract a backend from. Like the clients ip for example. The decimal value, modulo the number of backends. Or a cookie, modulo the #backends etc.
About the writers-starvation. What platforms does pound want to support? I can think of the main ones: Linux, *BSD, Solaris?, MacOS? If these platforms support the writers-starvation regulations is it acceptable to adopt this system? Steven -----Oorspronkelijk bericht----- Van: Joe Gooch [mailto:[email protected]] Verzonden: maandag 3 januari 2011 21:19 Aan: <[email protected]> Onderwerp: RE: [Pound Mailing List] RE: Website stalls every 60 seconds I've implemented the "tag each request with the backend in the browser instead of storing our sessions locally and incurring concurrency costs" method of session tracking. Described in 5 below. Patch (against 2.6c) is at: https://users.k12system.com/mrwizard/pound/pound_26_backend_cookies.patch.bz2 Essentially the change to session handling is when it has to choose a random backend (i.e. didn't find in the hashtable, or hashtable/sessions are disabled), it will check for the backend key header and if found, it will use the backend that matches (if possible). This can be used to turn off session handling entirely (allowing pound to use backend keys to use backend stickyness), or to augment session handling... For instance, if pound is restarted, the session DB is cleared. Using the cookie in the browser, when sessions are recreated, the correct backend will be chosen to resume their sessions. Joe > -----Original Message----- > From: Joe Gooch [mailto:[email protected]] > Sent: Friday, December 31, 2010 2:41 PM > To: <[email protected]> > Subject: Re: [Pound Mailing List] RE: Website stalls every 60 seconds > > On Dec 31, 2010, at 4:27 AM, "Robert Segall" <[email protected]> wrote: > > I don't like many of the solutions that come to mind. > 1) Wite our own fair/prioritized locking w/ linked lists or queues and > use mutexes and condition variables to implement. > 2) Find a C library that implements the semantics we need... Whether > that's a hashtable or locking library depends on what we could find. > 3) Write our own hashtable... For instance, mutex lock the fixed array, > release once we find the collision chain... Have a mutex for each > collision chain. Then t_expire can lock by collision chain and limits > the requests that are blocking at any given time. > 4). Use better hardware :) > 5) Use distributed session tracking instead of tracking it in > Pound.... > > For 5... Other load balancing appliances use a different approach... > The load balancer itself generates a cookie to tag the sessions. ( I > wouldn't even consider param/url rewrites ). Semantics would be like > this: > A). In the config pick a cookie name, domain, expiration for the > cookie,httponly flags etc. > B). On each request, look for our cookie. If it exists, use it to > determine the backend to use. Otherwise choose one randomly. If the > backend is down choose another. > C). Add a set cookie header to every request that sets or resets our > cookie. (thus updating the expiration time) > > Using this method no database is necessary in pound. The browser tells > the load balancer where it belongs. This has other cool benefits like > you can kill and restart pound and other than the connectivity > interruption, session affinity would be preserved. And no concurrency > issues because each request is autonomous. > > Implicit in this is the ability to uniquely identify each backend... > Either with a key inn the backend section in the config, or a hex > representation of the sin_addr and port... > > Might need to have this as an option so url/param LB is still an > option. -- To unsubscribe send an email with subject unsubscribe to [email protected]. Please contact [email protected] for questions. -- To unsubscribe send an email with subject unsubscribe to [email protected]. Please contact [email protected] for questions.
