Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:3096
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
To: internals@lists.php.net
Cc: Sascha Schumann <sascha@schumann.cx>,
	Wez Furlong <wez@thebrainroom.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-ID: <1057087738.1360.216.camel@hasele>
Mime-Version: 1.0
Date: 01 Jul 2003 15:28:58 -0400
Subject: Removing SQLite sessions from the default distribution
From: sterling@bumblebury.com (Sterling Hughes)

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.

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.

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.  After fixing the extension (the CVS version is
broken), I did some benchmarks on the following script:

<?php
mt_srand();
session_id(mt_rand(0, 300));
session_start();
if (!isset($_SESSION['counter'])) {
        $_SESSION['counter'] = 0;
} else {
        $_SESSION['counter']++;
}
echo $_SESSION['counter'];
?>

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 ::

<?php
echo $i++;
?>

Gets 520 req/s on my machine.

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.

If we want SQLite sessions, I submit this should be in a PEAR class or a
PECL handler (like with PostgreSQL).  SQLite sessions should not be a
recommended method, they don't gain you anything, and at the same time
they hurt you performance-wise.  Having users who really want it, go:

# pear install SQLite_Session

Is not a hard cross to bear, and considering that sqlite enabled
sessions should be avoided in the first place, I think its a bad idea to
include them by default.

-Sterling

(*) 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.

-- 
"Nothing is particularly hard if you divide it into small jobs." 
    - Henry Ford