quetz-mod_python-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Barry Pearce" <barry.pea...@copyrightwitness.net>
Subject Re: [mod_python] Sessions performance and some numbers
Date Fri, 08 Apr 2005 11:31:07 GMT
Hi,

>> yeah, but with dbm it's just one file - here you're looking at a file
>> per session (if i read the code correctly).

This is actually easier to manage.

> About the hashing mechanism. I thought about two different ways of
> handling it.
>
> a) On session saving FileSession determines the current number of files
> in the same dir, and if it exceeds some preset number it will create a
> one letter subdirectory based on the sid it has been passed. At two
> level nesting it would handle 240 directories. If we specify 500 max
> files per dir (I don't know if this is a sane number, but in my test
> system it didn't showed a big slowdown) we should be able to handle
> 120.000 active sessions.

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:

4c34ef90-081-364f1a9c

If there is a collision - we re-evaluate the random and try again until it works....This will
therefore support more clients than you would ever wish to imagine. Because of the basis on
time
as part of the filename you need a HUGE number of connections intiating in 1 second FROM THE
SAME
IP (possible if it is a proxy) to even remotely have a chance of collision.

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

4c34ef90/081/364f1a9c


> Pros: no need to change it in the advent of, for example, an slashdotting
> Cons: slightly slower speed (althought I don't yet know the impact)

We certainly have no performance problems.

> With method a) we would have to recursively iterate on session loading
> until we find the passed sid. We would also need to get the current
> number of files in the current directory on session creation. And,
> finally, on session saving we would need to iterate recursively again
> again until we find the session file.
>
> a) seems a total mess. Nicolas, do you want to code it ?

er. If I understood that correctly - yuk.

>> I say go for it. For locking, look at the session code. Note that it
>> uses lock number 0 which is what you should use as well to avoid
>> deadlock with the session-specific locking.

I use a .lck file - can avoid race conditions, and more importantly doesnt rely on o/s
capabilities (such as lockf - which doesnt work anyway in a multi-threaded environment.)

Regards,
Barry

Mime
View raw message