Gitea: Gitea slow on corperate Windows 10 environment

[michiil]

• 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
  
  
  • [x] SQLite
  
  
  • [] MSSQL
  
  
• Can you reproduce the bug at https://try.gitea.io:
  
  
  
  • [ ] Yes (provide example URL)
  
  
  • [x] 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.

[michiil]

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.

[michiil]

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...

[michiil]

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?

[michiil]

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?

[michiil]

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?

[michiil]

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.)

[michiil]

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.

[michiil]

Nope i'm on 1.8 (rc2 now).

[michiil]

Just tried #6478 and it definitely solves this issue 👍

[typeless]

Maybe we should have an optional setting in app.ini for the absolute path of git?

Edit:
Or even better (easier), Gitea can lookup the path of git first and then using the absolute path subsequently.

[lunny]

@typeless We can give an option of git command, which could be an absolute path or not.

[typeless]

@lunny If we decide to add an option, it would be better if this option is by default unset and optional.
Minimizing the "required" changes to configurations during installing Gitea is desirable.

[ve3]

I installed Gitea on Windows 10 pro. The main repository page with less than 50 files take me ...

© Gitea Version: 1.8.1 Page: 3403ms Template: 1583ms

I think it is too slow.

Here is the settings

[server]
OFFLINE_MODE     = true
[picture]
DISABLE_GRAVATAR        = true
ENABLE_FEDERATED_AVATAR = false

[typeless]

@ve3 A fix has already been merged for 1.9, which would help if it has the same root cause.

[Ziflin]

I've got a similar issue (just switched from Windows 7 to Windows 10) and a repository with ~250 files and 5 commits is taking quite a bit longer now on Windows 10 Pro (close to 2x slower) with identical configs in Gitea and both using Sqlite3. The repositories do use Git LFS and maybe 20 files are LFS files, so I'm not sure if that's related. (I'm also using Git v2.21.0 and Gitea v1.8.2.)

I also checked on several of the repos on the Gitea test server (https://try.gitea.io/) and the times there for the main Repository pages are like Page: ~15-20ms and Template: ~2ms. Those are 100-200 times faster than what I'm seeing on my (newly installed) Windows 10 Pro machine on the same network using a SSD drive. I would certainly like the times to be closer to that for such a small repository :). It does look like for non-repository pages (such as the user profile page) I get maybe Page: 6-10ms and Template: 1-3ms

Is there a way to tell what is taking so long? I have similar options as @ve3 so everything should be "local".

Thanks!

[lunny]

@Ziflin could you try gitea with mysql or other databases except sqlite3?

[Ziflin]

@lunny Sorry, I'm not able to on this machine. One of the reasons we're using Gitea was the single file install. Is there a way to profile what's taking time apart from the Page and Template times?

[zeripath]

You might find one of the 1.9 nighties quicker.

[Ziflin]

@zeripath Are those prebuilt somewhere or do I need to build it myself?

[sapk]

@Ziflin you can found the binary here: https://dl.gitea.io/gitea/master/ and there is a pprof export to diagnose botleneck but it is not well documented. https://github.com/go-gitea/gitea/issues/6240

[Ziflin]

@sapk and @zeripath I just tested the latest v1.9.0 and that seems to have fixed my issues. What was taking:

• Page: 1420ms and Template: 430+ms

Is now taking:

• Page: 19ms and Template: 4ms

So whatever happened in v1.9 seems to have fixed it. All I did was copy over the old exe with the new one.

Thanks!

[zeripath]

You should thank @filipnavara

[Ziflin]

Hehe, well thanks @filipnavara! That was a great improvement!

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.