On Thursday 31 Oct 2002 8:56 pm, Bear Giles wrote: > Edward Chan wrote: > > The default behavior of server-side session caching is > > to cache session in memory. This is probably not > > gonna work very well if there are a lot of connections > > to the server.... > > > > It says to "open file named according to session id". > > However, session_id contains non-ascii chars, chars > > that are illegal in a filename. So how can I name my > > file according to the session_id? > > If you have enough sessions that you need to cache them on disk, you > probably don't want to write them one-to-a-file either. Don't be so > literal about the "open file" comment. > > Instead, open a single database instance (e.g., a Berkeley DB in "hash" > mode, since you don't care about ordering) and use the session ID as > your key ID. The non-ASCII characters aren't an issue since you > specify a pointer and length, not a null-terminated string, as your > key. > > In practice, I believe apache's mod_ssl uses sdb instead of traditional > db files for some reason, and you should definitely investigate why. > But definitely go with a single, very efficient container object > instead of using the filesystem as one. Even if you're guaranteed to > be running on a new FS that uses btrees for the directory info, it's > still much faster to do a hash lookup than a btree search, O(1) vs O(lg > N).
I'd actually contradict you here, one of the main problems with the performance of the disk-based ((s)dbm) cache implementation is precisely the fact that it uses a hash-table! It's often misunderstood as being "slower but more stable" because "it's a file". In reality it's not disk-access that's going to *really* slow things down (the db file usually ends up cached in the kernel anyway), and neither is it more stable because of disk-access - for precisely the same reason! :-> The actual performance problem is how to algorithmically expire old sessions flush the database of old data so it doesn't grow without limit - in the case of mod_ssl's dbm-based cache design, these two problems are actually the same problem. The hash-database means the only way to remove expired sessions is to iterate across the entire database! This is the same problem as one of mod_ssl's other cache modes, 'shmht' - though shmht is implemented using shared-memory instead of dbm. The result is that genuine "expiry" operations are only done every once in a while; you lose storage (and memory-caching) efficiency, and you periodically do a very high overhead O(n) search where n is the number of cached sessions. So, if you save each session to a different file I guess it would be possible to use the path to make the expiry logic easier. Eg. each minute in the future has its own theoretical directory (it is only created if its ever needed). When saving a session, you could put it in the directory corresponding to the minute it will be expired. The "current" directory you look at (the "current minute") will contain a mixture of sessions that are just about to expire or have just expired - but any directories representing minutes in the past contain only "old" sessions (you can delete/unlink them whenever you like) and all directories representing minutes in the future contain healthy unexpired sessions. This makes 'expiry' and 'flush' operations O(1), which is hard to beat. Inserts are O(1) too. And if you name the session files according to the sessions' ID, 'lookup' operations (and non-expiry 'delete's) become O(n), where n is the length of the session timeout in minutes (so it's a constant anyway) rather than 'n' growing the number of sessions in the cache. Of course, if you don't want to thrash the disk to hell with this example technique (because this wouldn't benefit from kernel-caching like a single dbm file would), I'd suggest doing it inside a loopback file-system so it's all virtualised in memory anyway. Or you could push session caching out of the server and on to the network; http://www.distcache.org/ Cheers, Geoff -- Geoff Thorpe [EMAIL PROTECTED] http://www.geoffthorpe.net/ ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
