-----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----- _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
