The fact that JIRA custom fields impact issue creation performance has been documented https://confluence.atlassian.com/enterprise/scaling-jira-461504619.html#ScalingJIRA-JIRAperformancetestingmethodology
I recently did an experiment to try and tease out this impact per-field to try and determine if all fields have equal impact. I think I have found that they do not.
My experimental procedure was:
After several rounds of the above using different approaches to choosing the sets in step #2, I narrowed down to these three fields having a large impact on average time for issue creation:
These are all of type com.pyxis.greenhopper.jira:gh-lexo-rank.
In a final round I simply deleted each one individually in step #2 and collected the following measurements:
|Stage||Average time in milliseconds to create issue|
|After Rank removed||782|
|After Global Rank removed||674|
|After Ranking removed||332|
Is it already known that these fields have more impact? What computation is occurring during issue creation that interacts with these fields? Is there a way to avoid incurring that cost in a user-facing thread?
Disclaimer: I don't work on JIRA Software, so my information may be out of date.
The ranking operations have historically required several round trips to the database to implement their locking behaviour. When an issue's rank changes (or when it gets set initially), it needs to lock rows related to that operation (the rows that will end up on either side of the new rank) to prevent any possibility of two issues ending up with the same rank.
The locks are per-field, as well, so the more rank fields you have, the worse it would get.
This has historically been fairly both intrinsically expensive and a contention point, and it is definitely an area that they have wanted to improve. While they were still limited to using Active Objects for this, it was hard to see any way forward because that platform is so limited in what it can do. Now that the more powerful QueryDSL library is available, there are more options available, but I do not know what progress, if any, they might have made on that front since I last looked in on that problem.
In short, the calculation itself is not what is expensive. It is the repeated DB round trips and lock contention needed to ensure correctness that takes so much time.
I'm not sure what you mean by "all three of these". Three rank fields?
Using multiple rank fields lets you have more than one conceptual ordering of the issues. This would allow, say, developers to have a different ordering to their backlog than the ordering that managers look at. I'm not sure that having separate rank fields is altogether healthy, but it is definitely something that people do.
Ultimately, multiple rank fields is either an accident or a deliberate decision by the administrators. I can't tell you which one is the case, here; you would have to ask them if this is something that they did on purpose or not.
You absolutely do need at least one rank field to be able to use JIRA Software. It is fundamental to how boards work.
Custom fields don't have to store their values in that table, which is useful for fields that take a single, simple value. Custom fields can instead manage their own storage, and this is what lexorank fields do. The table name is
Atlassian Summit is an excellent opportunity for in-person support, training, and networking.Learn more
Hello! I'm Rayen, a product manager at Atlassian. My team and I are working hard to improve the trial experience for Jira Software Cloud. We are interested in talking to 20 people planning t...
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