On Fri, Mar 18, 2011 at 11:56 AM, Stuart Dallas <stuart@xxxxxxxx> wrote: > On Friday, 18 March 2011 at 17:36, Nathan Nobbe wrote: > On Fri, Mar 18, 2011 at 11:19 AM, Stuart Dallas <stuart@xxxxxxxx> 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. > Yes, I think it makes sense to start out storing sessions in cookies and consider a server-side move only when it makes sense. > 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. > I worked at a site that is roughly the 25th largest on the net in terms of traffic. This is where I was originally exposed to the tradeoffs of session storage in cookies vs server-side. Until then I presumed things were almost always done server-side. However, if you look at Code Igniter and I'd hazard a guess at a number of other frameworks, the default session store is cookies! This was perplexing until I started to work at the site mentioned above (remains nameless tho:)), where I was actually able to discuss pros & cons thereof. CI seemed to have a problem in that it would not spill data over into additional cookies when the size of one cookie was maxed out. One way to tell it's time to rethink your paradigm is when you're using up the maximum number of cookies for a given domain to propagate data between requests - been there, lol. I'm surprised this concept was such as surprise to many of the list members, I thought this was a well know paradigm, storing session data in cookies. -nathan
