On Tue, 2003-07-01 at 16:15, George Schlossnagle wrote:
> 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.
>
Is mysql session handling bundled? Talking about prior art, postgresql
sessions weren't included. Also, there is a much bigger advantage to
using postgresql sessions than sqlite sessions.
See my message to Wez as to why they are more useful.
> >
> > 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.
>
What do you mean (re the first)? You can remove files just as easily.
rm -f /tmp/sess_id
or
rm -f /tmp/sess_*
versus what?
rm -f /tmp/sessions
where you are forced to remove all sessions.
>
> >
> > 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.
>
Right. But using MM provides an advantage. Using a webserver provides
an advantage. Using sqlite for sessions provides *no* advantage.
> >
> [ ... 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).
But why should we be slower for no good reason. You need to have a
reason to add something. PHP is not the most stable language by
default. Does that mean I should add a function that deliberately
crashes PHP? Of course not.
SQLite sessions have no advantage, only disadvantages. Your argument
only works when things are useful. SQLite sessions are not useful. No
one has given me an argument for where it is better to use a sqlite
session than a file based session.
> >
> > 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.
>
Again. Code shouldn't be added because it can be added. There is no
advantage to using SQLite sessions, so why have them by default? its a
trivial php implementation if someone really wants to use it. My point
is that there is further no advantage to having them written in C (like
it would be for a rot13 function to improve speed).
>
> > (*) 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.
But mm will give you a speed boost. It has a practical advantage.
SQLite has none.
-Sterling
>
> George
--
"People can have the Model T in any colour -- so long as it's black."
- Henry Ford
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
