mirror of
https://github.com/go-gitea/gitea.git
synced 2026-07-15 20:09:18 -05:00
Slow performance during repository uploadFile. #6857
Closed
opened 2025-11-02 07:08:46 -06:00 by GiteaMirror
·
28 comments
No Branch/Tag Specified
main
release/v1.25
release/v1.24
release/v1.23
release/v1.22
release/v1.21
release/v1.20
release/v1.19
release/v1.18
release/v1.17
release/v1.16
release/v1.15
release/v1.14
release/v1.13
release/v1.12
release/v1.11
release/v1.10
release/v1.9
release/v1.8
v1.25.3
v1.25.2
v1.25.1
v1.25.0
v1.24.7
v1.25.0-rc0
v1.26.0-dev
v1.24.6
v1.24.5
v1.24.4
v1.24.3
v1.24.2
v1.24.1
v1.24.0
v1.23.8
v1.24.0-rc0
v1.25.0-dev
v1.23.7
v1.23.6
v1.23.5
v1.23.4
v1.23.3
v1.23.2
v1.23.1
v1.23.0
v1.23.0-rc0
v1.24.0-dev
v1.22.6
v1.22.5
v1.22.4
v1.22.3
v1.22.2
v1.22.1
v1.22.0
v1.23.0-dev
v1.22.0-rc1
v1.21.11
v1.22.0-rc0
v1.21.10
v1.21.9
v1.21.8
v1.21.7
v1.21.6
v1.21.5
v1.21.4
v1.21.3
v1.21.2
v1.20.6
v1.21.1
v1.21.0
v1.21.0-rc2
v1.21.0-rc1
v1.20.5
v1.22.0-dev
v1.21.0-rc0
v1.20.4
v1.20.3
v1.20.2
v1.20.1
v1.20.0
v1.19.4
v1.21.0-dev
v1.20.0-rc2
v1.20.0-rc1
v1.20.0-rc0
v1.19.3
v1.19.2
v1.19.1
v1.19.0
v1.19.0-rc1
v1.20.0-dev
v1.19.0-rc0
v1.18.5
v1.18.4
v1.18.3
v1.18.2
v1.18.1
v1.18.0
v1.17.4
v1.18.0-rc1
v1.19.0-dev
v1.18.0-rc0
v1.17.3
v1.17.2
v1.17.1
v1.17.0
v1.17.0-rc2
v1.16.9
v1.17.0-rc1
v1.18.0-dev
v1.16.8
v1.16.7
v1.16.6
v1.16.5
v1.16.4
v1.16.3
v1.16.2
v1.16.1
v1.16.0
v1.15.11
v1.17.0-dev
v1.16.0-rc1
v1.15.10
v1.15.9
v1.15.8
v1.15.7
v1.15.6
v1.15.5
v1.15.4
v1.15.3
v1.15.2
v1.15.1
v1.14.7
v1.15.0
v1.15.0-rc3
v1.14.6
v1.15.0-rc2
v1.14.5
v1.16.0-dev
v1.15.0-rc1
v1.14.4
v1.14.3
v1.14.2
v1.14.1
v1.14.0
v1.13.7
v1.14.0-rc2
v1.13.6
v1.13.5
v1.14.0-rc1
v1.15.0-dev
v1.13.4
v1.13.3
v1.13.2
v1.13.1
v1.13.0
v1.12.6
v1.13.0-rc2
v1.14.0-dev
v1.13.0-rc1
v1.12.5
v1.12.4
v1.12.3
v1.12.2
v1.12.1
v1.11.8
v1.12.0
v1.11.7
v1.12.0-rc2
v1.11.6
v1.12.0-rc1
v1.13.0-dev
v1.11.5
v1.11.4
v1.11.3
v1.10.6
v1.12.0-dev
v1.11.2
v1.10.5
v1.11.1
v1.10.4
v1.11.0
v1.11.0-rc2
v1.10.3
v1.11.0-rc1
v1.10.2
v1.10.1
v1.10.0
v1.9.6
v1.9.5
v1.10.0-rc2
v1.11.0-dev
v1.10.0-rc1
v1.9.4
v1.9.3
v1.9.2
v1.9.1
v1.9.0
v1.9.0-rc2
v1.10.0-dev
v1.9.0-rc1
v1.8.3
v1.8.2
v1.8.1
v1.8.0
v1.8.0-rc3
v1.7.6
v1.8.0-rc2
v1.7.5
v1.8.0-rc1
v1.9.0-dev
v1.7.4
v1.7.3
v1.7.2
v1.7.1
v1.7.0
v1.7.0-rc3
v1.6.4
v1.7.0-rc2
v1.6.3
v1.7.0-rc1
v1.7.0-dev
v1.6.2
v1.6.1
v1.6.0
v1.6.0-rc2
v1.5.3
v1.6.0-rc1
v1.6.0-dev
v1.5.2
v1.5.1
v1.5.0
v1.5.0-rc2
v1.5.0-rc1
v1.5.0-dev
v1.4.3
v1.4.2
v1.4.1
v1.4.0
v1.4.0-rc3
v1.4.0-rc2
v1.3.3
v1.4.0-rc1
v1.3.2
v1.3.1
v1.3.0
v1.3.0-rc2
v1.3.0-rc1
v1.2.3
v1.2.2
v1.2.1
v1.2.0
v1.2.0-rc3
v1.2.0-rc2
v1.1.4
v1.2.0-rc1
v1.1.3
v1.1.2
v1.1.1
v1.1.0
v1.0.2
v1.0.1
v1.0.0
v0.9.99
Labels
Clear labels
$20
$250
$50
$500
backport/done
💎 Bounty
docs-update-needed
good first issue
hacktoberfest
issue/bounty
issue/confirmed
issue/critical
issue/duplicate
issue/needs-feedback
issue/not-a-bug
issue/regression
issue/stale
issue/workaround
lgtm/need 2
modifies/api
modifies/translation
outdated/backport/v1.18
outdated/theme/markdown
outdated/theme/timetracker
performance/bigrepo
performance/cpu
performance/memory
performance/speed
pr/breaking
proposal/accepted
proposal/rejected
pr/wip
pull-request
reviewed/wontfix
💰 Rewarded
skip-changelog
status/blocked
topic/accessibility
topic/api
topic/authentication
topic/build
topic/code-linting
topic/commit-signing
topic/content-rendering
topic/deployment
topic/distribution
topic/federation
topic/gitea-actions
topic/issues
topic/lfs
topic/mobile
topic/moderation
topic/packages
topic/pr
topic/projects
topic/repo
topic/repo-migration
topic/security
topic/theme
topic/ui
topic/ui-interaction
topic/ux
topic/webhooks
topic/wiki
type/bug
type/deprecation
type/docs
type/enhancement
type/feature
type/miscellaneous
type/proposal
type/question
type/refactoring
type/summary
type/testing
type/upstream
Mirrored from GitHub Pull Request
No Label
performance/speed
Milestone
No items
No Milestone
Projects
Clear projects
No project
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/gitea#6857
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @miou-gh on GitHub (Feb 13, 2021).
[x]):Description
When uploading a file into an existing repository through the API, it can take several seconds to complete, even when on localhost and the file is under a megabyte in size.
...
Screenshots
@zeripath commented on GitHub (Feb 13, 2021):
Thank you for the listing pprof results.
Hmm. No clear smoking gun in that dump - it's all just a little a slow. Which I guess is related to you running on Synology. (You are running on a Synology right?)
One surprisingly slow thing was:
At 110ms but that doesn't really make much sense to me and it's not like it's a clear thing to improve.
It would be good to catch one of the really slow uploads because then we'd really be able to compare.
Now, some things:
@miou-gh commented on GitHub (Feb 16, 2021):
I have created a small application to benchmark, and attached it.
GiteaAddFilePOC.zip
I am not. I'm running on local filesystem.
I am trying 1.14 and there are still severe performance issues present.
I am automating the process of creating users, repositories and files in those repositories. I'm using the automatically generated SDK from https://github.com/belidzs/Gitea which appears to call the methods defined in Swagger, and nothing more really.
It appears as though there isn't any cut-off point.
I am using a SSD in perfect healthy condition.
I'm using Git version 2.30.0.
@miou-gh commented on GitHub (Feb 16, 2021):
pprof003.zip
@lunny commented on GitHub (Feb 16, 2021):
@atillabyte Could you try to use other database i.e. mysql/postgres rather than sqlite3?
@zeripath commented on GitHub (Feb 16, 2021):
That data suggests that master is at least twice as fast and up to 10 times faster - possibly even more if you account for GC time. (You previously had logs with 9s delays.)
Whilst I appreciate you may want this to be running at sub 100ms speeds - I'm not certain we will ever get to that point. Some acknowledgement of the fact that it is actually at least twice as fast would be appreciated.
Now... looking at the pprof SVG, we have 2.11s of work running in the http pathways. About half of that time is spent in json.Decode. So that would imply that there would be some benefit to switching from the default encoding/json library - but the place that is calling the json.Decode here isn't shown in that graph.
One thing that could be more useful going forward is to change the values of
edgefractionnodefractionandnodecount. These values determine how much is shown in a graph and could be hiding salient features. You can change them on the command line:go tool pprof ... -edgefraction 0 -nodefraction 0 -nodecount 100000but you can change them in the REPL that go tool pprof gives too. Setting these too extreme like this may make the graph more difficult to understand but you can change these values to decrease the noise as necessary.
I also note that SVG is clearly not helping you to post the images in here - it may be better to use
pnginstead ofsvg.It may be easier to meet on discord to help work through things a bit quicker.
@kyland-holmes commented on GitHub (Jun 29, 2021):
Is there any plan to improve the perf of file creation / upload to a repo? I've been monitoring this bug for quite some time. We consistently see it take 1.9-2.5 seconds when committing trivial files to a new repo through the gitea API.
@zeripath commented on GitHub (Jun 29, 2021):
@KyKoPho have you checked on main?
@zeripath commented on GitHub (Jun 29, 2021):
(I've spent most of this cycle doing performance fixes elsewhere - so I apologise that this hasn't had been looked at.)
@kyland-holmes commented on GitHub (Jun 29, 2021):
Hi @zeripath , thanks for the fast reply. I've tried the latest release, if that's what you mean. I could also clone and build from there.
@kyland-holmes commented on GitHub (Jun 29, 2021):
1.14.3 to be specific.
@zeripath commented on GitHub (Jun 29, 2021):
I mean main. 1.15-dev.
@kyland-holmes commented on GitHub (Jun 30, 2021):
We are using the public docker containers. Is gitea/gitea:latest built off of main? The only dev tags I see are back around 1.7.0, etc
@kyland-holmes commented on GitHub (Jun 30, 2021):
I just tried gitea/gitea:latest and did see about an ~8% improvement. I was unable to find the gitea/gitea:1.15-dev image anywhere, but I'm guessing the latest image will have some of that baked in already.
@zeripath commented on GitHub (Jul 21, 2021):
Hi @KyKoPho sorry I missed this...
Would it be possible to get some update pprofs or good test example for this? It would be good to know where to target improvements.
My suspicion is that the interpretation of the json payload is still going to be the largest delay - but changes targeting that would be involved so it would be good to prove this first.
@kyland-holmes commented on GitHub (Jul 24, 2021):
@zeripath Sure! Let me work on that. Never done that before, so may take some time.
@kyland-holmes commented on GitHub (Jul 24, 2021):
@zeripath Here's the output of pprof
raw sort cum > pprof.txt. Please let me know if this is useful or not. I'm assuming the 0s is a rounding / sampling artifact.pprof.txt
@kyland-holmes commented on GitHub (Jul 24, 2021):
Hopefully this helps some. This is the result of
go tool pprof http://localhost:6060/debug/pprof/heapimmediately after creating a new repo and pushing a new file.and also
pprof top@zeripath commented on GitHub (Jul 24, 2021):
That's memory ... We were looking at time
@kyland-holmes commented on GitHub (Jul 24, 2021):
@zeripath here is top 10 from pprof during the same call / workflow. Note this is all work coming in via the API, not the web interface for gitea:
@kyland-holmes commented on GitHub (Jul 24, 2021):
Looking at the graph, it actually looks like most of the time is being spent decrypting the user password from disk with the pbkdf2 algo. (maybe?)

@zeripath commented on GitHub (Jul 24, 2021):
Not surprised that pbkdf2 is a cause of slow down here - this is the cost of not having session support. If that really is the only slowdown left we've won though.
BTW I forgot to ask which version are you running. It's really important to state the version - plus its really only worth doing this on 1.15-RC2 or main (not 1.14.x).
@lunny commented on GitHub (Jul 24, 2021):
Have you tried to use username and token with the API?
@kyland-holmes commented on GitHub (Jul 24, 2021):
@lunny Once I saw this was in the hash algo, I tried that last night. No dice, I think whether you use a token or basic auth, the same algo still gets used. I'm looking into setting up a reverse proxy for auth as we internally have a solution for that.
@zeripath I tried this on 1.14.2, 1.14.3, 1.14.5 and 1.15.0+dev-543-g1b29747f0. They all seem to have the same perf in this regard.
How can I get 1.15-RC2? Are any of the tagged images in docker hub built from that?Disregard, just found it on docker hub.@zeripath commented on GitHub (Jul 24, 2021):
So unfortunately the tokens would still necessitate a pbkdf2 calculation as currently coded.
We'd need to cache successful tokens in an LRU cache, have sessions, or move to a JWT token approach. (JWT tokens is on my list of things to do.)
@lunny commented on GitHub (Jul 25, 2021):
We can change the login check sequence on API. Firstly index the access_token table by token if token length is matched. If there is not exist then check password.
@zeripath commented on GitHub (Jul 25, 2021):
We already do that - #16164 (& #16171), #6724.
There are several inefficiencies with the current approach:
6a33b290a0/models/token.go (L69-L82)Take a look at the loop starting line 77. The underlying assumption here is that the number of tokens returned is small - preferably one - however on a large install there may be many such tokens returned always in the same order.
Every time such a "pathological" token is used it will be hashed against every single token returned. This alone could be serious slowdown and in fact prior to #16164 this would take effect on passwords >8 characters if the last 8 characters were hex. #16164 means that this can only happen on passwords which are 40 characters long and all hex. (Hmm... thinking on I'm not sure how much this would happen)
This pathological case could be avoided if the user provides the username by limiting the tokens to those that match the username - I'll pop up a PR for this - but I'm not sure how often this would happen and paradoxically it may slow things down. However, that still leaves us with a pbkdf2 hash for each and every API call.
In the case of avoiding the pbkdf2 hash for each and every API call. The options are:
(As an aside, this issue is also why we need to convince administrators to ban BASIC authentication using passwords because these suffer the same problems.)
In terms of how to proceed:
EDIT: Thinking on, I think that the pathological case described above is should be somewhat uncommon.
@zeripath commented on GitHub (Jul 25, 2021):
@KyKoPho I suspect #16547 would significantly improve your experience and would be easily backportable 1.14 and 1.15.
@kyland-holmes commented on GitHub (Jul 27, 2021):
@zeripath thanks so much for the heads up.