Gitea slow on corperate Windows 10 environment #3078

GiteaMirror commented

@lunny commented on GitHub (Mar 20, 2019):

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

@lunny commented on GitHub (Mar 20, 2019): That's maybe caused by `sqlite_unlock_notify` and I think You maybe change your database if you have enough resources.

GiteaMirror commented

@mike-jl commented on GitHub (Mar 20, 2019):

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

@mike-jl commented on GitHub (Mar 20, 2019): 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...

GiteaMirror commented

@lunny commented on GitHub (Mar 20, 2019):

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

@lunny commented on GitHub (Mar 20, 2019): @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.

GiteaMirror commented

@mike-jl commented on GitHub (Mar 20, 2019):

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 commented on GitHub (Mar 20, 2019): > 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...

GiteaMirror commented

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

@mike-jl commented on GitHub (Mar 20, 2019):

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

@mike-jl commented on GitHub (Mar 20, 2019): 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

GiteaMirror commented

@lunny commented on GitHub (Mar 20, 2019):

Does your pull request have many commits or changed files?

@lunny commented on GitHub (Mar 20, 2019): Does your pull request have many commits or changed files?

GiteaMirror commented

2025-11-02 05:00:06 -06:00

@mike-jl commented on GitHub (Mar 20, 2019):

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

@mike-jl commented on GitHub (Mar 20, 2019): 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...

GiteaMirror commented

@lafriks commented on GitHub (Mar 27, 2019):

Could this be problem with resolving federated avatars?

@lafriks commented on GitHub (Mar 27, 2019): Could this be problem with resolving federated avatars?

GiteaMirror commented

2025-11-02 05:00:06 -06:00

@mike-jl commented on GitHub (Mar 28, 2019):

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

@mike-jl commented on GitHub (Mar 28, 2019): 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 ```

GiteaMirror commented

2025-11-02 05:00:06 -06:00

@zeripath commented on GitHub (Mar 28, 2019):

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?

@zeripath commented on GitHub (Mar 28, 2019): 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?

GiteaMirror commented

@mike-jl commented on GitHub (Mar 28, 2019):

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?

@mike-jl commented on GitHub (Mar 28, 2019): 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?

GiteaMirror commented

@zeripath commented on GitHub (Mar 28, 2019):

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

@zeripath commented on GitHub (Mar 28, 2019): Explicitly set the path when you execute gitea either through a bat file (or I think it's possible on a lnk file.)

GiteaMirror commented

@mike-jl commented on GitHub (Mar 28, 2019):

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

@mike-jl commented on GitHub (Mar 28, 2019): 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..

GiteaMirror commented

@zeripath commented on GitHub (Mar 28, 2019):

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.

@zeripath commented on GitHub (Mar 28, 2019): 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.

GiteaMirror commented

@mike-jl commented on GitHub (Apr 3, 2019):

Nope i'm on 1.8 (rc2 now).

@mike-jl commented on GitHub (Apr 3, 2019): Nope i'm on 1.8 (rc2 now).

GiteaMirror commented

@mike-jl commented on GitHub (Apr 10, 2019):

Just tried #6478 and it definitely solves this issue 👍

@mike-jl commented on GitHub (Apr 10, 2019): Just tried #6478 and it definitely solves this issue 👍

GiteaMirror commented

@typeless commented on GitHub (Apr 11, 2019):

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.

@typeless commented on GitHub (Apr 11, 2019): 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.

GiteaMirror commented

@lunny commented on GitHub (Apr 11, 2019):

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

@lunny commented on GitHub (Apr 11, 2019): @typeless We can give an option of git command, which could be an absolute path or not.

GiteaMirror commented

2025-11-02 05:00:09 -06:00

@typeless commented on GitHub (Apr 11, 2019):

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

@typeless commented on GitHub (Apr 11, 2019): @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.

GiteaMirror commented

@ve3 commented on GitHub (May 28, 2019):

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

@ve3 commented on GitHub (May 28, 2019): 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 ```

GiteaMirror commented

2025-11-02 05:00:09 -06:00

@typeless commented on GitHub (May 29, 2019):

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

@typeless commented on GitHub (May 29, 2019): @ve3 A fix has already been merged for 1.9, which would help if it has the same root cause.

GiteaMirror commented

2025-11-02 05:00:09 -06:00

@Ziflin commented on GitHub (May 31, 2019):

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!

@Ziflin commented on GitHub (May 31, 2019): 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!

GiteaMirror commented

@lunny commented on GitHub (Jun 1, 2019):

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

@lunny commented on GitHub (Jun 1, 2019): @Ziflin could you try gitea with mysql or other databases except sqlite3?

GiteaMirror commented

@Ziflin commented on GitHub (Jun 1, 2019):

@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?

@Ziflin commented on GitHub (Jun 1, 2019): @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?

GiteaMirror commented

@zeripath commented on GitHub (Jun 1, 2019):

You might find one of the 1.9 nighties quicker.

@zeripath commented on GitHub (Jun 1, 2019): You might find one of the 1.9 nighties quicker.

GiteaMirror commented

@Ziflin commented on GitHub (Jun 1, 2019):

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

@Ziflin commented on GitHub (Jun 1, 2019): @zeripath Are those prebuilt somewhere or do I need to build it myself?

GiteaMirror commented

@sapk commented on GitHub (Jun 1, 2019):

@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

@sapk commented on GitHub (Jun 1, 2019): @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

GiteaMirror commented

@Ziflin commented on GitHub (Jun 1, 2019):

@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!

@Ziflin commented on GitHub (Jun 1, 2019): @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!

GiteaMirror commented

@zeripath commented on GitHub (Jun 1, 2019):

You should thank @filipnavara

@zeripath commented on GitHub (Jun 1, 2019): You should thank @filipnavara

GiteaMirror commented

@Ziflin commented on GitHub (Jun 1, 2019):

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

@Ziflin commented on GitHub (Jun 1, 2019): Hehe, well thanks @filipnavara! That was a great improvement!

GiteaMirror commented