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.
On Tue, 2003-07-01 at 15:28, 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.
>
> 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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
