>From a performance standpoint you are correct, SQLite looses to files. The actually performance seems to be quite drastic (very surprising to me). That said, keep in mind that for most applications even 150 requests/second is an unattainable limit anyway. For example smarty templating system demo peaks at about 2.5 requests/second and phpMyAdmin front page does a whooping 10 requests/second and a list goes on an on. So what do we do, I still think having sqlite session handler is a good idea especially since all the tools necessary for it's operation are bundled by default. Not so with MySQL and PostgreSQL which require working server, password, logins etc... Which is why I believe we should still keep in the main trunk rather then move to PECL. As far as sqlite session handling benefits go, there are several: 1) Single file vs many file (rm -f will fail if there are too many files in a particular directory), which makes for easier maintenance. 2) Much easier to find & manipulate sessions outside of normal sessions framework. 3) Extremely easy to move sessions from one server to another 4) Marginally more secure then plain files
Ilia P.S. On the benchmark note it should be mentioned that the sqlite session handler does appear to use indexes, which could explain why session lookups are so slow. But it may average out, since that would make inserts faster. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
