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

The fact that JIRA custom fields impact issue creation performance has been documented

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:

  1. Take a snapshot of our production instance and restore it into a development environment.
  2. Delete some custom fields (see for a fast way to do this in bulk). 
  3. Run a script to create 50 issues via the REST api and measure the average time.
  4. 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 issue
After Rank removed782
After Global Rank removed674
After 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?


4 answers

Also, as a curious aside to none of the above seem to appear in the customfieldvalue table.

0 votes
Chris Fuller Atlassian Team Oct 27, 2016

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.

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.

Chris Fuller Atlassian Team Oct 29, 2016

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.

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.

0 votes
Chris Fuller Atlassian Team Oct 27, 2016

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.

Got it. Thanks.

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Jan 08, 2019 in Jira

How to Jira for designers

I’m a designer on the Jira team. For a long time, I’ve fielded questions from other designers about how they should be using Jira Software with their design team. I’ve also heard feedback from other ...

1,154 views 5 10
Read article

Atlassian User Groups

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!

Find my local user group

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

Groups near you