On Tue, 2003-07-01 at 15:57, Wez Furlong wrote:
> Sterling, you still seem to be afraid to benchmark sqlite vs mysql or
> postgresql sessions.
I'm not afraid. Its like compare apples with oranges. MySQL and
PostgreSQL are database servers, they give you wins in terms of
reliability, power and data collection. Sqlite is a file abstraction
api, with an SQL interface. I'm comparing apples with apples, not
apples with oranges. With MySQL and PostgreSQL for example, your custom
session handler can integrate with a custom table. You could use
master/slave read/write redirection, etc.
Also, no one has suggested that a mysql or postgresql session handler be
integrated with PHP. If they did, I would oppose that as well.
Actually, the postgresql session handler is PECL (or PEAR) atm. That's
an example of what I mean.
>
> Also, 150+ req/s is more than most people will ever have hitting their
> sites.
You can't look at raw performance on a simple script in terms of req/s,
but rather percentages. Most scripts are complex, and will have plenty
of other logic in them. Having a 1/3 performance decrement can add up.
Also, where is the advantage to SQLite sessions? You've admitted
yourself that there is none.
>
> 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.
I will commit my fixes, if the decision is to bundle sqlite. Or someone
is interested in trying it out in the interim.
>
> 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.
I can argue whatever i please :). You have to use the right tool for
the job. I argue for the inclusion of cURL support, that doesn't mean I
think we should add a HTTP based session handler. SQLite is not the
right tool for this job, that's my point, and I've backed it up
sufficiently.
Where will it be useful? Give me a real world example where using SQLite
sessions will be useful. Where the current system will help you as
opposed to file based sessions. Also note, this would mean that all
shared hosts go to a single sqlite database, instead of a directory.
One site may not get a lot of hits, but an entire shared host would.
This directive is per-php ini, and has to be.
Why would you get your own server to serve one website if performance
wasn't important? You wouldn't. Further, Why would you use SQLite
instead of the files based system? Give me a problem this solves.
>
> Yes, "enterprise" sites would be stupid to use sqlite for session storage,
> but then, enterprise sites probably won't be using sqlite at all.
I'm not talking about enterprise sites. I didn't mention that once in
fact. I'm talking about your every day average people, using php on a
shared host. They wouldn't use sqlite, because it requires that every
person on the shared host use sqlite (and I doubt anyone would use
per-dir).
In general database backends make no sense for sessions support, unless
you want to integrate into a pre-existing architecture, or you want to
cluster (and even then its iffy). The Sqlite sessions supports allows
you to do neither of these things. Its not easier to use, its a 300%
slowdown, and its not nearly as "safe" in shared environments (you can't
have different users for different sessions safely.)
So why add it?
-Sterling
>
> --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.
--
"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
