Description of problem:
lists *all* builds that were ever done. For such coprs, this is an easy mechanism to generate lots of unneeded traffic.
On my machine, after a few minutes, this page is still generating.
What's worse, after a build is submitted, the user is automatically redirected to this page, so it's pretty easy to end up on it even without wanting to.
A partial workaround would be to redirect to the page for the build instead. It'd be more useful for the user too.
Version-Release number of selected component (if applicable):
dunno, whatever's running
I've always seen the full list as a benefit because the table is sortable and searchable, so you do not need to click zillion times through the next pages to find what you need.
In this particular case:
$ time curl https://copr.fedorainfracloud.org/coprs/g/python/python3.8/builds/ >/tmp/info
0.80s user 0.97s system 1% cpu 2:12.09 total
$ wc /tmp/info
640706 1266684 17861563 /tmp/info
It's a 17MB query made live from the database, and python3.8 rebuild is not even close to being finished.
which is IMO not bad for such a huge project.
Additionally, the table is by default sorted by ID and streamed, so you should see the status of the last build even before the table is fully loaded.
BTW - there is a load of the failed build. In fact, most of them. If you would delete it, the page will render much faster.
It doesn't bother me personally too much, now that I know what is happening. If you think the load on the backend doens't matter, let's just close this.
The impact on the server is minimal as only few projects have such a huge list. IMO this does not justify spending developing cycles on this issue. Closing.