2009/5/20 gert <[email protected]>: > > On May 20, 1:02 am, Graham Dumpleton <[email protected]> > wrote: >> 2009/5/20 gert <[email protected]>: >> >> > On May 19, 6:03 am, Graham Dumpleton <[email protected]> >> > wrote: >> >> Since I am not sure when I might get to blog and/or document this >> >> properly, here is a example configuration for how to implement sticky >> >> sessions, also referred to as session affinity, when using mod_wsgi >> >> daemon mode. >> >> >> Note that this just shows the basic concept. One could get more >> >> elaborate again by using 'prg' RewriteMap to use a separate program to >> >> determine which process should be used rather than it being random. >> >> You might for example choose process which is having least requests >> >> passed through to it for existing sessions. >> >> >> If anyone wants to discuss it, by all means go ahead. My expectation >> >> at the moment is that only those who know what session stickiness is >> >> all about might do that. In other words, I don't want to necessarily >> >> have to go explain what it is. If you don't know, then do a Google >> >> search on 'session affinity' or similar. >> >> >> # Define multiple process groups each with a single multithreaded process. >> >> >> WSGIDaemonProcess sticky01 processes=1 threads=10 display-name=%{GROUP} >> >> WSGIDaemonProcess sticky02 processes=1 threads=10 display-name=%{GROUP} >> >> WSGIDaemonProcess sticky03 processes=1 threads=10 display-name=%{GROUP} >> >> WSGIDaemonProcess sticky04 processes=1 threads=10 display-name=%{GROUP} >> >> WSGIDaemonProcess sticky05 processes=1 threads=10 display-name=%{GROUP} >> >> >> # Mount our WSGI application at the sub URL of '/sticky'. >> >> >> WSGIScriptAlias /sticky /Users/grahamd/Sites/sticky/site.wsgi >> >> >> # Specify a rewrite map which randomly selects one of the process groups. >> >> # The contents of the file should be: >> >> # >> >> # processes sticky01|sticky02|sticky03|sticky04|sticky05 >> >> # >> >> # That is, an entry for each of the named process groups in appropriate >> >> # format for a random rewrite map. >> >> >> RewriteMap sticky rnd:/Users/grahamd/Sites/sticky/processes.txt >> >> >> <Directory /Users/grahamd/Sites/sticky> >> >> >> # Lots of rewrite magic to follow. >> >> >> RewriteEngine On >> >> >> # Extract the name of the process group from cookie sent in the request. >> >> >> RewriteCond %{HTTP_COOKIE} process=([^;]+) >> >> RewriteRule . - [E=PROCESS:%1] >> >> >> # Validate the name of the process group and if not valid then set it >> >> # to one of the process groups randomly. >> >> >> RewriteCond %{ENV:PROCESS} !^sticky0[12345]$ >> >> RewriteRule . - [E=PROCESS:${sticky:processes}] >> >> >> # Set the cookie so that life time of the cookie always pushed out when >> >> # active. The cookie will expire after defined number of minutes of >> >> # inactvity and stickiness lost. Using a stickiness timeout of 60 minutes. >> >> >> RewriteRule . - [CO=process:%{ENV:PROCESS}:%{HTTP_HOST}:60:/sticky] >> >> >> # For the WSGI application, indicate that process group should be selected >> >> # based on value for the cookie or where appropriate as set randomly. As >> >> # extra security measure, even though we validate name above, limit what >> >> # process groups could be selected in case there might be others >> >> configured >> >> # for same server. >> >> >> WSGIRestrictProcess sticky01 sticky02 sticky03 sticky04 sticky05 >> >> WSGIProcessGroup %{ENV:PROCESS} >> >> >> </Directory> >> >> > First stupid question: >> > Whats wrong with WSGIDaemonProcess sticky processes=5 threads=10 >> > display-name=%{GROUP} ? >> > They are identical processes, so why stick with process 1 when >> > processes 2 has nothing to do ? >> >> First stupid response. Did you do any research about what sticky >> sessions or session affinity is intended to achieve? Can you explain >> what the benefit is of having subsequent requests from same user going >> back to the same process? > > The benefit would be you can store session id's into a global var > array instead of a database. What raises the question, why would you > do that ? > 1) Your wsgi code, only works on servers that can do this
Keeping session data in memory, and subsequently making it a lot faster, is one thing you could do. Yes that would bind you to that architecture. But there are other things that could be done which wouldn't. Start thinking about caching in general. Imagine that a database query was done which was specific to a user, but that the data set was large enough not to easily be returnable in one page. On a subsequent request to get more of the results, if it can go back to the same process it may be able to benefit from any caching of database results implemented by a database client or ORM layer and not actually have to resubmit the query. If the request could have gone to another process, then no choice to have to do the query again. So, there can be benefits in area of transient caching of data to avoid database queries. This can improve performance, but also may avoid having multiple copies of same transient cached information kept in multiple processes for same multipart user request, thereby reducing overall memory usage. > 2) You can create bottle necks for some users because they are on the > same process of the one user who is doing this select * from GIGANTIC That would only be an issue if using single threaded daemon processes and not multithreaded daemon processes. > 3) Makes clustering apache servers impossible Not everyone uses clusters of Apache servers. Where they do, they use something like Pound or similar in front, which implements session stickiness in dedicated proxy/load balancer. Even with such a thing in front, probably entirely reasonable to create a two tier stickiness. That is, Pound gets you to the correct Apache instance and the example I gave you gets you to the actual process. Graham --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "modwsgi" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en -~----------~----~----~----~------~----~------~--~---
