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-12-01 10:12:48

On Wed, Dec 1, 2010 at 10:53 PM, Jim Bell <Jim_at_[hidden]> wrote:
>
> Is it my imagination, or is Trac working much better today than ever
> before? Did you do something big? Little?
>

>From where I'm at this side of the world (GMT +8, specifically the
Philippines) I don't see a difference -- it's always been slow for me,
multiple second waits on any action I make. Might be an Internet thing
which I won't be able to do anything about short of moving 1 hop to
the datacenter where it's located, and that's really cost prohibitive
if I just want to contribute to Trac tickets. ;)

>
> On 1:59 PM, Rene Rivera wrote:
>> It would also require that *all* of the Boost web services be switch
>> to using a cache proxy. As they all currently live on the same server,
>> and you can't share ports.
>>
>>> Is the Trac Wiki hosted on SQLite too? Or is the Wiki storage system
>>> external and doesn't touch the SQLite database?
>>
>> The entire Trac DB is SQLite.. which is annoying since one item I
>> noticed is that it also means cookie storage is in SQLite and many of
>> the stack traces I've seen when the database lock error happens is in
>> the cookie reading/writing.
>
> Might cookies be stored in an SQLite memory-only table, with some of the
> streamlining pragmas applied just to it?
>

Sorry Jim, but if you want to make this happen you're going to have to
patch Trac itself, introduce the pragmas, optimize the DB schema as
well and then maintain that unless you get that patch into the Trac
mainline.

It's not as easy as it sounds, putting the pragma's in especially with Trac.

Unless you've done this before and have specific advice, in which case
I think that would be really welcome in this case. :)

-- 
Dean Michael Berris
deanberris.com