Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:3104
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Date: Tue, 1 Jul 2003 16:15:21 -0400
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v543)
Cc: internals@lists.php.net,
 Sascha Schumann <sascha@schumann.cx>,
 Wez Furlong <wez@thebrainroom.com>
To: Sterling Hughes <sterling@bumblebury.com>
In-Reply-To: <1057087738.1360.216.camel@hasele>
Message-ID: <BDE009BA-AC00-11D7-B5D4-000393B2B3C0@omniti.com>
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Removing SQLite sessions from the default distribution
From: george@omniti.com (George Schlossnagle)
References: <1057087738.1360.216.camel@hasele>


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