Tempo report with custom Worklog Attributes takes several minutes to load

[Anson Hoyt]

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.

We have two custom Worklog Attributes. Each dropdown varies on the Account, so that variable is included in the External URL.

• A dynamic dropdown "Type" loaded from https://example.com/{Account}/types.json
• A dynamic dropdown "Category" loaded from https://example.com/{Account}/categories.json

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?

Gory Details

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:

1. https://jira.example.com/rest/tempo-rest/1.0/worklogs/customFieldValue/INT-6/Account?_=1370460287199
2. https://jira.example.com/rest/tempo-rest/1.0/worklogs/customFieldValue/INT-6/Account?_=1370460287484
   Response: INT
   Response Headers include: <tt>Cache-Control: no-cache, no-store, no-transform</tt>

Crazy Theories

Included in my answer so I don't confuse the question

[Viðar Svansson [Tempo] · Accepted solution]

Hi Anson, can you verify that the issue is resolved in version 7.6.3?

Thanks,

Viðar

[Anson Hoyt]

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!

[Anson Hoyt]

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?

[Viðar Svansson [Tempo]]

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.