Re: PHP session replication

On 17 March 2011 16:45, Stuart Dallas <stuart@3ft9.com> wrote: > On Thursday, 17 March 2011 at 16:16, Richard Quadling wrote: > On 17 March 2011 16:04, Stuart Dallas <stuart@3ft9.com> wrote: >> > On Thursday, 17 March 2011 at 16:02, Richard Quadling wrote: >> > On 17 March 2011 15:30, Stuart Dallas <stuart@3ft9.com> wrote: >> > > > On Thursday, 17 March 2011 at 15:29, Stuart Dallas wrote: >> > > > On Thursday, 17 March 2011 at 15:22, Richard Quadling wrote: >> > > > > On 17 March 2011 15:18, Stuart Dallas <stuart@3ft9.com> wrote: >> > > > > > > On Thursday, 17 March 2011 at 15:15, Nathan Nobbe wrote: >> > > > > > > On Wed, Mar 16, 2011 at 10:06 PM, Alessandro Ferrucci < >> > > > > > > > alessandroferrucci@gmail.com> wrote: >> > > > > > > > >> > > > > > > > > Hello, >> > > > > > > > > I'm curious, what are the most popular methods >> > > > > > > > > to perform session >> > > > > > > > > replication across http servers in PHP? >> > > > > > > > > I've read about repcache(memcached module) and >> > > > > > > > > Mysql. >> > > > > > > > > anything else? is there some >> > > > > > > > > mod_php_session_replication httpd module? >> > > > > > > > > thanks >> > > > > > > > >> > > > > > > > I recently posted a question to the memcached mailing >> > > > > > > > list about this. I >> > > > > > > > would suggest looking at membase if you're >> > > > > > > > interested in that route. >> > > > > > > > >> > > > > > > > Pragmatically speaking though, I'd say go for >> > > > > > > > database backed sessions until >> > > > > > > > they actually become a performance bottleneck. >> > > > > > > > >> > > > > > > > Here's the post from google groups if you're >> > > > > > > > interested: >> > > > > > > > >> > > > > > > > >> > > > > > > > http://groups.google.com/group/memcached/browse_thread/thread/7ed750db888e6b1b?pli=1 >> > > > > > > >> > > > > > > This may also be of interest: ï½mÖmŠ º¬Ž`ó* >> > > > > > > http://stut.net/2008/07/26/sessionless-sessions-2/ >> > > > > > > -Stuart >> > > > > > > >> > > > > > > -- >> > > > > > > Stuart Dallas >> > > > > > > 3ft9 Ltd >> > > > > > > http://3ft9.com/ >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > -- >> > > > > > > PHP General Mailing List (http://www.php.net/) >> > > > > > > To unsubscribe, visit: >> > > > > > > http://www.php.net/unsub.php >> > > > > > >> > > > > > Stuart, that's just cruel. >> > > > > > >> > > > > > Stut.net >> > > > > > Ramblings of a random software engineer >> > > > > > Error 404 - Not Found >> > > > > > Apologies, but we were unable to find what you were looking for. >> > > > > > Perhaps searching will help. >> > > > > > >> > > > > > Very much a Friday comment though. Along the lines of LMGTFY. >> > > > >> > > > Works fine from here, but I should probably add a search box to the site >> > > > given that 404 message :) >> > > > >> > > > -Stuart >> > > > >> > > > -- >> > > > Stuart Dallas >> > > > 3ft9 Ltd >> > > > http://3ft9.com/ >> > > >> > > GMail added the -Stuart on the next line onto the URL. >> > >> > Indeed. I've put in a permanent redirect for that specific URL. >> > >> > >> > -Stuart >> > >> > -- >> > Stuart Dallas >> > 3ft9 Ltd >> > http://3ft9.com/ >> >> I think ASP does something similar to what you've suggested. >> >> I don't know if you've considered this, but if you use >> session_set_save_handler() to wrap up your code, you the rest of the >> code can still use $_SESSION without having to do anything extra. >> >> Which is the main reason for session_set_save_handler(). >> >> Though you would have to make sure your code didn't output in dribs >> and drabs, essentially the last line in the code is the output as the >> cookie writing would have to be done before any output. >> >> Or use output buffering ... > > ASP.net, which I think is what you mean, keeps the session in a hidden form field. In order to > maintain that it has to make every single page one giant form, which is evil in many ways. > > I did consider implementing it using the existing PHP session stuff. The problem is that it > won't prevent people from stuffing large amounts of data into the session, which then ends up > in cookies. This is one of the reasons I really don't like the way ASP.net does it - the full > state gets transferred with every single request. > > The basic theory being my implementation is two-fold. Firstly it removes the need for > server-side storage for data specific to a given session. Secondly it stores only the minimum > required to limit DB accesses to when it's absolutely necessary. > > All too often I see sessions being used as a cache. Developers stuff data retrieved from the > database into the session so it's easily accessible for the next few page requests. In reality > there is minimum gain here when you start scaling across servers because you're still hitting > the DB (or some other data store). Sure, it may be a cheaper query, but if that's the case you > need to look at the original query and see how you can optimise it. > > The sites I maintain generally store PHP objects in memcache with long expiry times. Those > cached objects are updated when they change, and the site only reads from the DB when absolutely > necessary. With this arrangement the read-only general public facing sites can continue to run even > if the DB goes down. Given that architecture it makes sense to maintain user sessions in a way that > also does not involve the DB, otherwise that whole caching mechanism is pointless. > > As far as organising the page flow goes, my sites generally follow a three-step process when > building a response... > > 1) Gather data. > > 2) Output the header and use register_shutdown_function to queue the footer. > > 3) Output the page content. > > Given this arrangement there should never be a reason to set any cookies beyond step 1 so > it's never a problem. > > One final point on output buffering... when you deal with very busy sites you quickly see how > expensive output buffering is. I do use it, but sparingly since every little bit of memory adds up. > > > -Stuart > > -- > Stuart Dallas > 3ft9 Ltd > http://3ft9.com/ > > > > > Thanks for the additional info. Excellent readin. -- Richard Quadling Twitter : EE : Zend @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY