# Removing SQLite sessions from the default distribution

- Thread: https://externals.io/message/3096
- Original archive: https://news-web.php.net/php.internals/3096
- Started by Sterling Hughes on 2003-07-01T19:28:58+00:00
- Messages: 28
- Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL)
- Next page: https://externals.io/message/3096.md?page=2
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #3096 — Sterling Hughes — 2003-07-01T19:28:58+00:00

URL: https://externals.io/message/3096#3096

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

---

## #3103 — Sterling Hughes — 2003-07-01T19:49:42+00:00

URL: https://externals.io/message/3096#3103 · In reply to: #3099

> 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
> 
> 
> > […]
-- 
"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

---

## #3105 — Sterling Hughes — 2003-07-01T19:51:26+00:00

URL: https://externals.io/message/3096#3105

What advantage does it bring?

It is *only* a disadvantage.  It can only hurt users, it can't help
them.  I would be for it if someone gave me a practical usage, no one
has. Its not the right tool for the job.  If you want to shoot yourself
in the foot, PEAR is the place to do that.

-Sterling


> Hello Sterling,
> 
> Tuesday, July 1, 2003, 9:28:58 PM, you wrote:
> 
> SH> Hi,
> 
> SH> Recently sqlite sessions have been added by default.  I think this is a
> SH> bad idea to have as a default handler.  SQLite is not designed for a
> SH> write intensive environment, and encouraging such usage seems to be
> SH> silly.
> 
> This is just a nice option which cases some additional bytes of code and
> source. Why making such a big thing out of this? Will we remove everything
> that is not perfect? Then i'll suggest we remove everything.
> 
> 
> Best regards,
>  Marcus                            mailto:helly@php.net
-- 
"Backups are for wimps. Real men upload their data to an FTP site and have 
 everyone else mirror it." 
    - Linus Torvalds

---

## #3100 — Sebastian Bergmann — 2003-07-01T19:57:12+00:00

URL: https://externals.io/message/3096#3100 · In reply to: #3096

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/

---

## #3099 — Wez Furlong — 2003-07-01T19:57:51+00:00

URL: https://externals.io/message/3096#3099 · In reply to: #3096

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.

---

## #3104 — George Schlossnagle — 2003-07-01T20:15:21+00:00

URL: https://externals.io/message/3096#3104 · In reply to: #3096

> 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

---

## #3116 — Jason Greene — 2003-07-01T20:45:40+00:00

URL: https://externals.io/message/3096#3116 · In reply to: #3096

> 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

---

## #3118 — Sterling Hughes — 2003-07-01T20:51:55+00:00

URL: https://externals.io/message/3096#3118 · In reply to: #3115

> > […]
> 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 of course we should just say 'screw performance' :)  Again, if it
were useful, I would say "yes, totally."  100% and bucket o' bits.  But
it doesn't give you anything, and it can be in PEAR/PECL for those who
really want it. 

I'm not suggesting it never exist (although I would be happier if that
were the case).  What I am saying is that it should not exist by default
in PHP.  Its shooting yourself in the foot without any real world reason
too.

> 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.

Directory hashing is the answer, not putting it all into one file.

> 2) Much easier to find & manipulate sessions outside of normal sessions 
> framework.

When have you needed this?  Also, in the odd chance you do, what's so
hard about:

$data = session_decode(file_get_contents("/tmp/sess_$id"));

> 3) Extremely easy to move sessions from one server to another

tar cfz sessions.tar.gz sessions/

> 4) Marginally more secure then plain files

Not at all.  :)  More files more better, you can have different
permissions on each file, rather than the neive implementation of using
one file for all sessions.  Sure you can use save_path per virtual host,
but that's if you do it.  The default implementation is less secure, and
that's what we have to count on.

-Sterling

> 
> 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.
-- 
"I can't give you a brain, so I'll give you a diploma"  
    - The Great Oz, The Wizard of Oz

---

## #3115 — Ilia Alshanetsky — 2003-07-01T20:56:33+00:00

URL: https://externals.io/message/3096#3115 · In reply to: #3096

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.

---

## #3117 — Jason Greene — 2003-07-01T21:01:21+00:00

URL: https://externals.io/message/3096#3117 · In reply to: #3115

> 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

---

## #3119 — Olivier Hill — 2003-07-01T21:15:27+00:00

URL: https://externals.io/message/3096#3119 · In reply to: #3116

Jason Greene wrote:
> > […]
> I still can not see a functionality difference. As to performance, I
> think it is obvious that file based sessions are faster.

+1

If someone was to include MM session support by default, I would agree 
because it's faster. But including SQLite sessions by default is 
useless. It's not faster, it's not more secure, it's only more overhead 
than file support. Ohh.. and while developping, I sometimes want to do a 
'rm -f sess<id>', it's simple, and it works.

Oliver
-- 
GB/E/IT d+ s+:+ a-- C++$ UL++++$ P++++ L+++$ E- W++$ N- ?o ?K w--(---) 
!O M+$ V- PS+ PE- Y PGP t++ 5-- X+@ R- tv++ b++(+++) DI++++ D+ G++ e+>++ 
h(*) r y+(?)

---

## #3124 — Ilia Alshanetsky — 2003-07-01T21:58:32+00:00

URL: https://externals.io/message/3096#3124 · In reply to: #3118

> So of course we should just say 'screw performance' :)  Again, if it
> were useful, I would say "yes, totally."  100% and bucket o' bits.  But
> it doesn't give you anything, and it can be in PEAR/PECL for those who
> really want it.

No, I certainly do not want to 'screw performance' as you've put it. Just 
playing a devil's advocate for the moment and putting things in perspective. 
The bottom line is that for most applications sqlite performance is adequate, 
same as files. However, when you need that 'ultimate' bit of speed you should 
consider something like shared memory.

> I'm not suggesting it never exist (although I would be happier if that
> were the case).  What I am saying is that it should not exist by default
> in PHP.  Its shooting yourself in the foot without any real world reason
> too.

You and I both know that unless things change dramatically by the 5.0 release, 
PEAR & PECL are pretty much siberia. As people will begin to use sqlite 
eventually they'll surely consider using it for session managment. And 
implement a variety of classes etc... to do essentially what John has created 
for us in C. Why not save our users some time and have it bundled and avoid 
dosens of likely incompatible session managment formats. As long as files 
session handler is default this won't affect anyone and the only people 
who'll end up using sqlite session handling are the ones who think they need 
it.


> > […]
>
> tar cfz sessions.tar.gz sessions/

Certainly, except you forget few minor things, on most hosts all sessions are 
store in one place /tmp and even if you were to do  tar cfz sessions.tar.gz 
/tmp/sess_*. You will pickup lot's of useless files and so on and even then 
you'll need to have permissions to execute the command, which many people do 
not. While with sqlite, all you need to a cp or php's `copy()` command.

>
> > […]
>
> Not at all.  :)  More files more better, you can have different
> permissions on each file, rather than the neive implementation of using
> one file for all sessions.  Sure you can use save_path per virtual host,
> but that's if you do it.  The default implementation is less secure, and
> that's what we have to count on.

By default all sessions (files) are in one place /tmp for all users on the 
server. And most servers will allow users access to /tmp, meaning that any 
user with an account on the server can read anyone's session. But, security 
is a bad, point anyway most of the security issues that apply to files apply 
to sqlite as well.

Ilia

---

## #3130 — Sterling Hughes — 2003-07-01T23:13:49+00:00

URL: https://externals.io/message/3096#3130 · In reply to: #3096

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

---

## #3133 — Sterling Hughes — 2003-07-01T23:31:54+00:00

URL: https://externals.io/message/3096#3133 · In reply to: #3131

>     Having a SQL session storage module in the default
>     distribution is a good learning example for other storage
>     module authors.  I don't see any necessity to remove this
>     particular piece of code based on the assessment that it
>     does not outperform simple file access on Linux.  SQLite

It doesn't give you any benefit, that's my problem.  People will use it
to replace files, when in fact its no good.  Its a fine candidate for
PEAR or PECL, just like the postgresql session handler.  As for a
reference implementation, I've written C session handlers before, and
files or MM are fine for reference implementations. 

>     could very well be faster on synchronous filesystems where
>     creating new files is more expensive than in your testcase.

I highly doubt that, and besides, what percentage of php users use those
filesystems for sessions?  Because session *creation* is not the issue
here.  In real world usage, you would hope most of your time is not
spent creating sessions.  Besides, on a synchronous filesystem, you'll
probably have a much larger disk sync overhead with sqlite (shown by the
benchmark where PRAGMA SET synchronous = ON was set).

-Sterling

> 
>     - Sascha
-- 
"Science is like sex: sometimes something useful comes out, 
but that is not the reason we are doing it." 
    - Richard Feynman

---

## #3137 — Sterling Hughes — 2003-07-01T23:40:20+00:00

URL: https://externals.io/message/3096#3137 · In reply to: #3132

> What is the point of publishing a benchmark if you are not comparing an SQL
> data store with an SQL data store?

Speaking of bullshit comparisons :)

One is a client/server architecture, the other is a direct disk access
architecture.  Using an RDBM gives you tons of other advantages,
including efficient replication (separating read servers from write
servers for example), integration with existing storage systems, etc. 
You actually *win* something when you use a RDBM.

With SQLite sessions you just lose.

> 
> > […]
> 
> Commit it.


Fine.
> 
> > […]
> 
> Huh?
> Thats bullshit.
> session.save_path allows you to configure the database per virtual host.
> There is no restriction that forces an entire server to use the same dir.
> 
> Each server should use a seperate save path anyway (or have you never had
> problems with session collisions between vhosts?).

Does that work currently with sqlite?  If so, then its fine.  I stand
corrected.

> 
> > […]
> 
> This is also pure excrement.
> 
> > […]
> storage,
> > […]
> 
> and everyday users cluster their sessions...

Plenty of non "enterprises" do.

> > […]
> 
> Because it is a single .c file logically grouped with the rest of the
> library that we bundle.

Fine.  Perhaps I should add a export_privates() function to ext/standard
than.  It would export all private class variables into the current
scope.  Just because something fits somewhere, doesn't mean it should be
there.

> 
> If you hate it so much, lets just unbundle the whole sqlite extension.
> 

I don't "hate" SQLite.  I just think right tool for the right job. 
SQLite is not a good *generic* tool for managing sessions, not one
person has given a real world case where this helps them.   Give me one
which has a 'practical advantage' from using a *generic* SQLite, and
I'll stop this discussion.

-Sterling

> --Wez.
-- 
"Reductionists like to take things apart.  The rest of us are 
 just trying to get it together." 
    - Larry Wall, Programming Perl, 3rd Edition

---

## #3138 — Sterling Hughes — 2003-07-01T23:40:42+00:00

URL: https://externals.io/message/3096#3138 · In reply to: #3136

>     Sterling,
> 
>     you have obviously made up your mind already, so arguing is
>     moot.  Let's have a quick vote and move on.
> 
>     Pro removing: Sterling

>     Con removing: Sascha
> 
>     - Sascha
-- 
"Science is like sex: sometimes something useful comes out, 
but that is not the reason we are doing it." 
    - Richard Feynman

---

## #3139 — Sterling Hughes — 2003-07-01T23:42:31+00:00

URL: https://externals.io/message/3096#3139 · In reply to: #3136

Btw, the quickest way would be for you to give me a real world usage -
Happen to have any on your mind?

-Sterling


>     Sterling,
> 
>     you have obviously made up your mind already, so arguing is
>     moot.  Let's have a quick vote and move on.
> 
>     Pro removing:
>     Con removing: Sascha
> 
>     - Sascha
-- 
"That stuff's easy compared to installing Horde" 
    - Alan Knowles, In response to my applause for creating a LALR 
    parser for PHP.

---

## #3131 — Sascha Schumann — 2003-07-01T23:45:12+00:00

URL: https://externals.io/message/3096#3131 · In reply to: #3130

Having a SQL session storage module in the default
    distribution is a good learning example for other storage
    module authors.  I don't see any necessity to remove this
    particular piece of code based on the assessment that it
    does not outperform simple file access on Linux.  SQLite
    could very well be faster on synchronous filesystems where
    creating new files is more expensive than in your testcase.

    - Sascha

---

## #3132 — Wez Furlong — 2003-07-01T23:51:23+00:00

URL: https://externals.io/message/3096#3132 · In reply to: #3103

What is the point of publishing a benchmark if you are not comparing an SQL
data store with an SQL data store?

> I will commit my fixes, if the decision is to bundle sqlite.  Or someone
> is interested in trying it out in the interim.

Commit it.

> 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.

Huh?
Thats bullshit.
session.save_path allows you to configure the database per virtual host.
There is no restriction that forces an entire server to use the same dir.

Each server should use a seperate save path anyway (or have you never had
problems with session collisions between vhosts?).

> 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.

This is also pure excrement.

> > […]
storage,
> > […]
>
> 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.

and everyday users cluster their sessions...

>  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).

again...

> 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?

Because it is a single .c file logically grouped with the rest of the
library that we bundle.

If you hate it so much, lets just unbundle the whole sqlite extension.

--Wez.

---

## #3135 — Wez Furlong — 2003-07-01T23:57:58+00:00

URL: https://externals.io/message/3096#3135 · In reply to: #3118

----- Original Message -----
From: "Sterling Hughes" <sterling@bumblebury.com>
To: <ilia@prohost.org>
Cc: <internals@lists.php.net>
Sent: Tuesday, July 01, 2003 9:51 PM
Subject: Re: [PHP-DEV] Removing SQLite sessions from the defaultdistribution


> > […]
>
> Not at all.  :)  More files more better, you can have different
> permissions on each file, rather than the neive implementation of using
> one file for all sessions.  Sure you can use save_path per virtual host,
> but that's if you do it.  The default implementation is less secure, and
> that's what we have to count on.

Bullshit again.
You can have a session database per vhost and configure the permission of
that database per-vhost.

---

## #3144 — Sterling Hughes — 2003-07-01T23:59:01+00:00

URL: https://externals.io/message/3096#3144 · In reply to: #3143

>     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

---

## #3136 — Sascha Schumann — 2003-07-01T23:59:29+00:00

URL: https://externals.io/message/3096#3136 · In reply to: #3133

Sterling,

    you have obviously made up your mind already, so arguing is
    moot.  Let's have a quick vote and move on.

    Pro removing:
    Con removing: Sascha

    - Sascha

---

## #3145 — Sterling Hughes — 2003-07-02T00:02:09+00:00

URL: https://externals.io/message/3096#3145 · In reply to: #3143

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.

---

## #3143 — Sascha Schumann — 2003-07-02T00:17:43+00:00

URL: https://externals.io/message/3096#3143

Tallied votes so far.

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

    - Sascha

---

## #3146 — Sascha Schumann — 2003-07-02T00:29:17+00:00

URL: https://externals.io/message/3096#3146 · In reply to: #3145

> Wez explained to me a real world usage (over IRC).

    Could not that have happened a couple of hours earlier? :)

    - Sascha

---

Next page: https://externals.io/message/3096.md?page=2