On Sat, Nov 12, 2011 at 4:01 AM, Aaron Bentley <email address hidden> wrote:
> I think most of the time the user *will* be following these links.  Not
> all of them, but at least the next link.  I say "I think", because I
> don't have the actual data.  Do you?

next is plausible. We have enough data in our logs to run an analysis
if desired. I don't know at what % of times someone clicking next
would be enough to justify calculating and throwing away a search
result.

In the datacentre, getting https://bugs.launchpad.net/ubuntu/+bugs via
wget - 3.04seconds to generate, 3.129s end to end - the primary reason
round trips are slow on bug searches is that the bug search batch
generation is slow. For me locally.
https://bugs.launchpad.net/launchpad/+bugs just took 2.2s to render
and 4.2s end to end. So the round trip component for me is ~2 seconds,
and the time spent on a service point doing the generates was 2.2
seconds. If there was eager loading then I could click next and get it
immediately *after another 4 seconds*. Clicking next twice in a row
would still be slow. And if I don't click next, then the computation
is wasted.

Google have made a few big presentations recently about eager loading
and discarding results to get a very very snappy UI. Thats pretty
cool, but they (AFAIK) only do it on search - they don't do it for
google code bug reports, nor for gmail. They are also doing it because
it brings them revenue - the more searches folk do the more time they
spend searching, according to their in-house research... and the more
adverts folk see. I don't know if the google presentations have
influenced this bug, but if they have - I think the goal is great, but
I don't think the situations are similar.

If doing another batch was a cheap operation, I would have no concerns
about us having everyone that searches do a second batch automatically
(though I would suggest you just send the second immediately, because
/most/ of our search results don't deliver incrementally from the DB;
grabbing 150 items at once is much cheaper than two x 75.

https://devpad.canonical.com/~lpqateam/ppr/lpnet/latest-monthly-pageids.html
shows that
Person:+bugs was hit 470K times in the last month, with a mean render
time of 0.36 seconds (most persons have few related bugs). Thats about
2 CPU days of time on our cluster. If next is rarely clicked, we'll be
doubling that; if its often clicked, the overhead of eager-loading
(just next) will be inconsequential. So the impact ranges from 'does
not matter' to 'matters quite a lot'.
DistributionSourcePackage:+bugs 	114K times with avg 0.71 - about one CPU day.
Product:+bugs - 53K times, avg 0.71 - 1/2 CPU day.
SourcePackage:+bugs 43K @ 0.35s - 0.17 CPU days
Distribution:+bugs 20K @ 3.76 for 0.86 CPU days
MaloneApplication:+bugs 13K@6s - 0.9 CPU days
DistroSeries+bugs 10K@1.18 - 0.13 CPU days
ProductSeries:+bugs 5.5K@0.23 - 0.01 CPU days
ProjectGroup:+bugs 4K@0.73 - 0.03 CPU days

TBH I had expected rather more page impressions on bug search. And
this doesn't discriminate between batch retrieval and surrounding UI
as yet. Nevertheless, summing the current figures: we spend 3.6 CPU
days a month processing +bugs, or ~10% of a CPU. This is shared
between appservers and DB, roughly 50-50.
If we increased that by 10 fold (all links), we'd be taking up an
additional 0.45 cores in our DB cluster, which is not very scalable at
the moment, and is very expensive to scale.
Doubling it (direction-of-travel eager loading only) would be much
more modest and I suspect we can support that without additional
hardware today if we need to.

However, I believe this is premature optimisation - we would be better
off investing in faster search generation than in doing the work
speculatively, *at this point*.

-Rob