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/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
