Hi Jira Support Team,
we face a performance problem in the following situation:
Background: In our Software Development process we use Release Planning Events (RPE) to discuss and plan features for a specific release. Features can be impacted by several teams. Each team documents its planning result concerning the commitment (committed, uncommitted, out of scope) in a subtask of the feature (one subtask for each impacted team). We use subtasks because there is a high variation of impacted teams over all features and using the subtasks is our current solution to implement this 1:n relation.
Challenge: At the end of the RPE the teams document their votes in the corresponding subtasks. We have created a dashboard where we can see how much features are "voted" and the consolidated vote of the features (by defining a rule according to the linked subtasks of the specific feature). We face the problem, that the documentation of the teams in the subtasks takes a significant amount of time to be propagated to the dashboard - in a worst case it took hours.
Tests: To get an idea about the reason of this performance issue, I created a script (by using ScriptRunner) which changes the field entry of all relevant subtasks. In my tests I have used 350 features and overall 715 subtasks of these features. The number of subtasks of the feature varied from 1 to 10. For example the script changes the "vote" from "committed" to "uncommitted" in all subtasks.
Performance values of the tests: The duration of the script takes round about 2 minutes. After these 2 minutes the value of the field "vote" has been changed in all subtasks. When I search (filter) for the subtasks with the new value in the "issue search" dialogue, it takes about 7 minutes to get all subtasks with the new value in the search result table.
Questions: Is this behavior "normal"? Is there a way to speed up this behavior? Currently, we face the problem that we cannot report in real time the status of the voting because of this performance issue.
I'm looking forward to your feedback,
Ok, there's a couple of things that worry me here, but I need to ask some more questions, with a little bit of context to them.
Jira's search engine relies on a physical index system on the disk - it's a copy of most of the data in the database, but organised for searching (Jira's database is not, it's, at best, just a data store).
Whenever you change an issue, the index for that issue is updated with your new data. The dashboard runs mostly off searches, and hence the index, so if you make a change to an issue that is being reported on in your dashboard, then refresh the dashboard, you should see an immediate update.
So, my questions are:
As for your main question at the end, the short answer is "no, this does not sound normal". But I'm not sure it's a performance issue...
thanks a lot for your quick feedback!!
Here are my answers to your questions:
Maybe some other system values are helpful:
In our Jira System we currently have round about...
- 300 Projects
- 300,000 Issues
- 180 issuetypes;
- 900 Customfields, 38 of them are scripted fields (using ScriptRunner)
- 1,400 activ users
- 60 permission-schemes
- 350 workflows
...that is somehow reassuring. Thus, we "only" have to find the reason behind the behavior ;-)
Additional questions regarding the indexing:
Once more: thanks a lot for your support!
Ok, the vote being a single field doesn't really make much sense in terms of it being a vote (it's just a flag field), but it does contribute to the "this is a really simple action", and tells me it is just a symptom, not the cause of your problems.
A single change, to an issue, such as setting your voting field, should be indexed before you have a time to swap tabs/windows back to a dashboard or search and click "refresh"
If it's taking 7 minutes for a single change (or even a batch of a couple of hundred), your indexing is broken, there's something horribly wrong with it.
You really need to get your admins to take a close look at the configuration, disk io, and errors so they can find and fix whatever it is that's wrong. There's one extra clue - "we re-index every night" - NO. That's "plastering over the cracks". You've got a bad setup and broken process to try to pretend something isn't wrong. This all needs fixing. A properly set up Jira of your size should not even consider automatic indexing runs, re-indexing when fields need it should be enough (and those could be months apart)
So, on to the follow up questions
Ok, it seems to be that I was not able to describe our use case properly, but that doesn't matter. Independent from the use case I also assume that such a change (reasonable or not) should not lead to such a system behavior.
I will ask our admins concerning the configuration, disk-io, and errors. Hopefully, they are able to see some hints for the underlying problems in our setup.
I wonder that re-indexing "could be months apart" because Jira asks for "re-indexing" every time whenever a new custom field is introduced.
Thanks for your assessment.
No, I think it was me not quite grasping it, your description was good, and your patient explanation of it for me was excellent.
But yes, everything is pointing towards some problem with your index. There's absolutely nothing wrong with your voting, there's something wrong with your Jira that your voting system is exposing or highlighting.
One more question: Due to the fact that I'm not part of the admin team (my job is to configure in Jira, e.g. workflows, screens etc.) which has installed Jira Software and Jira Service Desk in our system landscape - is there a documentation available - beneath the "official" installation page(s) on confluence - which describes how a suitable system setup should look like?
We’re excited to introduce external collaboration for Confluence, now available in early access. It is available to preview for Confluence Cloud Premium and Enterprise customers. (If you're not on ...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events