Updating bug heat is expensive

[Graham Binns]

What happens:
The bug heat updater code in garbo-daily blocks on other DB activity, which means that it can take a spectacularly long time to run (e.g. in 20 hours on staging it had updated 286k out of ~510k bugs).

What should happen:
Bug heat updating should run more efficiently, probably in a batched manner, possibly concurrently given the number of bugs that need updating (and the fact that this number will only keep growing).

[Gavin Panella (allenap)]

The calculation of bug heat is now driven by a jobs system, not a periodic all-of-the-database recalculation using the DBLoopTuner. This bug was filed in response to the latter.

[Robert Collins (lifeless)]

I'm reopening this because slow and inefficient is expensive : we have to buy hardware to support such tasks.

We should make bug heat totally deterministic on the bug itself and constant irrespective of date - so that we don't need an expensive process to update it.

Calculations for where the flame boundaries are may need improving too in order to be very cheap - e.g. store the range delimiters in the bug context - which would permit examining just the first 100 bugs in a context to update the range delimiters, and we could do that on-demand when a bug context has bugs within it change, IFF the bug's heat is above the lowest range delimiter. This will also solve a usability problem that the distro developers have reported with the allocation of flames not handling contexts with a few very high visibility bugs.

[Stuart Bishop (stub)]

Parallel garbo and improved timeouts will help here.

[Deryck Hodge (deryck)]

Just want to point out that "constant irrespective of date" runs counter to what users said they wanted as we developed bug heat. The reason for this bit is so that the hot bugs list on a bugs homepage for a project or package see very little change without the variation in heat by days of activity. I suspect if the bugs homepage was changed to not have a hot bugs list, somehow to show interesting bugs in a different way, or to treat "hot bugs" as a secondary list on the page, then this aspect of heat would be less useful or required.

[Robert Collins (lifeless)]

Thanks for noting that Deryck. I think we can do some cheap tests: I
have a theory that we're not giving them that variety now - see for
instance the lp hot bugs page which is essentially static.

[Robert Collins (lifeless)]

Further to that, we have to find a way to support what users want/need without terrible DB performance: rewriting the bugs table even weekly causes -huge- database bloat and IO issues; so its something we have to change somehow.