Performance issue in Jira Data Center

[Kevin Künstler]

Hi,

We noticed a performance decrease after installing this app in a 2000 user Data Center Jira 7.13.

Using app version ~1.5.0 the whole instance froze for around 20 minutes multiple times a day (stuck Java threads).

After updating to 1.20.0 the freeze happens once a day in the morning.

‌

Using the “Burndown Chart Current Sprint” gadget on a dashboard, the gadgets says for multiple minutes “Scheduled for processing…” / “Processing…”.

While loading a dashboard with 2 of those gadgets, the developer console shows several requests triggered by this board, up to two requests each second which results in over 1200 requests:

Today we faced again a performance decrease from approx. 07:30 to 08:00 and noticed a lot error messages from the StonikByte App during this time:

Count Error Messages / Time (full hour)
 20 00
 16 01
 20 02
 16 03
 20 04
 16 05
 72 06
247 07
309 08
 20 09
  4 10

Additionally we noticed mutliple requests at night where the user (example JIRAUSER) was definitely not active:

2020-10-08 01:08:30,293 pool-task-service-1-thread-27 ERROR JIRAUSER 1310x38478x1 u63oyi 1.2.3.4,1.2.3.4 /plugins/servlet/stonikbyte/greatgadgets/aws [c.s.c.b.services.tasks.Task] Error executing task with key: http://127.0.0.1:9090 -2 879 Sprint Closure Date Sprint Closure DatefieldStoryPoints false false : Received http error code 403. Access to /rest/agile/1.0/board/879/sprint is forbidden. The id of this error is: 28269694473546495

‌

Is it possible that some requests get repeated for several hours?

Do you have any advice on how to investigate further?

‌

‌

Best Regards

Kevin

[Danut M [StonikByte]]

Hi Kevin,

‌

Thanks for posting.

It’s good that you upgraded to latest version. There multiple improvements made between v1.5.0 and v1.20.0.

When the chart like Sprint Burndown Chart is about to be displayed in dashboard, the browser (JavaScript) first makes a request to the app’s server component (that runs in Jira) for processing the data and providing the processed results back for being displayed in the chart. Such task/request might take seconds or minutes to execute, depending on the amount of data to be processed/displayed and on what you set in the gadget settings (time interval, filter, number of issues, etc). During this time, the browser also makes short requests to the server at every 500ms to get the status/progress of this task and to update the user with the task progress by displaying the progress in GUI (Example: Processing…. 10% completed, 20% completed…).

The multiple requests that you see are these short requests for getting the status of the processing tasks. They should not be a problem, being not heavy at all.

Night requests can happen if the gadgets are configured to refresh automatically. For example, JIRAUSER configured a gadget to refresh periodically by setting “Refresh Interval“ in gadget settings to a value other than “Never“. Please check.

In this case it seems that there is a gadget that takes a lot to process. Can you please identify it and provide a screenshot with its settings screen? Does it load in the end or it ends up in displaying an error? We have to see why.

This investigation might require switching various info. I propose moving the conversation over the email instead of this public ticket. So please contact [e-mail] with the requested info.

‌

Thank you,

Danut Manda

[Danut M [StonikByte]]

This issue was fixed in version 1.21.1 by adding data caching to Sprint Burnup Burndown Chart gadget. Also fixed for Cloud version.