Slow web-ui on large repo

Hi, we’re seeing slowness in the web-ui for a large repo. It has about 2000 directories and each directory contains about 15 files (so about 25000 files). These are text files.

We use the web-ui editor to make edits and commits on these files. It takes about 20 seconds to even open the main repo page in the web-ui. We see a message when opening the repo:

“Too many items to show. To preserve performance only 1,000 of 2000 items are displayed.”

Then when you drill down to your file to edit it takes another 20-30 seconds to load the file in the web page. Then if you want to edit the file (by clicking the ‘Edit’ button) it takes another 15-20 seconds to open the web editor.

So just to edit a file it takes over one minute to get to the actual web editor and make a change.

For smaller repos these operations only take 1-2 seconds per click. So less than 10 seconds to get from the main repo page to inside the web-ui editor.

We’re running the latest CE Omnibus self-hosted version (gitlab-ce-12.4.2-ce.0.el7.x86_64) on a RHEL 7 clone.

THe VM has 8 CPUs and 8GB of memory. The backend disks are SSD.

I’ve adjusted the number of unicorn workers up to 13 as per the config document formula.

unicorn[‘worker_processes’] = 13

I’ve also tried to adjust the unicorn max memory

unicorn[‘worker_memory_limit_max’] = “2048 * 1 << 20”

These don’t seem to help with the web-ui slowness when trying to edit files in the large repo.

Are there any other settings to tweak? Thanks.

I’ve been looking at

https://docs.gitlab.com/ce/ci/large_repositories/

it shows how to set GIT_DEPTH on CI/CD but not on just regular gitlab. Is this something I can add to /etc/gitlab/gitlab.rb?

https://docs.gitlab.com/omnibus/settings/environment-variables.html

shows how to add env vars but I’m not sure which section to add GIT_DEPTH to.

Any ideas? Thanks.

I’m also facing similar issue. Displaying large repo take 2 couple of minutes with web-ui.

@thomserv0, Did you manage to solve this issue?

@lakshmipathi.g

Hi, no we have not resolved this. I opened an issue on gitlab as well but have not heard back.

Really the only solution so far is to break up the repo into smaller and smaller directories and files. Not ideal but the more you divide up the directories into more and more repos the performance gets better and better.

The other thing we’ve tried is another application. I tested with Gitea

https://gitea.io/en-us/

and with the same large repo (2000 dirs and 25000 files) it’s very fast. Gitea doesn’t have a lot of the extra features of gitlab but just for git management Gitea is very nice (and fast).

Hi @thomserv0,

Thanks for the details and sharing your solution. I hope gitlab will provide some inputs on how optimize the web-ui performance for large repo.

thanks for pointers on Gitea.