|
Sort Order:
We now have a customer with 300k issues, and this is starting to cause issues. We can either lazy-load it, or find a smarter way of doing the searching. I have a lot of ideas about how this could be improved - please ping me before implementation. We should use FieldableDocumentHitcollector as we don't need to pull in the whole document, but just the key. There is also a Synch issue, in that we store the pager in the session. 5 threads could hit this at the same time, see that it is null and all do a search (bots love to do things like this). And it really isn't thread safe. The only way to work around this issue for now is to remove the next/prev panel from the view issue page. This can be accomplished by editing the includes/panels/issue_headertable.jsp There is a section that looks like this: <%-- Display next/previous nav panel unless a search has been executed --%>
<webwork:if test="searchRequest != null">
<%-- Next/Previous nav panel--%>
<webwork:if test="pagerManager/pager/hasCurrentKey == false">
<td valign="top" align="right">
<table cellpadding="1" cellspacing="0" border="0" bgcolor="#bbbbbb"><tr><td>
<table cellpadding="2" cellspacing="0" border="0" bgcolor="#f0f0f0">
<tr>
<td bgcolor="#dddddd">
<img src="<%= request.getContextPath() %>/images/icons/undo_16.gif" alt=""
width="16" height="16" border="0" align="absmiddle" />
<b><a href="<%= request.getContextPath() %>/secure/IssueNavigator.jspa"
title="<webwork:text name="'navigator.return.search'"/> (ALT+<webwork:text name="'navigator.return.search.accesskey'"/>)"
accesskey="<webwork:text name="'navigator.return.search.accesskey'"/>">
<webwork:text name="'navigator.return.search'"/></a></b>
<webwork:if test="searchRequest/name != null">
<font size="1">"<webwork:property value="searchRequest/name"/>"</font>
</webwork:if>
</td>
</tr>
</table>
</td></tr></table>
</td>
</webwork:if>
<webwork:else>
<td valign="top" align="right">
<table cellpadding="1" cellspacing="0" border="0" bgcolor="#bbbbbb"><tr><td>
<table cellpadding="2" cellspacing="0" border="0" bgcolor="#f0f0f0">
<tr>
<td bgcolor="#dddddd">
<img src="<%= request.getContextPath() %>/images/icons/undo_16.gif" alt=""
width="16" height="16" border="0" align="absmiddle" />
<b><a href="<%= request.getContextPath() %>/secure/IssueNavigator.jspa"
title="<webwork:text name="'navigator.return.search'"/> (ALT+<webwork:text name="'navigator.return.search.accesskey'"/>)"
accesskey="<webwork:text name="'navigator.return.search.accesskey'"/>">
<webwork:text name="'navigator.return.search'"/></a></b>
<webwork:if test="searchRequest/name != null">
<font size="1">"<webwork:property value="searchRequest/name"/>"</font>
</webwork:if>
</td>
</tr>
<tr>
<td nowrap>
<font size="1">
<webwork:text name="'pager.results.displayissues'">
<webwork:param name="'value0'"><b><webwork:property
value="pagerManager/pager/currentPosition"/></b></webwork:param>
<webwork:param name="'value1'"><b><webwork:property
value="pagerManager/pager/currentSize"/></b></webwork:param>
</webwork:text>
<br>
</font>
<div align="center">
<font size="1">
<webwork:if test="pagerManager/pager/previousKey != null">
<a href="<%= request.getContextPath() %>/browse/<webwork:property value="pagerManager/pager/previousKey" />"
title="<webwork:text name="'navigator.previous.title'"/> '<webwork:property value="pagerManager/pager/previousKey" />' (ALT+<webwork:text name="'navigator.previous.accesskey'"/>)"
accesskey="<webwork:text name="'navigator.previous.accesskey'"/>">
<< <webwork:text name="'navigator.previous'"/></a>
</webwork:if>
<webwork:else>
<span class="hiddenField"><< <webwork:text
name="'navigator.previous'"/></span>
</webwork:else>
| <webwork:property value="pagerManager/pager/currentKey"/>
|
<webwork:if test="pagerManager/pager/nextKey != null">
<a href="<%= request.getContextPath() %>/browse/<webwork:property value="pagerManager/pager/nextKey" />"
title="<webwork:text name="'navigator.next.title'"/> '<webwork:property value="pagerManager/pager/nextKey" />' (ALT+<webwork:text name="'navigator.next.accesskey'"/>)"
accesskey="<webwork:text name="'navigator.next.accesskey'"/>">
<webwork:text name="'navigator.next'"/> >></a>
</webwork:if>
<webwork:else>
<span class="hiddenField"> <webwork:text name="'navigator.next'"/> >></span>
</webwork:else>
</font>
</div>
</td>
</tr>
</table>
</td></tr></table>
</td>
</webwork:else>
</webwork:if>
This whole block needs to be removed so that the panel will not appear. When Nick talks about a FieldableHitCollector he means that we call: IndexReader.document(int,org.apache.lucene.document.FieldSelector) We may get an improvement (but probably not anywhere near as much) similar to this: When we do this, we will have to change the SearchProvider interface to take a HitCollector instead of a DocumentHitCollector in searchAndSort. It was only a DocumentHitCollector more for documentation reasons rather than needing to be that. *Please note, the solution in the comment above Removing the pager dialog from the JSP will not have any effect on performance when it comes to viewing an issue. What you'll have to do is to edit the ViewIssue action, and comment out the following lines in the doExecute() method: final PagerManager pagerManager = getPagerManager(); pagerManager.updatePager(getSearchRequest(), getRemoteUser()); pagerManager.getPager().setCurrentKey(issue.getString("key")); I've attached a patch as well as a compiled ViewIssue.class (tested on JIRA 3.8.1. Use on any other version of JIRA at your own risk) to this issue. To deploy the patched class file do the following:
The fix for this issue has not been able to make it into JIRA v3.12. We are hoping to incorporate it into v3.12.1. As of writing however, there are 163 items scheduled as Fix For v3.12.1. We will not be able to include all of them. Any news about when this will be implemented? Aggelos, this issue is on our to-do list, however no fix date has been set for it yet. Thanks for the update Dushan. We have a customer with 150K issues db and we are getting some negative feedback on the performance front. So an improvement on this area would certainly help. I know that returning large resultsets and browsing though them, is not the right way to use JIRA, but in a 1000+ user base is not that easy to enforce best practices. I have created a patch for PagerManager to limit the number of searches the pager object can handle. It is hardcoded to 100 but feel free to change it. We didn't want the database to slow down on large queries and wanted to have the pager for small datasets. I hope this one proves to be useful for someone. Patch src/java/com/atlassian/jira/issue/pager/PagerManager.java from jira top directory. This patch was created for JIRA 3.13.1. Hi all, this has been fixed. I have committed a fix to 3.13.3 that should improve times significantly. Though for 4.0 I went a step further and the performance is crazy fast. Even for 150K issues it was taking less than a second on my local machine. Cheers, JIRA Developer Hi! We installed this patch on jira 3.13 on Atlassian support advice. The patch results in that sub tasks stops working, due to patch beeing incompatible with 3.13. Is there a patch available for jira 3.13? Please attach it to this issue. Kind regards, There is now a patch to versions 3.13 or high. The file is zipped. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Bug
Resolved
Major
View Issue take a long time (slow) after search returning lots of issues
This happens because JIRA is loading all search hits in order to display the ' << Previous | ABC-123 | Next >>' navigation in the top-right of each issue.