Re: [boost] [trac] Website performance, and disabling the code browser?

Subject: Re: [boost] [trac] Website performance, and disabling the code browser?
From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2010-11-28 17:30:25

On Mon, Nov 29, 2010 at 4:31 AM, Artyom <artyomtnk_at_[hidden]> wrote:
>
> I don't think trac is slow because of database, it is just
> slow it is written in Python and it is very slow.
>

I don't think the discussion was about Trac being slow. The point was
that "Database Lock" errors happen pretty often now.

> It is quite big misconception that DB is bottle neck.
>
> If some searches are slow you may need indexes switching DB would not help.
> but other then that, Sqlite3 is VERY fast and I don't think.
>

Sorry, but SQLite is not fast enough if you have multiple processes
trying to perform the same query on the same database. The reason is
because of the database locking mechanism that the SQLite library
enforces on the database file.

If you had a single process and multiple threads and serialized all
access to the SQLite DB on a single thread then that would perform
better. Unfortunately Trac wasn't implemented this way and everything
that happens within the WSGI handler is blocking -- also consider that
Boost has thousands of tickets and multiple query types, most of which
have JOIN's IIRC.

SQLite is fast if you had enough memory to put the whole DB in memory,
and only ever performed primary key query lookups. Introduce JOINs and
then you run into trouble.

> Once I did tests with Wordpress and it could generate 4-5 pages per second
> when if I separated all SQL queries and executed them (about 20 per page)
> I could run about 20x1000 queries per second. So I would not start
> from blaming Sqlite.
>

But wordpress doesn't do JOINs and only ever does simple selects and
sorts on indexes. See how Trac does it and you'll see why SQLite is
the wrong choice for any sufficiently large installation.

HTH

-- 
Dean Michael Berris
deanberris.com