Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:3117
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
To: ilia@prohost.org
Cc: Sterling Hughes <sterling@bumblebury.com>, internals@lists.php.net
In-Reply-To: <200307011656.33332.ilia@prohost.org>
References: <1057087738.1360.216.camel@hasele>
	 <200307011656.33332.ilia@prohost.org>
Content-Type: text/plain
Organization: 
Message-ID: <1057093281.6996.33.camel@halcyon.workpc.tds.net>
Mime-Version: 1.0
Date: 01 Jul 2003 16:01:21 -0500
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Removing SQLite sessions from the default
	distribution
From: jason@php.net (Jason Greene)

On Tue, 2003-07-01 at 15:56, Ilia Alshanetsky wrote:
> 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.

If too many files in a dir became a problem, directory hashing could
easily be implemented into the file based handler.

> 2) Much easier to find & manipulate sessions outside of normal sessions 
> framework.

This I can maybe see, however I am not sure what the practical reasons
are to dig through a session database, besides perhaps deleting old
sessions, and that is something easily done with file sessions

> 3) Extremely easy to move sessions from one server to another

I really can't see why you would want to do this.

> 4) Marginally more secure then plain files

This reminds me of an argument I had with an unnamed firewall vendor
that storing an entire site security policy all on one box was ok
because its compiled. There really is no security difference here.


> 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.

I think you will still see a significant performance difference between
file and sqlite

-Jason

-- 
Jason Greene <jason@inetgurus.net>
             <jason@php.net>