Sterling Hughes wrote:

It offers not one practical advantage.

I though the same, the SQLite euphoria should not be taken too far.

+1 for removing the SQLite Session Save Handled from the default
distribution.

--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/

Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-php5.de/

Sterling, you still seem to be afraid to benchmark sqlite vs mysql or
postgresql sessions.

Also, 150+ req/s is more than most people will ever have hitting their
sites.

Yes, so you fixed some segfaults (are you going to commit that?) but keep in
mind that the code is in the HEAD branch and was only written this morning.

You can't argue for bundling of sqlite and then argue against the inclusion
of some simple C code that provides a feature that some people will find
useful, even if you don't find it useful.

Yes, "enterprise" sites would be stupid to use sqlite for session storage,
but then, enterprise sites probably won't be using sqlite at all.

--Wez.

----- Original Message -----
From: "Sterling Hughes" sterling@bumblebury.com
To: internals@lists.php.net
Cc: "Sascha Schumann" sascha@schumann.cx; "Wez Furlong"
wez@thebrainroom.com
Sent: Tuesday, July 01, 2003 8:28 PM
Subject: [PHP-DEV] Removing SQLite sessions from the default distribution

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.

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

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

• 1

One thing I would like to point out here, is that a session backend is
transparent to the user. As long as their sessions are stored, and the
api works, they really don't care. So why would we want to use a
different embedded technology? The only logical reasons are: it offers
more functionality, or it is better performing.

I still can not see a functionality difference. As to performance, I
think it is obvious that file based sessions are faster.

-Jason

--
Jason Greene jason@inetgurus.net
<jason@php.net

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.

Not to reply to myself, however, one thing I have not heard this time is
a real world usage of this functionality. One case where "you" (ie,
someone on the list) would extract a benefit from using the SQLite
backend. Give me a problem that using SQLite as a generic session
backend will solve your problem better, or in a way that files or MM
can't.

I don't think that's much too ask. If you can't think of one, then move
it to PEAR/PECL. If we are including this functionality by 'default,'
there needs to be some usage, besides slowing down your application, and
making your processor red hot.

-Sterling

PS: Some people seem to be confused by what I meant as default. I meant
default in the sense that its always available, always compiled into
PHP, not default like its used by default.

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
--
"C makes it easy to shoot yourself in the foot; C++ makes it harder,
but when you do, it blows away your whole leg."
- Bjarne Stroustrup

Tallied votes so far.

Yay: Sterling
Nay: John, Marcus, Wez, Sascha
Abstain: Jani

• John

He hasn't given his opinion in this thread.

-Sterling

- Sascha

--
"Programming today is a race between software engineers stirring to
build bigger and better idiot-proof programs, and the universe trying
to produce bigger and better idiots. So far, the universe is winning."
- Unknown

Wez explained to me a real world usage (over IRC). I still think its a
terrible idea, but I'll drop it .

-Sterling

Tallied votes so far.

Yay: Sterling
Nay: John, Marcus, Wez, Sascha
Abstain: Jani

- Sascha

--
"That stuff's easy compared to installing Horde"
- Alan Knowles, In response to my applause for creating a LALR
parser for PHP.