On Fri, Aug 24, 2012 at 2:01 PM, Dmitrijs Ledkovs <dmitrij.led...@ubuntu.com> wrote: > On 24/08/12 13:35, Sebastien Bacher wrote: >> Le 24/08/2012 14:25, Oliver Grawert a écrit : >>> "This will let us judge whether the timeouts we're seeing on the month >>> view and sometimes on the day view are caused by talking to Launchpad" >> hum, what does that mean exactly? what is missing when using that option? >> > > I think instead of fetching the bug status & other data from launchpad, > it is using the cache it already had, thus removing the 'timeouts' when > loading large data (e.g. monthly, all-time views). > > Adding ev, to CC to explain.
Thanks Dmitrijs! Hi Seb, Right now the website asynchronously loads the contents of the most common problems table using the web API. This request first gets the problems that have the highest rate of instances from Cassandra, then it asks Launchpad for the status of any linked bug and asks what the most recent published version of the package is. It asks Launchpad for this information to color the table based on whether we thought a problem was a possible regression, already fixed, or had disappeared in the most recent version. The two Apache servers for errors.ubuntu.com have timeouts in handling the request. With the addition of talking to Launchpad, we're now hitting this timeout fairly frequently. Both parts of this were in need of some alteration and optimization. The "highest rate of instances" was determined by just looking for any problem with an instance count greater than 20 in the period specified. This caused a lot of confusion when people switched to the 12.10 day view and suddenly saw no data (because the problems didn't have more than 20 instances). This is fixed in trunk. It now takes the 100 problems that have the highest instance count for the specified period. If seeing more problems than that is a priority, let me know. The actual fetching of data from Cassandra has been optimized in trunk by fetching multiple rows at once. This may require some tuning as fetching multiple rows in a single call can be a very taxing operation on the database. There are likely to be other ways in which we can speed this up. This is just the work of part of yesterday. We use httplib2 for talking to Launchpad's API, as it creates a cache of etags and uses compression to speed things up. I've made some changes in trunk to speed this up further, but I'm still looking into why these queries are still so slow. For now you can use https://errors.ubuntu.com?launchpad=false, which turns off fetching the data for possible regressions, fixed bugs, and disappeared problems from Launchpad. I'm also going to look into separating out the Launchpad query into another asynchronous call. So the graph will load with plain text, then you'll get the coloring. Unrelated, but while I have the attention of the release team, I'm aware that the colors in the most common problems chart are confusing. We're working on making their purpose much more obvious. This is what it looks like in trunk: http://people.canonical.com/~evand/tmp/errors-design-proposed-20120823-1.png Thanks! -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release