release v2 page in the admin ui is very slow

Question

release v2 page in the admin ui is very slow

Opened this issue a year ago · 9 comments

Going to any release page in the admin ui, e.g. https://balrog.services.mozilla.com/releases/Firefox-mozilla-central-nightly-latest/v2, makes a request to https://aus4-admin.mozilla.org/api/v2/releases, which takes forever (about 30s for me). It seems wasteful to query the entire list of releases here...

I'm not sure whether this is entirely an UI problem or if it requires new API to fix.

Answer 1 · 2023-10-05T09:05:52.000Z

i would love to work on this issue kindly assign me

Answer 2 · 2023-10-05T09:28:32.000Z

Relatedly, https://balrog.services.mozilla.com/releases/ also makes a request to the releases list, which makes more sense, but which I'm seeing time out after 1 minute, and return 502.

Answer 3 · 2023-10-05T16:43:28.000Z

I don't think this needs API changes. I should be possible to pass the release name to the endpoint I think? (it's displayed at the top of the page)

https://aus4-admin.mozilla.org/api/v2/releases/Firefox-mozilla-central-nightly-latest

Answer 4 · 2023-10-05T17:35:52.000Z

The UI also does that request for the specific release's contents, but it gets some extra metadata from the "give me all releases" endpoint.

Answer 5 · 2023-10-11T19:17:41.000Z

@ademolaomosanya are you applying for outreachy?

Answer 6 · 2023-10-11T19:24:54.000Z

We are letting applicants work on whatever issues are available, and not worry about being assigned to things (in part because there's more contributors than issues.) The experience is valuable to everyone (even if an applicant's pull-request is not the one that ends up merged.)

Answer 7 · 2023-10-12T13:22:15.000Z

Just for the record, I'm not sure this is a frontend issue, at least not exclusively. There may be cases where we can avoid hitting this endpoint altogether, but the root problem is that the /api/v2/release is incredibly slow.

Answer 8 · 2023-10-12T13:44:16.000Z

@ademolaomosanya are you applying for outreachy?

yes

Answer 9 · 2023-10-12T13:46:12.000Z

One factor here is that we're never started removing stale releases from the v2 table, like we do for v1. Doing that would go a long way to speeding this up.

One hitch here is that we'll want to make sure we remove any associated data from GCS as well (which is where the actual release blobs are stored for v2 releases). This is likely to involve some manual GCS endpoint manipulation, as the db.py classes will not remove any data from it.