Gitea slow on corperate Windows 10 environment

[mike-jl]

• Gitea version (or commit ref): 6a6656a, but was the same since 1.6
• Git version: 2.21.0
• Operating system: Windows 10 Pro
• Database (use [x]): (also tried MSSQL but no difference)
  • PostgreSQL
  • MySQL
  • SQLite
  • [] MSSQL
• Can you reproduce the bug at https://try.gitea.io:
  • Yes (provide example URL)
  • No
  • Not relevant
• Log gist:

Description

Gitea on my Work PC is generally very slow.
My PC has plenty of resources left according to resmon.
Changing to the commit view of the repo takes 9.4 seconds.
Trying to create a pull request between two branches, the loading time after selecting the branch is 50 sencods.
I already tried disabling the antivirus, and it does help (pull request goes down to 42 seconds), but that's still way to much.

Any way to debug what is taking so long?
I looked at ProcessExplorer, but all i can see is that gitea spawns a view git processes in that time. Maybe i just need to know where to look..

Thanks in advance!

[lunny]

That's maybe caused by sqlite_unlock_notify and I think You maybe change your database if you have enough resources.

[mike-jl]

As i said i already tried with a local MSSQL installation and ended up with the same performance...
Should i try MySQL?
I could try it in a local installation, but for prod my only options are MSSQL or SQLite...

[lunny]

@MichiiL haven't found you mentioned MSSQL on above messages. I run a gitea instance with MSSQL on macOS it's fast and I cannot reproduce your problem since I have not windows with MSSQL installed.

[mike-jl]

Database (use [x]): (also tried MSSQL but no difference)

Maybe i should have made it more clearly..
Its also fast on my private windows machine, or on my private linux server.
It has to have to do something with the corporate environment...

[mike-jl]

Here is a log with REDIRECT_MACARON_LOG = true and LEVEL = Trace
This is from selecting the branch in a new pull request.

https://gist.github.com/michiil/1d91ef87fb6a248e746014d5959e4eb3

[lunny]

Does your pull request have many commits or changed files?

[mike-jl]

Its 41 commits and 147 changed files.
About 100 of the changed files are new images.
But still, on my linux server at home with far inferior hardware it takes 1.38 seconds...

[lafriks]

Could this be problem with resolving federated avatars?

[mike-jl]

I don't think so, i got the following lines in my config:

[server]
OFFLINE_MODE     = true

[picture]
DISABLE_GRAVATAR        = true
ENABLE_FEDERATED_AVATAR = false

[zeripath]

So do you think it's the starting of the git process that's taking the time?

How long is the PATH on that Windows server? Is it possible that Windows it's having to look through large numbers of directories to find git? Is there a slow virtual drive on the path so your corporate Windows has to do Windows networking to check for the file before it finally finds git? Presumably git is on the local server?

Similarly presumably your repositories are local to that server and are not on some shared drive so that when gitea has to look it doesn't have to do cross network lookup?

[mike-jl]

That could very well be it.
The path is pretty long yes, but everything is local.
Is there a way to point gitea to the git executional so it doesn't have to search through the path?

[zeripath]

Explicitly set the path when you execute gitea either through a bat file (or I think it's possible on a lnk file.)

[mike-jl]

Here are some measurements that i made:
Normal PATH with Antivirus:
© Gitea Version: 6a6656a Seite: 53899ms Vorlage: 46065ms
Only git in PATH with Antivirus:
© Gitea Version: 6a6656a Seite: 41122ms Vorlage: 35044ms
Only git in PATH without Antivirus:
© Gitea Version: 6a6656a Seite: 34646ms Vorlage: 29545ms

So the PATH is a big issue! Maybe that should be added to the docs?
Unfortunately i can't disable antivirus permanently, but 12 seconds is a lot better!
Still not as good as i would expect from that machine, but maybe that's the windows tax..

[zeripath]

Ok so simplifying the path was one thing. The next is, are you still using 1.6? Prior to #4921 every time you wanted to do a pr Gitea would mindlessly clone and do a full checkout, perform the merge and push. As you can imagine that takes forever - so #4921 significantly reduces the amount of work involved. Now Windows is fairly bad at keeping file caches around so if you try to clone a repo this will be expensive especially with the hooks for antivirus.

I think #4921 is only in version 1.8 and the current master but it's well recommended to try that to see if it makes things better.