Re: PHP session replication

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