-----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, there won't be any "next" to fetch.

> However, I believe this is premature optimisation

I believe that your round-trip-time is too slow, all by itself.  We
should be aiming for 100 ms where we can achieve it.

http://www.useit.com/alertbox/response-times.html

That's the kind of responsiveness that will make users love us.  I
know of no way we can achieve that response time without pre-fetching.
 So I don't think this is premature.

> - we would be better off investing in faster search generation than
> in doing the work speculatively, *at this point*.

Both of these approaches can improve the user experience.  If we do
pre-fetching, then faster search generation becomes a way to reduce
initial load time and save money by reducing hardware requirements.

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

iEYEARECAAYFAk69jIkACgkQ0F+nu1YWqI1ZWgCfeODzXWFzPoy++3CQlreUaSaq
BN0AnRFaMDxT48goMdfSiL+cUzj6R2kU
=K5b+
-----END PGP SIGNATURE-----