On Tuesday 12 February 2008 16:06:04 Stut wrote: > Sancar Saran wrote: > > Hello > > > > On Tuesday 12 February 2008 13:39:19 Stut wrote: > >> I'll be using memcache as a simple cache. I hate sessions and avoid them > >> for anything but the most trivial sites. The main sites I work with no > >> longer use sessions because they add a pointless layer of complexity to > >> any application that need to scale beyond a single machine. Maybe I'm > >> just lucky that the applications I develop don't need to store huge > >> amounts of temporary data during a visit, but I'm yet to come across a > >> reason to use "session data". > >> > >> -Stut > > > > May I ask how can you record the state ? > > You may. > > Oh, you probably want an actual answer... ok. > > The only 'state' I really need to keep track of is a few details about > the logged in user (ID, username, etc). These get encrypted and get > passed around as a single value in the same way PHP manages the session > ID (cookie or embedded in the URL). > > The encrypted value is time limited and gets updated on each request. > > Clearly there is a limit to how much info can be stored like this but > after some analysis of how the site worked I reached the conclusion that > most of the crap that was being put into the session was not required > from request to request and could be retrieved from the DB when it was > needed. > > This has been running on a site with > 1 million unique users a month > for over 6 months with no issues. I now use this system with most sites > I get involved in and am yet to find a valid reason to replace it with a > traditional session. > > Part of the reason this works is that in the few parts of the site where > it would make sense to use a traditional session to temporarily store > data it does it in a table in the database. This is essentially a > SQL-based session but with one important difference... DB hits are > limited when they are needed only - i.e. when the user is using those > parts of the site. With a SQL-based session you cause 2+ DB hits for > each request even if you don't actually use the session. This is bad m'kay! > > Over the past few years I've learnt a lot about scalability and the > single biggest tip I can pass on is to only do what is absolutely > necessary at any given time. Sessions are the biggest barrier to being > able to do that, so they had to go. > > Hope that answers your question. > > -Stut Yes Thanks much :) Sancar -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
