| dharana 2005-04-08, 7:45 am |
| Gregory (Grisha) Trubetskoy wrote:
>
> yeah, but with dbm it's just one file - here you're looking at a file
> per session (if i read the code correctly).
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.
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)
b) Manually configure the nesting level throught a PythonOption. It
would be faster because mod_python doesn't have to think but we would
handle slightly less total sessions with the same number of subdirectories.
Prons and cons: just the opposite of a)
ABOUT THE IMPLEMENTATION
With the a) option and 2 levels nesting we would have sessions in:
a/ (max_sessions_per_dir with sid starting with a)
a/a/ (max_sessions_per_dir with sid starting with aa)
With the second option and 2 levels nesting:
a/ (session empty, just subdirs)
a/a/ (max_sessions_per_dir)
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 ?
>
> 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.
>
Nicolas took the lead!
> Thanks!!!
>
>
|