If i am right then you have 1.44KB per request ? BR/Torsten
"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
