This is my fault.

pagure.io was getting hit by a DDoS of people hitting that page. ;(

So, I blocked it to keep the site up and happy...

looks like there's been...
110k hits to it today, so it's gone way down.

I can see about removing this or try and figure some other way to block the DDoSers...

How much requests per second can withstand Pagure? Is there some cache for anonymous?

There is something more.

https://pagure.io/fedora-web/websites.git redirects to https://pagure.io/fedora-web/websites which gives 403.

But https://pagure.io/fedora-web/websites/ works.

How much requests per second can withstand Pagure? Is there some cache for anonymous?

No idea... but when the DDoS was happening it was large enough to impact performance. :)

There is something more.

https://pagure.io/fedora-web/websites.git redirects to https://pagure.io/fedora-web/websites which gives 403.

But https://pagure.io/fedora-web/websites/ works.

Yes, I only blocked the specific url that they were all hitting.

So any plans to revert the change? Implement some proper throttling mechanism perhaps? No idea how.

I've dropped the redirect.

I could not come up with any throttling method that would work.

Thanks.

I could not come up with any throttling method that would work.

Not any best practices for throttling high load in any of Fedora infrastructure?
https://docs.fedoraproject.org/en-US/infra/sysadmin_guide/

Looks like we'll need to block that URL again, I have 10K error emails with a majority of them referring to this url triggering the error:

sqlalchemy.exc.TimeoutError: QueuePool limit of size 5 overflow 10 reached, connection timed out, timeout 30 (Background on this error at:
+http://sqlalche.me/e/3o7r)

Is there a way to properly debug where the bottleneck is? It looks bad
for Pagure if its installation is not ready to gracefully handle
production traffic. Or at least know what the limits are.

Closed as duplicate in favor of https://pagure.io/pagure/issue/5340, recent communication about this issue happened over there.