launchpad-dev team mailing list archive
-
launchpad-dev team
-
Mailing list archive
-
Message #05570
Re: next steps on codebrowse
-
To:
launchpad-dev@xxxxxxxxxxxxxxxxxxx
-
From:
Max Kanat-Alexander <mkanat@xxxxxxxxxxxx>
-
Date:
Wed, 10 Nov 2010 18:11:23 -0800
-
In-reply-to:
<AANLkTi=pkVsu3wpDXto1-pyV2AJ7yhaJtpu0ppuSkcz_@mail.gmail.com>
-
Organization:
Bugzilla Project
-
User-agent:
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Thunderbird/3.0.10
On 11/10/2010 06:04 PM, Martin Pool wrote:
> * make a 1.18 branch and tarball; in future this will get only safe
> bugfixes and Launchpad should deploy this until a 1.19 is stable
This should be happening later today or tomorrow, and I'll email the
list in a separate thread about it when it's done.
However, I do need to know exactly what revision of loggerhead
Launchpad is currently running.
> * turn off per-line annotations in the default view
Yep, and I think that this will solve quite a few of the existing
performance problems. Basically all that will happen is that the
"Revision" column of the default view will disappear unless you choose
to see it, probably by clicking on a new text link at the top of the page.
After this, I may also remove the "Latest Rev" and "Last Changed" view
from the default "Files" view, which would mean that we wouldn't have to
go into bzr's history at all for two most-used pages in Loggerhead.
> * add a 'just plain text' view
Yes, although as mentioned when we discussed this before, there are
security concerns. I've dealt with such concerns thoroughly in another
app with much higher security requirements, though, so I know how to
deal with it.
> * work with http caches - suggested refresh interval, perhaps etag
Yeah, etag at least. Expires is a bit more questionable for dynamic
pages, but the etag will do most of what we need in terms of making the
actual performance difference, I think.
> * performance/memory usage serving a single page
Well, more than serving a single page, running as a single thread. The
problem right now is that loggerhead is heavily dependent upon its
in-memory cache that it shares between its threads in order to have
decent performance. Removing the revision data from some of the default
views (and possibly improving interactions with bzr-history-db) will
make a big difference here, though.
-Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.
Follow ups
References