On Sun, 6 Jan 2002, Gerald Richter wrote: >> If you use "File" you may do fine when there are 1000 >> files in your sessions directory, but will begin to >> degrade speed as it increases. Perhaps there's a >> subdirectory, index simulating approach I'm not aware >> of. > > Apache::Session doesn't implement such a subdirectory schema, so you really > get a lot of files in one directory. This really slows things down, unless > you use a filesystem that is able to handle such situation more smart, like > ResierFS on Linux does (by using balances trees, instead of doing linear > searches in directories)
Incidentally, ReiserFS also gives you journaling, so your only reasons to use ext3 instead of ReiserFS is you don't want to reformat and you're wanting to use more mainstream code. (At least, I can't remember any other big reasons one might not want to use ReiserFS. My definition of big, of course.) One could implement such a subdirectory schema for Apache::Session, but it wouldn't provide a significantly more efficient solution than using ReiserFS. >> If you use DB_FIle, does it load the whole file into >> memory? No. But only a few handle concurrent accesses correctly, last I checked (which was some time ago). The rest would require a wrapper which provides mutual exclusion, and there goes your performance. (Note that I've not used DB_File with Embperl or anything relating to web pages - I feel much safer using it with serial processing concepts, given that I don't have a concurrent access friendly DB for it.) > I don't know, but you will run into concurrentcy issues, as more as you have > a highly loaded server. I don't recommend to use DB_File for session > handling, unless you use a DB_File version that can handle concurrent > read/write accesses correctly (like the one from sleepy cat, which is not > totaly free) > >> If you use Mysql, you are really moving a lot of data >> around if you're pulling it from a remote server. >> Still, it would be quite quick given you have you >> sessions table set up optimally. > > I think mysql, preferably on the same machine as the webserver, will be (one > of) the fastest solutions for highly loaded server. If you are doing anything non-trivial with the data (that is, stuff other than shoving it around en-mass), I would have to concur (comparing only the choices you've given). Note that MySQL running on a different machine connected with a fast pipe (100 or 1000 Mbps) is generally not as much of a performance degredation as an overloaded machine, and that could enable the use of a web server farm. This also allows for tuning your database server hardware for running a database, and your web server hardware for running web servers. An example of this configuration (although not using Embperl, or mod_perl at all for that matter - if I recall correctly, Brad had issues with the coding of mod_perl) is www.livejournal.com. Ed --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
