On Mon, 8 May 2000, Leslie Mikesell wrote:
> > 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 can't imagine why anyone would pin a website's future to a session
system that has a maximum of 1k or 2k of session storage potential!
We use a custom written session handler that uses Storable for
serialization. We're storing complete results for complex select
statements on pages that require "paging" so that the complex select only
happens once. We store user objects complete, and many multi-level complex
data structures at whim.
Limiting yourself to cookie size limitation would be a real drag.
--
-- Tom Mornini
-- InfoMania Printing and Prepress
