According to Tom Mornini:
> > 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!
Using cookies where they work doesn't prevent you from using
another mechanism where you need it. Conceptually, I think
things like user preferences 'belong' on the user's machine
and should be allowed to be different from one machine/browser
to another for the same user. Things like a shopping cart
in progress might belong on the server.
> 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.
What kind of traffic can you support with this?
> Limiting yourself to cookie size limitation would be a real drag.
I'm more concerned about dealing with large numbers of simultaneous
clients (say 20,000 who all hit at 10 AM) and I've run into problems
with both dbm and mysql where at a certain point of write activity
you basically can't keep up. These problems may be solvable but
timings just below the problem threshold don't give you much warning
about what is going to happen when your locks begin to overlap.
Les Mikesell
[EMAIL PROTECTED]
