Is there a way to estimate the time needed to perform a Jira re-index?

[Rob Horan]

Assume you are working on a Jira instance that is not your own and you think a re-index is needed.  The client asks you how long it will take.  How can you respond, given that Jira does not provide an estimate?

[Craig Castle-Mead]

Hey @Rob Horan 

The critical factors I can think of are:

• Jira version (8 has been much quicker than 7 in my experience thanks to the lucene upgrade)
• cpus (speed and cores)
• physical of virtual hardware
• have you tweaked the reindex threads value? (https://confluence.atlassian.com/jirakb/increase-speed-of-reindexing-in-jira-server-826879636.html)
• number of custom fields (and how many of them are global)
• number of issues
• heap size

If you can provide some/all of that information, users with similar environments may be able to provide some relative numbers. 

CCM

[Rob Horan]

Thanks - this was more of a theoretical question which may be applied in different scenarios, but for the sake of argument, let me just say that as an outside advisor I will likely not have the ability to get some of those answers in many cases. 

[Nic Brough -Adaptavist-]

There are far too many factors to try to feed into an estimate of re-indexing time.

A Jira with 1,000,000 issues and 5 custom fields might index faster than one with 100,000 issues and 500 fields.  10 times the number of issues implies 10 times the time, but the fields change the overhead.  It's not a simple multiplication 

You'd then need to factor in the complexity of the user base, permissions, history, differences in speed for field types (select lists are quicker to index than text fields for example), calculated fields, and that's before you move on to hardware.

It could be done.  But it will take you a very very long time to get approximate data for it and work out a rough calculation. 

The better option is to get a machine of roughly the same spec as production and try it.  Ideally on a copy of the production system.  If you can't do that, then you can very roughly say "we worked with a data set that's 5% of production, and that took X minutes, so we would expect production to take 20X minutes"  (Pad that a bit though - not everything in the index is issue based)

[Rob Horan]

As a follow up, is there a way to see how long the last reindex took?  The last 5?  Having that info available would be so helpful.

[Craig Castle-Mead]

Reindex times go in to the application logs (there’s a reindex complete - took 1234567 seconds type entry), but full indexes don’t happen by themselves and with log rotation you’re unlikely to have the last 1 reference, let alone the last 5 unless you’re shipping your logs to some longer term storage. 

CCM

[Rob Horan]

This would be very useful to have in the GUI, presented on the reindex screen.  Something along the lines of "the last (type) reindex took (length)"

[Nic Brough -Adaptavist-]

I'd love to see that, ideally for any indexing run in the last couple of months.  Foreground, Background and Project-name in the type columns, how many seconds, and and how many issues were covered (and whatever else is in the index - it's not entirely issues).  That would give us the basic numbers to estimate against.

An additional nice-to-have would be to show where the system was started in-between them, in case hardware or system settings may have been changed.