819348 - balrog dev is bursting with releases

Status: RESOLVED FIXED

(Release Engineering :: General, defect, P2)

Description

[[e-mail] (:bhearsum)]

I tried to load https://aus4-admin-dev.allizom.org/releases.html today and got a Service Unavailable after 30 seconds. It's able to load on occasion, but we need to make these page loads faster. I haven't profiled anything, but I'm going to guess that whatever query is happening to load all of the release names is really expensive. We may want to load N and then load more on demand rather than loading all of them?

Peter, this isn't directly related to the frontend but I figured I'd cc you anyways.

Comment 1

[Nick Thomas [:nthomas] (UTC+12)]

Attachment: Don't try to read all the json data

We don't actually use the json part when building releases.html, instead offering a link to it, so don't bother with the expensive parsing. This should help building the page.

Comment 2

[[e-mail] (:bhearsum)]

Comment on attachment 733215 [details] [diff] [review]
Don't try to read all the json data

Review of attachment 733215 [details] [diff] [review]:
-----------------------------------------------------------------

Wooo, this will be nice to have fixed!

::: auslib/test/test_db.py
@@ +747,5 @@
> +        self.assertEquals(releases, expected)
> +
> +        releases = self.releases.getReleaseInfo(product='a', version='b')
> +        expected = [ ]
> +        self.assertEquals(releases, expected)

It looks like these are separate tests under the same name. Can you split them out? r=me with that

Comment 3

[[github robot]]

Commit pushed to master at https://github.com/mozilla/balrog

https://github.com/mozilla/balrog/commit/a1e129fcf1782f254ce6dad8005564b7c039ab1b
Bug 819348, /releases.html should still load when there are lots of releases, r=bhearsum

Comment 4

[Nick Thomas [:nthomas] (UTC+12)]

The commited patch addressed Ben's comment so differs slightly from the attachment here.

https://aus4-admin-dev.allizom.org/releases.html loads now. It returns 600KB of html for our 1959 releases, so gzip compression might be work looking at in the future.