launchpad-dev team mailing list archive

[John Arbash Meinel <john@xxxxxxxxxxxxxxxxx>]

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


...
> It does happen yes. We may be able to come up with something better,
> but I can't tell if you are saying:
> A 'no do not do this, we prefer accuracy and timeouts'
> or
> B 'if you can do better than you describe that would be awesome'
> or
> C 'have you considered the psychological impact of this corner case'
> 
> For A, I think most folk disagree; for B I don't have anything better
> to offer yet, not doable in the short term [and these queries we're
> trying to handle are sitting at 6+ seconds *hot*]. For C, yes I have;
> I think its a fairly rare corner case, tolerable if we documented, and
> certainly something we can improve on in future [but requires more
> work].
> 
> -Rob

What is the runtime for queries that are <100 entries, like the number
of critical bugs in bzr right now (sitting at 1 unless I'm mistaken).
Sure the number is 6s hot-cache for all-ubuntu-bugs, but that is exactly
where this table works well.

I guess the point is. You've clearly defined a great way to scale up to
Ubuntu scale numbers. How do we scale it down to very accurate numbers
when they are small.

For example, if it takes 10ms to get back a result from this table
saying "you have <10 bugs", can we turn around and do the real query to
get the absolutely-accurate number? AJAX Log for
'bugs.launchpad.net/bzr' said that updates were 1.27s and 1.7s (And then
it updated the Bug portlet, so I assume that those are related)

For /ubuntu it did say about 6-7s for me yesterday (7.86s for me today,
and an 11.33 503 Service Unavailable). The numbers did fill in, so ID:0
seems to be the bug portlet request.

Back to the point. I don't know how that query is generated, if it is
asking for all the different statuses concurrently, or sequentially, or
whatever. But if it is feasible to migrate from "fast, but slightly
inflated" to "fast, and accurate for small numbers", that would be a
great place to end up, and certainly reasonable to migrate to the
intermediate.

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

iEYEARECAAYFAk2msXkACgkQJdeBCYSNAANMWwCeJGbZQ0eHyGMrhDr4r0I06Co3
PI8AnRkKygyNUuM9Kg0lcnfH9YH24sc5
=sikK
-----END PGP SIGNATURE-----