SQLite sessions are a good idea, however this is a problem with your implementation. Because during inserts/updates sqlite locks the entire database unless you turn of synchronization session mechanism will be extremely slow. My earlier tests, showed 10-15 new sessions per second with synchronization enabled. However, once you turn off synchronization you get a much more respectable 70-80 new sessions per second and up to 100 existing session hits per second. The idea would be that when you initialize the session database for the 1st time you would run "PRAGMA default_synchronous=OFF" query, which would disable synchronization for that database permanently. Additional speed may be gained by using memory only table, that would be persistent for as long as the webserver (Apache) is alive. You can also try using the cache_size option to gain additional speed, under heavy load it may yield additional 5-10 requests per second.
Ilia On June 29, 2003 10:43 pm, John Coggeshall wrote: > Since SQLite will be bundled in the future, I sat down and got > acquainted with it by writing a module for the session extension which > allows users to store their session data in a SQLite database*. > > To use, just apply the patch to session.c (which adds the reference to > the new module and adds the mod_sqlite.c to config.m4) and compile.. To > use it set session.save_handler = sqlite. > > comments welcome. > > John > > * = http://www.coggeshall.org/php/mod_sqlite.php > -- > -~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~- > John Coggeshall > john at coggeshall dot org http://www.coggeshall.org/ > -~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
