JIRA performing slowly only in Firefox with Enable DNS over HTTPS
Categories
(Core :: Networking, defect)
Tracking
()
People
(Reporter: jlkryza, Unassigned, NeedInfo)
Details
(Keywords: regression, regressionwindow-wanted)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:87.0) Gecko/20100101 Firefox/87.0
Steps to reproduce:
- Removed all addons (safe mode)
- Logged into local instance of JIRA v8.7.1#807001
https://share.firefox.dev/3rCM67H
Actual results:
When going through Kanban, project, or calendar view the responses are extremely slow and delayed. Responds much smoother in chromium-based browsers
Expected results:
No delays and smooth operations
|
||
Comment 1•4 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Toolkit::Add-ons Manager' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.
|
||
Updated•4 years ago
|
|
||
Comment 2•4 years ago
|
||
The network chart shows 21 seconds spent in DNS resolution: https://share.firefox.dev/31UJCY9
And then later 5 seconds in establishing the TCP connection.
jlkryza, when you say "only in Firefox 87", does this mean that it was fast in Firefox 86 and then this issue first appeared in 87?
Also, can you reproduce this problem in Firefox Nightly? https://nightly.mozilla.org/
|
|
||
Updated•4 years ago
|
Sorry. Removed the 87 bit. It has been slow for the last slew of FF releases. It's been slow for a while. I initially thought it was just our self hosted instance but after trying it in Chrome and Edge and then confirming with a coworker (Chrome user) I realized it was only when Firefox was being used.
I will download nightly and test it again with no addons or anything.
|
||
Updated•4 years ago
|
After Markus pointed out the DNS time, I removed/turned off "Enable DNS over HTTPS". JIRA now performs as snappy as it should. I tried both CloudFlare and NextDNS. Both slowed down my JIRA access.
While this isn't necessarily a bug, I would think having DNS over HTTPS to be very beneficial towards security. Is there a way to turn it on for everything EXCEPT my local JIRA instance?
(In reply to jlkryza from comment #4)
After Markus pointed out the DNS time, I removed/turned off "Enable DNS over HTTPS". JIRA now performs as snappy as it should. I tried both CloudFlare and NextDNS. Both slowed down my JIRA access.
Valentin, do you have suggestions in how to get more logging information for that?
Thanks for reporting this.
Could you clarify how the local JIRA instance works?
Is it only available with a local network IP?
Or are you mapping the host name with /etc/hosts?
I think most likely this is an example of a split horizon failure.
Using DoH it tries to connect to the public IP of the domain, the connection fails (times out as far as I can tell), so we retry without DoH and get the local IP so it works.
If you want you can exclude certain domains from using DoH by adding the name to: network.trr.excluded-domains. For example:
quikq.com or jira.quikq.com.
I don't manage the instance so I can't answer the /etc/hosts question.
It is only available locally which explains the DoH slowing it down. I updated network.trr.excluded-domains and it works perfectly.
Thank you!
Thanks for the info.
Just to confirm the cause, could you revert network.trr.excluded-domains and record some HTTP logs ?
Thanks!
So I ended up getting annoyed at the speed and looked into this a bit finally. Found this and tried out the network.trr.excluded-domains idea and checked the output of about:networking#dns to compare the trr result. Seems there's a whole bunch of API calls that web app uses, and tracked down a few more just to see if it makes any difference. So far I came up with this list: atlassian.com,atlassian.net,atl-paas.net.
It seems faster? Is there anything I could do to provide a more useful debug or profiling report to help pinpoint this?
|
||
Updated•4 years ago
|
I think this is expected behaviour - this is a classic split horizon case. We have some mitigations in place, but no way to actually fix it.
Description
•