launchpad-dev team mailing list archive

[John Arbash Meinel <john@xxxxxxxxxxxxxxxxx>]

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


...

> https://devpad.canonical.com/~lpqateam/ppr/lpnet/latest-daily-timeout-candidates.html
> (internal link - sorry) - is what I use to assess impact. This is all
> pages over 10 seconds for their 99th percentile.
> 
> The drop of 14 to 13 *added* a bunch of timeouts, but we had *also
> fixed a bunch*, so the absolute count stayed flat - which is good:
> we're at a sweet spot: a higher timeout and we're being wasteful,
> which leads to long lived locks, more contention etc. A lower timeout
> and the impact is felt by more users.

"fixed a bunch", meaning that lowering the timeout caused some things
which took longer than 13s to now take less? (because of contention, etc.?)


> 
> I want us to ride this wave all the way down: not too hot, not to
> cold, Just Right.
> 
> -Rob

The log on the graph takes a bit to get used to. Some of those are
pretty interesting. Like "Archive+delete", which has ~95% of all queries
finishing in under 2s, and then the remaining 5% finish in >15s, with
nothing inbetween.

Question:+makebug is similar. Very bi-modal.

If you sort descending on 99% Under Time, why do the high ones end up so
much past the cutoff? Question:+makebug, for example, gives a 99% time
of 42.8s. How does it survive for 30s longer than the cutoff?

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk1vcLsACgkQJdeBCYSNAAOSNQCfWYv0AkecqWIrrAoTLmVVDBMp
EJ0AnRPe3vcrFZx1i+6eaONBKobvw1uO
=KCo5
-----END PGP SIGNATURE-----