Hi all,
On Don 10.07.2008 06:53, Willy Tarreau wrote:
>Hi Beni,
>
>On Tue, Jul 08, 2008 at 09:09:05PM +0200, Benedikt Fraunhofer wrote:
[snipp]
>> what I did was the following (the full patch is attached)
>>
>> 1) added
>
>Well, first I must say I'm happy that someone works on this. However,
>you're too much focused on session IDs. What we need is a more generic
>persistence framework, which will process session IDs like anything
>else.
>
>There are two types of stickyness we need to support :
> - response->request : first request is load-balanced, one piece of
> information is learned from the response, and subsequent requests
> are scanned for this information, which leads to direct access to
> the server if the required information is found. This is what is
> currently done with appsessions (learn cookie from set-cookie, then
> match it either in cookie: or in URL).
>
> This might be extended to SSL IDs for instance.
>
> - request->request : first request is analyzed, any useful information
> is stored, then the request is load-balanced. The assigned server is
> stored with the rest of the information. Next requests are simply
> scanned, and if a matching information is found, then you go directly
> to the server without storing anything else. This would be useful for
> source IP addresses, hashes of some request invariants (user-agent,
> accept-*, ...), etc.
>
>Right now, only #1 exists and only for cookies.
and GET / POST requst.
Isn't url_param not similar?
>#2 does not exist at all and you're going into that direction (which is
>fine). I would just like you to see further than just cookies or URL
>session IDs. You might see from the description above that there are
>two parts in the process :
>
> - data extraction for storage
> - data extraction for matching
>
>Those two mechanisms should be independant, even if often tied. This is
>already partially the case with appsessions since we store from
>set-cookie headers and match from either cookie: or URL param.
>
>This should simply be extended to work like this :
>
> - define where/how to find the information to store (request header,
> request URL param, source IP, response header, response cookie,
> response SSL ID...)
>
> - define where to store it (a "persistence pool"), for how long max,
> and the max number of entries
>
> - define where/how to find the information to match (request header,
> request URL param, source IP, request SSL ID...)
and of course some log entries.
>Now, I'm well aware that you will not do all that in one second, and
>that's not my intention. However, I'd like that you try to match this
>scheme for your implementation (even if it requires small changes to
>the existing appsessions to make it fit). Basically, you should
>consider that right now we only store session IDs, so you will just
>have one fixed persistence pool (reuse appsessions). Appsessions
>already finds the information to store in one place (response cookie)
>and matches it in two places (cookie and url param). So all in all, you
>already have #2 and #3 done (may be will need some tweaking). You
>"just" have to completely implement #1 and try to make it cleanly share
>existing #2/#3.
>
>If you can do this cleanly with all possible evolutions in mind, it
>will later be simple to add lots of stickiness methods (even on
>arbitrary contents). That's why I'm insisting for something going in
>the direction of a generic framework.
I also prefer a generic one, imho.
>To be honnest, I've quikly looked at your patch, and the way it works
>does not appear obvious to me, mostly because appsessions is already
>not obvious to me :-) So I'd like that you try to see how to more
>clearly separate the 3 principles above in the code (do not hesitate to
>add comments where you find things that take a long time to
>understand).
What I not understand is that for the ';' and '?' you have the appsession and the url_param the only think I don't see is the 'spliting' with '&' but this I could oversee in the src/proto_http.c or it is in anothter file ;-)
>A nice evolution would consist in being able to store the persistence
>information in a remote shared memcached server (two in fact for high
>availability). That way, we would be able to restart haproxy without
>losing persistence information, and we could also have multiple
>haproxies sharing persistence information. This is a really important
>point too, as many of us are using multiple haproxies in front of
>application servers. It also solves the multi-process problem.
>
>We've had long talks about all this with Aleksandar Lazic in the past,
>when he implemented the appsessions. Do not hesitate consulting him too
>when you have a hard time making a decision about something, I'm fairly
>sure he will be interested in sharing useful thoughts, as he has made
>intensive usage of appsessions in the past and has been confronted to
>far more annoying applications than me :-)
Oh yes the past ;-))
>And of course, I'm very much interested too :-)
Still, me too.
Cheers
Aleks Received on 2008/07/10 23:46
This archive was generated by hypermail 2.2.0 : 2008/07/11 00:00 CEST