repos/pulls api take long time for large repos #31492
Comments
yp05327
added
performance/speed
|
Facing the same issue while using Postgres. |
|
another poke, i'm facing the same issue on projects.blenders.org tracker, but rather than a long wait and still giving the data, their server just gives a running a |
Can you post the link? |
|
I'm not entirely sure what you're asking? the link to what? the fact shortstat somehow runs i got from the opening post in this ticket, the failing call on the blender server you can repro with if it's something else you're looking for happy to help but you're gonna have to be a bit more specific :) |
|
I was curious what these long running commands look like, so I copied a few and ran them locally. I had to run |
It's very strange because the web request https://projects.blender.org/blender/blender/pulls is very fast. If you can provide some logs about this API requests, that's better. |
If the loading time increases for all "old" pages, it seems to be a SQL index or optimizer problem. In many cases |
I'm not in control of that server, but i'll prod blender devops, they should be able to dig up whatever you need, could be a few days though, hang tight! |
|
The following logging is what I could drum up:
|
Can you also give more context logs of API requests, your previous log lost some details? |
|
If there is performance problem, maybe you could refer to the diagnosis tool to collect performance profiles. Steps:
|
|
And if the performance is related to SQL, you could enable SQL logs to see what happens: https://docs.gitea.com/help/support (LOG_SQL) |
|
I'm working on this one. |
|
#32680 is ready to review. |
|
Blender updated to gitea 1.23.1 today! good news: I'm no longer getting a gateway timeout (but that's likely to blender devops tweaking the infra to allow longer requests) Bad news: The performance here still isn't where it needs to be: |
|
It’s unfortunate news. I will look into it. |
Can you catch some logs? |
|
If you could upgrade to 1.24 (main) branch, there is a very powerful builtin trace tool, just download the trace report from admin panel -> monitor -> trace page |
|
Ran the following command which took Then went to Entered (update by wxiaoguang: removed the attachment after downloading) |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
By the way, without the 1.24 "trace" support, it could also be able to figure out the bottleneck by:
By the way 2: Found something interesting in the report: The memory used by cache seems reasonable, but no idea whether LogNameStatusRepoParser should consume that much memory. (May be or not be related to the "slow" problem, just record the finding)
|
|
I'll admit since i don't have access to that server, this is pure speculation on my end, but what i got from the opening post, is that it's not necessarily slow because of database performance, but because it's spawning long running |
Oh yes, it could also be that reason ..... (just like the OP said) Maybe related to Make gitea webhooks openproject compatible (#28435), the Maybe could try to comment out that line to try? (there are 2 calls to that function in 1.23: |
Does it work for blender (since you could build your own binary and test)? |
|
Maybe there could be some interests in " Decouple diff stats query from actual diffing #33810 ", also I added a FIXME comment for "GetDiffShortStat". (And for 1.23: Do not call "git diff" when listing PRs #33817 ) @bartvdbraak does the suggestion above work for you? |
|
1.23 nightly is ready, feel free to try it. There is no "GetDiffShortStat" call for PR list |
The diff stats are no longer part of the diff generation. Use `GetDiffShortStat` instead to get the total number of changed files, added lines, and deleted lines. As such, `gitdiff.GetDiff` can be simplified: It should not do more than expected. And do not run "git diff --shortstat" for pull list. Fix go-gitea#31492 (cherry picked from commit 6422f05)
Unfortunately we don't have the amount of PRs on staging as on production and I'm not too keen to deploy a nightly build towards Production. Is this change already on 1.23.5? |
|
no |
|
Thanks for #33817! My big repo went from ~15 min to a little over a minute when running renovate 🎉 |
|
Had the same problem. Thanks for the fix. Great work guys! |
Description
I'm working with renovate which makes calls to
api/v1/repos/org/repo/pulls?state=all&sort=recentupdate&page=[page]. At pages 8+ the requests take a long time. Looking at htop it's because the git diff command is blocking.This is likely because my repo had a large restructure, loading the diffs on the gitea web app is also very slow.
Is there any way to cache diffs or any config I can use to speed them up? My current workaround is to set the request timeout to 5 min in renovate
Gitea Version
1.22.0
Can you reproduce the bug on the Gitea demo site?
No
Log Gist
https://gist.github.com/GammaGames/b1ae6715c8a66da638ee181ed6f93da1
Screenshots
Git Version
No response
Operating System
No response
How are you running Gitea?
Docker compose:
Database
SQLite
The text was updated successfully, but these errors were encountered: