On Fri, Mar 18, 2011 at 11:58 AM, Richard Quadling <rquadl...@gmail.com>wrote:

> On 18 March 2011 17:36, Nathan Nobbe <quickshif...@gmail.com> 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.
> >
> > -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

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!


Reply via email to