How to check if an SSL/Proxy is causing Slowness while using JIRA
Platform Notice: Data Center Only - This article only applies to Atlassian products on the Data Center platform.
Note that this KB was created for the Data Center version of the product. Data Center KBs for non-Data-Center-specific features may also work for Server versions of the product, however they have not been tested. Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.
*Except Fisheye and Crucible
Many times we get performance issues reported for Jira where the page takes longer to load.. There are various external factors that could be the root cause. However, in this KB we are trying to identify if an SSL/Proxy inspector is placed in the network, which could be a possible reason for the issue.
In accordance with our security policies, we strongly advise excluding the Atlassian first-party domains from TLS interception/inspection to ensure a performant experience. Atlassian products heavily depend on features of the HTTP/2 protocol, particularly support for simultaneous transactions. TLS interception/inspection proxies and firewalls often cause HTTP/2 to HTTP/1.1 protocol downgrades. Downgrades to HTTP/1.1 significantly degrade the performance of modern web applications by causing transactions to become serialised. Page load and experience wait times can incur noticeable delays as a result.
One of the easiest ways to understand if there is an SSL inspector in your network is to check with the network admin. However, if you are not sure, this KB would help you identify if there is an SSL/Proxy inspector.
Capture an HAR log for the action where you are seeing the performance degradation. Ensure that you try to get the exact HAR logs, many a time we end up getting a lot more and it becomes cumbersome to go through the entire set of logs. In the captured HAR logs, we will look for the calls that are taking longer than expected. Ensure that the URL is an Atlassian/Jira URL. In our case, we see that the call is taking very long and is mostly in a stalled state.
Once we get to see such call, we would like to check the IPs for the Atlassian URLs being hit. Mostly all of the Atlassian URLs would point to one or two IP addresses of Atlassian. We will be trying to look for a call where we see the URL to be that of Atlassian but the IP does not belong to that of Atlassian. In our case we found the IP to be of an SSL inspector called IBOSS. There are various tools available to identify who owns a public IP, like https://www.whois.com/.
For the same calls, If we turn on the protocol column in the HAR network tab we see its forcing all the requests to go as HTTP/1.1. This severely degrades jira performance.
Once we have the above analysis in place, the next steps would be to exclude Atlassian domains from TLS/SSL inspection/interception or ensure the TLS/SSL inspection tool supports HTTP/2 and verifying that HTTP2 is used in a HAR capture..
Was this helpful?