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 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:

  1. Take a snapshot of our production instance and restore it into a development environment.
  2. Delete some custom fields (see https://answers.atlassian.com/questions/43214384 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
Beginning959
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

This widget could not be displayed.

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

This widget could not be displayed.
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.

This widget could not be displayed.
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.

This widget could not be displayed.

Got it. Thanks.

Suggest an answer

Log in or Sign up to answer
Atlassian Summit 2018

Meet the community IRL

Atlassian Summit is an excellent opportunity for in-person support, training, and networking.

Learn more
Community showcase
Posted yesterday in New to Jira

Are you planning to trial, or are currently trialling Jira Software? - We want to talk to you!

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...

54 views 1 0
Join discussion

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