On Tue, 2003-07-01 at 19:51, Wez Furlong wrote:
> 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 RDB
- Original Message -
From: "Sterling Hughes" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, July 01, 2003 9:51 PM
Subject: Re: [PHP-DEV] Removing SQLite sessions from the defaultdistribution
> > 4) Marginally more
- Original Message -
From: "Sterling Hughes" <[EMAIL PROTECTED]>
To: "George Schlossnagle" <[EMAIL PROTECTED]>
Cc: "Wez Furlong" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; "Sascha
Schumann" <[EMAIL PROTECTED]>
Sent:
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 hos
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 yo
On Tue, 2003-07-01 at 16: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
> unatt
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
> unatta
> 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
> My point being that 1/3 slowdown seems to be about worst case, given
> the construction of your benchmark. The test was both designed to
> exploit lock contention (which does increase in overhead non-linearly
> under usage due to the queueing issues involved) and to measure only
> the overh
On Tue, 2003-07-01 at 16:33, George Schlossnagle wrote:
> On Tuesday, July 1, 2003, at 04:00 PM, Sterling Hughes wrote:
> > On Tue, 2003-07-01 at 16:15, George Schlossnagle wrote:
> >> On Tuesday, July 1, 2003, at 03:28 PM, Sterling Hughes wrote:
> >>
> >>
> >> This is no different than a typical
On Tue, 2003-07-01 at 16:08, Elfyn McBratney wrote:
> On Tue, 1 Jul 2003, Sebastian Bergmann wrote:
>
> > 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 S
On Tue, 2003-07-01 at 16:20, George Schlossnagle wrote:
> On Tuesday, July 1, 2003, at 03:49 PM, Sterling Hughes wrote:
> > 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
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 inte
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
On
On Tue, 2003-07-01 at 15:57, Wez Furlong wrote:
> 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 da
15 matches
Mail list logo
