On Fri, Mar 18, 2011 at 11:58 AM, Richard Quadling <rquadling@xxxxxxxxx>wrote: > On 18 March 2011 17:36, Nathan Nobbe <quickshiftin@xxxxxxxxx> wrote: > > On Fri, Mar 18, 2011 at 11:19 AM, Stuart Dallas <stuart@xxxxxxxx> 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. > > > > -nathan > > > > The addition of a small cookie would far outweigh all the > communication to and from the SQL server (even though it is only > memory). > > Consider that you are going to be getting a session cookie from the > client, substituting the cookie for compressed/encrypted data should > be very quick. Nothing more than a bit of string manip. > Well that and travelling over the Internet, which is where the slow down comes in. > The actually traffic for a channel to a SQL db is going to be a little > more than a few bytes. All the handshaking and SQL server processing > of the SQL statement, the data retrieval and packaging and > transmission ... > I dunno, I'd say that should still be faster given that it's all on one side of a wide area network, but for really small pieces of data it could be slower. I'd say that for the right circumstances, putting the session data in > the cookie would be beneficial. No doubt - especially when you're starting a company and looking at a bare pocket book! -nathan