> FYI-- here are some Apache::Session benchmark results. As with all
> benchmarks, this may not be applicable to you.
Thanks for taking the time to run these and write up the results.
> Benchmark: This benchmark measures the time taken to do a create/read for
> 1000 sessions. It does not destroy sessions, i.e. it assumes a user base
> that browses around arbitrarily and then just leaves (i.e. does not log
out,
> and so session cleanup can't easily be done).
It would be interesting to see how the options perform with different mixes
of read/write traffic, i.e. not writing every time as you are in your
current code. Maybe not that big a deal, since we can assume more writes
will have worse performance across the board, but it would also be
interesting to see how locking issues might come into play if you were using
different lock managers. And the next step from there would be to run the
test from many processes in parallel and see how they do.
> Apache::Session::File - Dual-PIII-600/512MB/Linux 2.2.14SMP: Ran 4 times.
> First time: ~2.2s. Second time: ~5.0s. Third time: ~8.4s. Fourth time:
> ~12.2s.
Is there any reason not to use a file tree approach (splitting first and
second characters of filenames into separate directories) like mod_proxy
does? This seems like a pretty easy solution to the problem of degraded
performance on larger sets of data.
> Question: does anyone know how to pre-specify the _session_id for the
> session, rather than allowing Apache::Session to set it and read it? I saw
> some posts about it a while back, but no code...
Isn't it just this?
tie %session, 'Apache::Session::Foobar', $id;
- Perrin
