On 17 March 2011 16:45, Stuart Dallas <stu...@3ft9.com> wrote: > On Thursday, 17 March 2011 at 16:16, Richard Quadling wrote: > On 17 March 2011 16:04, Stuart Dallas <stu...@3ft9.com> wrote: >> > On Thursday, 17 March 2011 at 16:02, Richard Quadling wrote: >> > On 17 March 2011 15:30, Stuart Dallas <stu...@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 <stu...@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 < >> > > > > > > > alessandroferru...@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: >> > > > > > > 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 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
