Re: PHP session replication

On Friday, 18 March 2011 at 17:36, Nathan Nobbe wrote: On Fri, Mar 18, 2011 at 11:19 AM, Stuart Dallas <stuart@3ft9.com> wrote: > > On Friday, 18 March 2011 at 17:14, Torsten Rosenberger wrote: > > > > I'm curious to know what people are storing in their sessions. Is there > > > > anything larger than a few hundred bytes that is specific and unique to that session storage? What > > > > are the use cases for server-side session storage because it seems like I'm missing something? > > > > > > I store user rights in the session but also possible to do it with a DB query every > > > time. > > > > Why not store those in an encrypted cookie? Unless we're talking about more than a > > couple of hundred bytes I see no reason to store them separately server-side or to hit the DB each > > time. > > Stuart, would you not agree that sending any amount of data over the wire takes more time than > passing it over an internal network? From my perspective the tradeoffs of cookies vs. server side > session storage are application performance and cost of ownership. > > An application will be more responsive if less data is sent over the wire on each request > however running a distributed session store on the server side can be expensive monetarily. Storing > session data in cookies has it's merits, but I think they start to loose their benefits on > large sites. The way I see it they can be a great way to cope with startup costs and server-side > complexity on low traffic sites. Agreed, but how much traffic do you need to be getting for an extra 127 bytes per request to make a noticeable addition to page response times or your bandwidth bill? I just logged in to the main site on which I use this mechanism and checked the headers sent by the browser. This is what got sent... Cookie: t=HgiivpyFIVX62BYIe4PSg4de04I92qTa1aL6yu8vQDI%3D; expires=Sat, 17-Mar-2012 17:39:36 GMT; path=/; domain=example.co.uk That's 126 bytes plus the LF, and that's assuming that your site sets no other cookies. If it does then the extra weight is only 118 bytes. Obviously this varies slightly but essentially we're talking about a very small overhead per request. My strategy specifically aims to limit the amount of data stored in cookies - I don't use sessions to store anything that's not absolutely necessary. I would argue that an application will get more responsive with every server-side shared resource you remove from the equation. Compare the time taken to receive an extra 118 bytes and decrypt that data to the time taken to make a request to a shared data storage system, bearing in mind that such a system will get slower as the number of concurrent requests increases. I agree that for sites with huge amounts of traffic need to look at this type of problem differently, but I think the level at which your perspective changes is very high. The main site on which I use this cookie-based system peaks at ~400 reqs/sec and pushes out just under 1.5TB of HTML per month. I've done the calculations and the cost of maintaining a server-side session store are huge compared to the extra bandwidth used by the cookies. If your app really needs to store large amounts of data in sessions (and I'm yet to have anyone give me a solid example) then the maths will flip and server-side storage becomes the cheaper option. So, in summary, you're right that the data transfer time will be lower server-side, but there are other factors that also need to be considered. -Stuart -- Stuart Dallas 3ft9 Ltd http://3ft9.com/