dynamic bug listings do round trips for new batches

[Aaron Bentley]

Dynamic bug listings always make http requests for new batches, even though the number of batches a user can request from a given batch is extremely limited. Instead, we should pre-fetch batches that are likely to be requested soon, such as the next, previous and different orderings.

[Robert Collins (lifeless)]

Uhm lets not do this, This will increase server load and most of the
time the user won't be following those links.

[Aaron Bentley (abentley)]

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?

[Robert Collins (lifeless)]

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...

[Aaron Bentley (abentley)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11-11-11 01:57 PM, Robert Collins wrote:
> 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.

Next is a special case, because you can also just double the initial
batch size and hide half the results. Or indeed, we could halve the
displayed batch size, because 75 rows is >4 screenfuls on a 1080p
monitor, and that's quite excessive if the bug listings are just as
responsive as scrolling.

> 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.

If, as you later implied, half of that is appserver time, shipping
JSON across the wire might be cheaper. My best-of-3 nova/+bug time is
2.50s, while best-of-3 nova/+bug/++model++ is 2.27. However, there is
a lot of variation.

> 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*.

Ah, you mean that once the browser receives the page, it will
pre-fetch the results, and that will take another 4 seconds, eh?

This is true, but I assume the user will look at the results before
clicking next, so it will still be faster than otherwise.

This is also an argument in favour of shipping the next batch
simultaneously with the initial page load, per "Next is a special case..."

> Clicking next twice in a row would still be slow.

(I assume you mean clicking next once, and then clicking it again
before the we could pre-fetch the new next result, i.e. the 3rd batch.)

True, but I don't think that's the common case. As above, I assume
the user will look at the results before clicking "next". So I'd
expect that only happens when the search is very poorly selected. We
could also consider pre-fetching even more batches.

> And if I don't click next, then the computation is wasted.

You could also see it as an investment in reducing overall latency.

> 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.

No, they haven't influenced me. I'm thinking more of Facebook and
other ajaxy sites. Facebook's photo viewer, for example, is a joy to use.

> 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.

Just how few related bugs do people have? If it's less than 75 on
average, t...

[Martin Pool (mbp)]

On 12 November 2011 02:01, 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?

I barely ever look at the second page of results: if my search results
weren't good enough I will either tweak my search or more likely do
another search through my mail or through google.

I guess you could look at the access logs to see how often people
actually proceed to the next page?

If people rarely click that link there is not much point doing work or
spending cpu time to preload it.

--
Martin

[Aaron Bentley (abentley)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11-11-16 03:36 AM, Martin Pool wrote:
> On 12 November 2011 02:01, 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?
>
> I barely ever look at the second page of results: if my search
> results weren't good enough I will either tweak my search or more
> likely do another search through my mail or through google.
>
> I guess you could look at the access logs to see how often people
> actually proceed to the next page?

That's what I was thinking of when I said "actual data".

> If people rarely click that link there is not much point doing work
> or spending cpu time to preload it.

I often click the link. Anecdotes are interesting, but they don't
prove anything.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk7D3m4ACgkQ0F+nu1YWqI3euwCeNSO9DOGwtdb8xp31781yKEaB
CNAAnR1ck2OXaG1/Jsci3MgcplPvjHKm
=Q751
-----END PGP SIGNATURE-----

[Martin Pool (mbp)]

>> I guess you could look at the access logs to see how often people
>> actually proceed to the next page?
>
> That's what I was thinking of when I said "actual data".

I was curious so I looked at recent access data:

In the window I looked at (current logs from soybean, all instances),
there were 30370 total requests for +bugs, and 390 of those had a
start= parameter. So naively it's about 1.2%.

Many of them are Googlebot, various other bots, or the
python-launchpad-bugs pseudo-api-client (which is scraping a huge
amount of data).

With them cut out it's down to 5887 requests in the window I looked
at, and only 67 requests from humans for pages after 0, so as it
happens that's still about 1.1%.

If those numbers are correct, then the 'next' link is rarely clicked
and it will not be worth preloading it.

[Launchpad QA Bot (lpqabot)]

Fixed in stable r14352 <http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/14352>.