On Mon, 8 May 2000, Leslie Mikesell wrote:
> According to Jeffrey W. Baker:
>
> > > I keep meaning to write this up as an Apache:: module, but it's pretty trivial
> > > to cons up an application-specific version. The only thing this doesn't
> > > provide is a way to deal with large data structures. But generally if the
> > > application is big enough to need such data structures you have a real
> > > database from which you can reconstruct the data on each request, just store
> > > the state information in the cookie.
> >
> > Your post does a significant amount of hand waving regarding people's
> > requirements for their websites. I try to keep an open mind when giving
> > advice and realize that people all have different needs. That's why I
> > prefixed my advice with "On my sites..."
>
> Can anyone quantify this a bit?
>
> > On my sites, I use the session as a general purpose data sink. I find
> > that I can significantly improve user experience by keeping things in the
> > session related to the user-site interaction. These session object
> > contain way more information than could be stuffed into a cookie, even if
> > I assumed that all of my users had cookies turned on. Note also that
> > sending a large cookie can significantly increase the size of the
> > request. That's bad for modem users.
> >
> > Your site may be different. In fact, it had better be! :)
>
> Have you timed your session object retrieval and the cleanup code
> that becomes necessary with server-session data compared to
> letting the client send back (via cookies or URL) everything you
> need to reconstruct the necessary state without keeping temporary
> session variables on the server? There must be some size where
> the data values are as easy to pass as the session key, and some
> size where it becomes slower and more cumbersome. Has anyone
> pinned down the size where a server-side lookup starts to win?
I have really extensive benchmarks for every part of Apache::Session.
These will be released with version 1.5, which also includes more than
fifty new unit tests. Again the performance is very dependent on what you
are doing. If everything is on one machine and you are grabbing Storable
obejcts from the filesystem, you can retrieve and unStorable the object in
time on the order of 100 microseconds (600 MHz Intel/Linux 2.2). If you
need to get the object out of a database across the network, network
latency will add to that. In larger applications, I would use a private,
switch 100 Mb/s ethernet to access the shared backing store, so that
latency is not bad. Once again, it depends on your specific needs and
implementation.
I think storing the state information in a cookie is fine, if you can do
it. For me, the state information is larger than what you can shove into
a cookie, according to the cookie specification. It simply is not an
option for me.
I also don't think the cookie storage mechanism is the best thing for the
users. If I store the session information on the server side, I can do
some pretty tricky stuff. The user could use one computer for a while, go
somewhere else, then log in from another computer and I could take him
right back to whatever he was doing before. With cookie storage, you
can't do that.
-jwb
