import com.atlassian.jira.ComponentManager double totalTime = 0 def scripttime=System.currentTimeMillis() if (issue.getIssueTypeId()=="21") { // Epic def componentManager = ComponentManager.getInstance() def issueLinkManager = componentManager.getIssueLinkManager() def time=0 issueLinkManager.getOutwardLinks(issue.id)?.each {issueLink -> if (issueLink.issueLinkType.name == "Epic-Story Link") { time=issueLink.destinationObject.getTimeSpent(); if (time!=null) totalTime += time/3600; } } } scripttime = System.currentTimeMillis()-scripttime; log.warn ("ScriptField Epic time summary took [ms] "+scripttime) return totalTime
I can't reproduce any problem here at all. I tried your script, around 100 issues, displaying the script field value in the issue navigator, and it takes around 500ms total.
There must be some other problem. What is the template for this field?
> JIRA evaluates the custom field for each issue in the navigator - is there some overhead in Jira, while calling and executing groovy script?
Not in the sense that you mean... it's not treated as a script, it's just calling a method on a class that's in memory. The script is only compiled to a class once.
> I would expected that Jira takes the values from Lucene index...
It uses the index for searching, but not for displaying the values. I agree with you though, that would be better.
Rather than checking for issuetype == 21, why don't you associate this field only with Epics... at least that will mean it will only be evaluated for epics, and you can see if that makes a difference.
But like I say, for me, a hundred invocations of this script takes < 10ms.
Also try replacing the script with just "return 1", and see if that makes a difference. Try to narrow this down a bit...
The check for issuetype==21 is "only for sure" - the field is associated only to Epic issue type and only to this one specific project in its configuration.
The script itself tooks only several milliseconds (as logged using log.warn() in my script):
ScriptField Epic time summary took [ms] 16 ScriptField Epic time summary took [ms] 2 ScriptField Epic time summary took [ms] 7
But JIRA says (with profiler turned on, for a while) something like this:
[236ms] - Rendering navigable field 'customfield_12253' for issue: HRM-106 ... [243ms] - Rendering navigable field 'customfield_12253' for issue: HRM-105 ... [208ms] - Rendering navigable field 'customfield_12253' for issue: HRM-104
and issue navigator's loading is slow.
I use the standard "Number Field" template.
All I can suggest is using a proper profiler like JProfiler or yourkit, and turning on the CPU monitoring when you run the query. I can't reproduce any problem at all here.
I have seen big performance problems with some of jira's templates, particularly the one that renders a user profile (with avatar and full name etc), maybe it's something similar.
Thank you, I'll try it and write results.
We have the same case. If we do not include the scripted field as a result column, a sample search returning 268 issues takes 10 secs otherwise around 90 secs. When we enabled the JIRA profile, it shows that for every record, it takes almost 900 ms. in the "IssueTableHtml" step. (Our version of JIRA is 6.3.15)
You need to make sure you have set a searcher for the field, otherwise it will be recalculated for every issue (in order to show the value)...
Thank you for your answer. Users requested a field to get and search "due date change count for an issue." Searcher is "Number Searcher" and Template is "Number Field" The code (I know, far from optimum) is as belows: import com.atlassian.jira.ComponentManager import com.atlassian.jira.issue.history.ChangeItemBean def componentManager = ComponentManager.getInstance() def changeHistoryManager = componentManager.getChangeHistoryManager() List<ChangeItemBean> issueDuaDateChangedManager = changeHistoryManager.getChangeItemsForField(issue, "DueDate") def duadateChangeMinItem = 0 def duadateChangeCount = 0 for (entry in issueDuaDateChangedManager){ if(duadateChangeMinItem == 0){ duadateChangeMinItem = entry.getCreated().getTime() duadateChangeMinItemValue = entry.getFromString() } else{ if (entry.getCreated().getTime() < duadateChangeMinItem) { duadateChangeMinItem = entry.getCreated().getTime() duadateChangeMinItemValue = entry.getFromString() } } if(duadateChangeMinItemValue){ duadateChangeCount = issueDuaDateChangedManager.size() } else { if (issueDuaDateChangedManager.size() > 0) { duadateChangeCount = issueDuaDateChangedManager.size() - 1 } } } duadateChangeCount as Double
I don't see a real problem in the script... I think there is another issue though. Why does the search without the field take so long to render? 10s is far too much. Can you look for the diagnostic info in the html at the bottom of the page...
It looks like you're new here. Sign in or register to get started.