I can' reproduce this on my machine. Do you eventually have a browser log that show which requests take this long?
I encountered the same issue. Codeberg had really poor performance yesterday when I tried to sign up. The landing page would load but anything other than that would take several minutes to load. However, that is not the case today and every page seems to be loading fine.
We are investigating these reports. It's somewhat unlikely to be related to the logged-in state. Can you tell us
- the exact time when you run into those issues
- the page you were browsing and maybe if you did anything special before (interesting especially if you are browsing big repos, reloading the page, encounter timeouts etc)
- if you can open any other page during that time
- how long it takes until you can continue browsing Codeberg again
System parameters look fine during the last days, the last warning was issued at the beginning of May. We found some weird request behaviour in the logs, but we cannot really tell how this relates yet.
Also, we reproduced some scenarios where we can temporarily render the whole instance unresponsive on codeberg-test.org (single-core VPS, much easier to trap). We'd be glad to receive some more hints when looking for indices that this happens on production, too. We also suspect a conneciton to some backend changes (go-git vs direct git usage).
I can reproduce this now while logged in, actually. All pages are pretty slow. I've attached a HAR file from loading this page which should provide all the details you need (though I have removed cookies).
If you are interested in reading on, please also follow the discussion upstream: https://github.com/go-gitea/gitea/issues/15707#issuecomment-850399192
Yesterday, we migrated the backend back to go-git for now and the performance was improved again. We hope to help optimize the backend performance again, so that it is fast and uses less RAM.
Also, we are trying to tune caching with Redis.
The issue was addressed by changing the backend implementation and adding Redis as a commit info cache.
The site's performance isn't heavily degraded now as it was at the time of reporting, but further improving it is of course very welcome (will close this issue nevertheless).
I wasn't following the exact upstream discussions recently (I don't think I can help there at the moment), but some plans include deferring the last commit information into an async function.
Deleting a branch is permanent. It CANNOT be undone. Continue?