On Friday, 18 March 2011 at 17:36, Nathan Nobbe wrote:
On Fri, Mar 18, 2011 at 11:19 AM, Stuart Dallas <stu...@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 

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 Dallas
3ft9 Ltd

PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to