How much performance degradation with large export?

[jasongrahn]

I've read https://confluence.atlassian.com/display/JIRAKB/Export+More+Than+1000+Results+to+Excel?continue=https%3A%2F%2Fconfluence.atlassian.com%2Fdisplay%2FJIRAKB%2FExport%2BMore%2BThan%2B1000%2BResults%2Bto%2BExcel&application=cac ,  https://confluence.atlassian.com/display/JIRAKB/OutOfMemory+or+Poor+Performance+due+to+XML+View+of+a+Filter , and https://confluence.atlassian.com/display/ONDEMANDKB/Export+More+than+1000+Issues+to+Excel+from+Issue+Navigator+in+JIRA+OnDemand .

As the report I need to export is ~60k+ rows, my IT department would like to know what kind of load this will place on our JIRA instance. We plan on comparing any information provided against the system properties of our server and using this information to schedule a time where I can export my information. 

many thanks

[Midori]

You can export to Excel for further analysis with the Better Excel Plugin although it will also put quite some load on your JIRA.

Tips to reduce the load:

• Trim your export template to the bare minimum.
• Export the data set in multiple chunks and "merge" those chunks into one gigantic sheet in Excel.
  

Further tip:

• You may also want to consider use this Excel automation plugin to generate your chunks using JQL to save you the manual work.
• I'm quite sure you can use VB to merge multiple worksheets into one.

[Benito Picarelli]

Maybe he can spread his export in a bunch of bulked JQL searches to avoid overloading his instance?

[Nic Brough -Adaptavist-]

Yes, 1000 at a time, it's a sensible limit. It's there for a very good reason. What he's trying to do is wrong.

[jasongrahn]

@Benito Picarelli, I appreciate you trying to help. It seems like JIRA has indoctrinated in some that large exports are unnecessary?

@Nic Brough, If you have other recommendations on how I can pivot and analyze my data, I'm all ears. The tools I have that will allow me to crunch this in combination with my other datasets exist outside JIRA (tableau, excel, etc)... 

[Nic Brough -Adaptavist-]

I can't do much with a vague story like that. What question(s) are you actually trying to answer?

[jasongrahn]

I'm answering what degree of case load my team has worked, by issue and subissue; and by agent; and our adherence to SLA; and a host of other questions. I'll combine this with outside data as well; which is why it cannot be done within the JIRA reporting structure.

[Nic Brough -Adaptavist-]

So instead of doing random static and instantly obsolete reporting, you should be concentrating on writing something that draws data from your other systems and combines it with the RELEVANT Jira data (not extracting the whole lot and wasting time discarding 99% of it every time). Or just install Jira service desk and probably junk your other system

[jasongrahn]

The data is intended for YTD. I'm exporting a specific set of columns relevant to my research. I don't understand why you're being so aggressive?

[Nic Brough -Adaptavist-]

It'll render your JIRA useless for a while, and then crash.  It's too much, it won't cope unless you have stupid amounts of RAM allocated.

[jasongrahn]

what do you define as "stupid amounts"?

[Nic Brough -Adaptavist-]

I'd start with 16Gb and not bet on it being enough. I think the right option is to ask why you're trying to do an export that JIRA deliberately and explicitly limits, and do it properly instead of trying to bodge it.