: 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.
Butting in a little OT here but will v1.5 support the transparent use of
additional path if cookies are turned off.
The reason for asking is that other web technologies have this sort of
functionality and this would be a great plus for mod_perl (I know it does
not need it, and this can be easily writen..).
Greg Cope
<bits snipped>
