On Tuesday, July 1, 2003, at 03:28 PM, Sterling Hughes wrote:
Hi,
Recently sqlite sessions have been added by default. I think this is a bad idea to have as a default handler. SQLite is not designed for a write intensive environment, and encouraging such usage seems to be silly.
SQLite is bad because:
1) It uses one file for the entire db. Therefore, every time *any*
session is updated, all sessions must be locked. This means that if you
have session a and session b in two separate processes, they must be
updated one at a time, instead of together. Furthermore, this clusters
terribly, requiring all locks to happen on a single file across a
cluster(*).
It also means that if one session gets corrupted, all your sessions will
be corrupted. If a session file gets removed, then you've lost all
your session files.
This is no different than a typical mysql setup using myisam datafiles.
2) It offers not one practical advantage. When asking the proponents of
SQLite based sessions, they said the advantage is that everything is in
one file.
That's the disadvantage.
It's also an advantage from the standpoint of cleanliness and manageability. The ability to identify and whack a session out of band is nice. The biggest possible advantage is that it's a builtin endorsement for sqlite which you lobbied hard for enabling by default just days ago.
Having a single point of access, single point of failure, single point of performance degradation is a never a good thing, especially if it buys you nothing.
This is a pretty vacuous statement. It's clearly true, but doesn't mean much here. The mm session handler is a single point of failure. Using a database is a single point of failure. Having a single webserver is a single point of failure, running on a single AS is a single point of failure. Adding a sqlite db to that list is a rather small addition. If you don't trust the technology, don't use it.
[ ... bench details ...]
With sqlite synchronization enabled, I got ::
files = 410-440 req/s sqlite = 33-35 req/s
With synchronization disabled, I got ::
files = 410 - 440 req/s sqlite = 150-179 req/s
That's a very signifigant slowdown, and it wins you nothing. A base script ::
It should be noted that synchronization is off by default in libsqlite. Having little personal interest in the extension, I haven't checked if that is changed there.
There is plenty of slow stuff in PHP. PHP out of the box is not designed for performance. Most people apps won't see 1 request per second, let alone 10, let alone 150. Anyone who is serious about building a high-performance application should have the good sense to evaluate their options and choose the session mechanism that works best for them. This probably won't be sqlite. But who cares? It's not designed for them anyway (this is paraphrased from one of your own arguments for inclusion of sqlite in php - it's a god alternative for people with basic needs and basic configurations).
3) Writing the code in C gains you nothing. Its not like you'll be gaining req/s if the code is in a C session handler vs. a PHP session handler. The C code is also harder to maintain. For example, in order to prove that sqlite sessions were slow and otherwise crappy, I had to "fix" 3 segfaults in the session handler code, and change the queries around.
That same argument could be made for any of the session hanlders. sqlite is a good candidate for bundling as a 'builtin' handler type because it is
a) enabled by default (largely your doing) b) fully self-contained
As far as fixing bugs in the code to get it to compile - who cares? It's brand new code. There are alot of glass windows around to be throwing those sort of rocks.
(*) You may argue "don't cluster sqlite sessions." That's not a good thing. Fine, don't cluster sqlite sessions, but that's a negative, against sqlite.
Again, you can't cluster mm.
George
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
