Without showing any custom Worklog Attributes, our Tempo Team report for May 2013 loads in 12.03 seconds, with the browser making 5 HTTP requests. That's fast enough.
If we select both "Type" and "Category" from the Views menu, our Tempo Team report for May 2013 loads in 2 minutes and 29 seconds, with the browser making at least 2066 HTTP requests. That's too slow to be usable.
Can we make this perform faster?
We're using Tempo 7.6.2 on JIRA 5.2.7
Our May 2013 report seems to include 1962 worklog entries
document.querySelectorAll('div#tempo-report-module table#issuetable tr.section.level-3.issuerow').length => 1962
Each worklog entry seems to generate two HTTP requests:
Deployed 7.6.3 today with good results. Our May 2013 Team report now makes 186 requests and takes 11.49s, which makes it usable with custom attributes shown. It looks like each unique request is now cached.
It looks like there is an opportunity for another (more modest) performance improvement. To keep this question clean, I asked https://answers.atlassian.com/questions/188219/tempo-report-makes-extra-requests-when-custom-worklog-attributes-use-account
Many thanks for getting a fix for this into your next release! Kudos Tempo team for excellent service!
Here are a few thoughts on what could be happening:
Cache Control Theory
Response headers include <tt>Cache-Control: no-cache, no-store, no-transform</tt>. Tempo should remove the <tt>no-cache</tt> header for these responses. As per the <tt>HTTP/1.1 Cache-Control| http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9</tt> spec, this forces the browser to go back to the server for each request to this URI.
Cache Buster Theory
We don't have Account as a Worklog Attribute, so the Account comes from the Issue and is the same for all Worklog entries on that issue. A unique cache buster parameter, _, is appended to every request, so even requests to the same URI must go back to the server. Tempo should remove the cache buster, or at least re-use the same cache buster per issue.
Account Already Known Theory
The Account is an attribute on the issue. Since the Account column is loaded with the first HTTP request (report.jspa), the susequent HTTP requests like /rest/tempo-rest/1.0/worklogs/customFieldValue/INT-6/Account are redundant and can be eliminated. This applies since I don't have Account as a Worklog Attribute.
Here are my crazy theories. What is the real answer?
Wow what a great analysis, thanks a lot Anson!
A little background: We had a look at this in the development of Tempo 7.6 and we believed that we eliminted all unneeded request. So either we did not completely finish that or that the new account field in reports feature in Timesheets 7.6 is re-introducing the problem. Your information will help us a lot to investigate.
I have created an issue for this. Lets continue the discussion over there.
I’m a designer on the Jira team. For a long time, I’ve fielded questions from other designers about how they should be using Jira Software with their design team. I’ve also heard feedback from other ...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs