On Friday, 18 March 2011 at 19:25, Torsten Rosenberger wrote: If i am right then you have 1.44KB per request ? >
I've never done the analysis, but it's an AJAX-heavy site so that could well be the average. -Stuart -- Stuart Dallas 3ft9 Ltd http://3ft9.com/ > "Stuart Dallas" <stu...@3ft9.com> schrieb: > > > 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 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/ > > > > > > > > > > > > -- > > PHP General Mailing List (http://www.php.net/) > > To unsubscribe, visit: http://www.php.net/unsub.php > > -- > Sent from my Android phone with K-9 Mail. Please excuse my brevity. > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
