If i am right then you have 1.44KB per request ?


"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 
>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

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

Reply via email to