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 |
Beginning | 959 |
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?
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 AO_60DB71_LEXORANK
.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks for explaining. Do you happen to know if all three of these are needed for the agile features to work? Even getting rid of just two would be big performance win.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks @Chris Fuller that answers my question. To clarify, I was asking if JIRA requires the three I mentioned (Rank, Global Rank, Ranking). I take it that it does not intrinsically require these three.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Also, as a curious aside to https://answers.atlassian.com/questions/43328765 none of the above seem to appear in the customfieldvalue table.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.