quetz-mod_python-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gregory (Grisha) Trubetskoy" <gri...@modpython.org>
Subject Re: [mod_python] Sessions performance and some numbers
Date Fri, 08 Apr 2005 16:00:06 GMT


On Fri, 8 Apr 2005, Barry Pearce wrote:

> I already have file based sessions that we implemented some time ago. We use a number
of items:
>
> Firstly I use the time since epoch in hex, then add the 4 numbers of the client IP address
and the
> we append a 32bit random number - which then gives you something that looks like this:

this is pretty much what the _new_sid() is Session.py does (it also adds 
the pid to the mix)

> If you several thousand in the same dir causes problems - then simply use it as a dir
path.

I think should run some tests to see how much of a big deal this really 
is. If you have 10000 active sessions you're bound to have other problems 
elsewhere and I doubt that the session lookup is going to be your main 
slowdown, so I propose we table this discussion until later.

> 4c34ef90/081/364f1a9c

This won't work with _new_sid() because it uses MD5 so session id's aren't 
likely to be alike. But it's a moot point - see above pargraph.

> I use a .lck file - can avoid race conditions, and more importantly 
> doesnt rely on o/s capabilities

what's a .lck file? locking by definition *must* be an OS capability or 
else it _is_ subject to race conditions.

> (such as lockf - which doesnt work anyway in a multi-threaded 
> environment.)

Current locking uses the APR's global locking mechanism which decides 
based on OS and the httpd config/compile options what the most efficient 
locking mechanism is. There is no reason to reinvent the wheel here - it's 
a complex problem that I trust the APR folks are most qualified to solve.

Grisha

Mime
View raw message