launchpad-dev team mailing list archive

[Robert Collins <robert.collins@xxxxxxxxxxxxx>]

Hi Bjorn, I'm really interested in performance for Launchpad and would
love it if you could expand on the performance figures you saw.

I guess in LEAN terms I'm pressing the little red stop the line button.

>From your LEP page performance section, you see accessing 40 bugs out
of 50K go from 1100ms to 1300ms - an 18% increase and 1/5 of a second
in real terms - per 40 bug page.

Now, if thats as part of a refactoring that should eventually speed
things up, its tolerable, because being stuck in a local minima that
is globally non-minimal would be a pain. I didn't see any implications
that that is the case here though - so if its actually a new overhead
going to be worn everywhere in the system, I think we should measure
some more and think harder about the design to see how we can address
the overheads.

The reason I think that its important to stop and think about this
now, is that real servers often perform *worse* than workstations:
while they have more memory so can handle a larger working set, they
also have more users accessing a greater variety of content
concurrently. So a local workstation test that is slower is usually a
very good sign that it will be slower in production too - unless one
is deliberately designing to make use of a large memory pool for some
task (e.g. bug analysis or something on a dedicated server). We don't
have a 'never make launchpad slower' policy, but I think its very
concerning when a new feature is as dramatically slower as you're
reporting this one is.

I found when tuning commit in bzr 1.0 that there was a hard lower
limit we couldn't get below - we did some full tree XML stuff, and
that required us, under all circumstances, to work with the entire
dataset. So performance work there was tricky, as really there was a
constant overhead affecting the measurements; when that was
eliminated, I could much better evaluate the relative improvements /
costs I was achieving. And it was from that work that we got the
status overheads down as low as it is (over a series of releases - no
magic bullets :().

I wonder if there are similar issues here, as Launchpad is in a
similar place. Perhaps looking at the query breakdown (use the
++oops++ decorator on a URL, and then you'll get an oops logged that
oopstools can analyse for you) might show up where the extra time is
coming from.

If theres anything I can do to help with this - whether reviewing the
design, just chatting on IRC or voice, or whatever - let me know; I
want ACLs, and I want Launchpad to be fast, and I'm sure we can do it.

-Rob