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: * Take a snapshot of our production instance and restore it into a development environment. * Delete some custom fields (see https://answers.atlassian.com/questions/43214384 for a fast way to do this in bulk). * Run a script to create 50 issues via the REST api and measure the average time. * Repeat #2 and #3 until there were no more custom fields. 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: * Rank * Global Rank * Ranking 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: StageAverage time in milliseconds to create issueBeginning959After Rank removed782After Global Rank removed674After Ranking removed332 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?

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; } } }

How do Greenhopper lexo-rank custom fields impact Jira issue creation performance?

dmitri_z5hhjq

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:

Take a snapshot of our production instance and restore it into a development environment.
Delete some custom fields (see https://answers.atlassian.com/questions/43214384 for a fast way to do this in bulk).
Run a script to create 50 issues via the REST api and measure the average time.
Repeat #2 and #3 until there were no more custom fields.

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:

Rank
Global Rank
Ranking

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?

Accepted answers

All comments

dmitri_z5hhjq

Also, as a curious aside to https://answers.atlassian.com/questions/43328765 none of the above seem to appear in the customfieldvalue table.

crf

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.

crf

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.

dmitri_z5hhjq

Got it. Thanks.

dmitri_z5hhjq

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.

crf

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.

dmitri_z5hhjq

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.

Welcome!

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

Quick Links

Find more posts tagged with

jira

jira-software

performance