nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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
=&gt; 1962

Each worklog entry seems to generate two HTTP requests:

https://jira.example.com/rest/tempo-rest/1.0/worklogs/customFieldValue/INT-6/Account?_=1370460287199
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

Accepted answers

Viðar Svansson

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

Thanks,

Viðar

All comments

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

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.

Viðar Svansson

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!

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

tempo

tempo-timesheets