Gitlab CE web ui starts taking 60s+ randomly

Hi guys, I have been using an omnibus install since version 11. At some point during version 12, the Web UI starting taking forever to load on occasion. Sometimes it behaves normally, and its a rocket.

Currently, I’m on omnibus version 14.2 (Updated today) and the issue still persists.

I’m running on a 4790k with 32GB of RAM, and the server is almost never under any load (~7-10%).

The only thing different from a base installation is using a reverse proxy for my main nginx.

Are there any logs/commands I can use to check what it is causing so much latency on the web? I do not have any issues anywhere else…

Also, I have setup the JIRA DVCS connector, and I can see it absolutely blazing through API calls, so it seems to be related to just the web-ui…

I wanted to post an update, because it turns out the culprit may or may not be related to gitlab.

After trying a bunch of different browsers, it turns out that only firefox was loading gitlab slow. After monitoring the loading of pages, I noticed that requests were sitting blocked for a long time before even being sent.

In an attempt to figure it out, I turned off the new “DNS over HTTPS” feature in Firefox, and everything is instant again!

I’m not sure if this is a bug with firefox or with some https configuration that gitlab has.

This isn’t related to Gitlab. DNS over HTTPS instead of using normal DNS on UDP port 53 or perhaps TCP port 53, is sending the DNS requests over HTTPS instead.

Therefore, if I have an internal Gitlab instance, configured in my internal DNS, I cannot resolve this in DNS over HTTPS if I’m using for example Cloudflare as the provider in Firefox configuration. I would need to have a public configured DNS entry that Cloudflare would see and be able to resolve for my server to be accessible.

Also, the same is if I decide, well, I want a custom DNS over HTTPS, and I input my internal DNS server instead, it also won’t work, because I don’t have a HTTPS listener configured on my DNS servers for it to resolve the DNS entries.

I would need on my internal DNS servers a HTTPS listener, to redirect the requests to the DNS daemon on my servers, to resolve the entry and send the reply back over HTTPS.

This link will help for custom DNS over HTTPS: Set Up DNS over HTTPS (DoH) Resolver on Debian with DNSdist if I wanted to configure on my own site. That way I can use my own internal DNS servers and provide the resolution over HTTPS. Then it would work fine.

What you can also do is make exceptions for DNS entries that cannot be resolved by DNS over HTTPS: Firefox DNS-over-HTTPS | Firefox Help

I don’t use an internal DNS server, and my DNS provider IS also cloudflare… Which is even stranger as I was getting blocks with cloudflare as the https provider. I have a feeling that there may have just been some bug in Firefox.

Its possible yes. I expect it will settle down eventually and become stable with DNS over HTTPS.