Are you here because you are seeing performance issues with certain functions in JQL Tricks plugin? Or you want to learn about it before trying out the plugin?
Are you on 5.0 or a later version? If not, please consider upgrading the plugin as version 5.0 introduced some major improvements in performance. JQL Tricks now have a calculated custom field and a custom searcher to make better use of lucene indexes. What does it mean to you? Faster Searching.
If you are on a JIRA version that is not compatible with JQLT 5.x and if you are not planning to upgrade any soon OR if you are seeing performance issues even after upgrading to 5.0, please read on. Hopefully, some of the other options might help you.
One of the major issues with JQL functions is a bottleneck in JIRA itself. When the number of issues in the search results increases, it increases the time taken to render the issue navigator. This issue was initially raised with Atlassian, along with out detailed test results, by the JQL Tricks team. All information on this can be found at https://jira.atlassian.com/browse/JRA-36368. This issue is resolved in 6.3.4+ and has had a positive impact on all JQL functions including the ones provided by JQL Tricks. If you are not on JIRA 6.3.4+ yet, upgrading will certainly improve the performance.
But resolving JRA-36368 is only one part of the problem. There is a second part, which Atlassian is trying to address soon, raised at https://jira.atlassian.com/browse/JRA-39375. Until the JQL functions can opt out of the heavy processing, there will be performance issues for larger result sets.
What does this mean to you? Until JRA-39375 is resolved, the way to achieve best results is to reduce the number of results returned by individual functions. JQL Tricks plugin helps you to do this in a couple of ways.
But what is it is not an option to reduce the result set? One of the following might help.
We hope one of the above will make a difference in your case. Let us know if you want us to help you with any specific setting.
Are you on 5.0 or a later version? If not, please consider upgrading the plugin as version 5.0 introduced some major improvements in performance. JQL Tricks now have a calculated custom field and a custom searcher to make better use of lucene indexes. What does it mean to you? Faster Searching.
If you are on a JIRA version that is not compatible with JQLT 5.x and if you are not planning to upgrade any soon OR if you are seeing performance issues even after upgrading to 5.0, please read on. Hopefully, some of the other options might help you.
One of the major issues with JQL functions is a bottleneck in JIRA itself. When the number of issues in the search results increases, it increases the time taken to render the issue navigator. This issue was initially raised with Atlassian, along with out detailed test results, by the JQL Tricks team. All information on this can be found at https://jira.atlassian.com/browse/JRA-36368. This issue is resolved in 6.3.4+ and has had a positive impact on all JQL functions including the ones provided by JQL Tricks. If you are not on JIRA 6.3.4+ yet, upgrading will certainly improve the performance.
But resolving JRA-36368 is only one part of the problem. There is a second part, which Atlassian is trying to address soon, raised at https://jira.atlassian.com/browse/JRA-39375. Until the JQL functions can opt out of the heavy processing, there will be performance issues for larger result sets.
What does this mean to you? Until JRA-39375 is resolved, the way to achieve best results is to reduce the number of results returned by individual functions. JQL Tricks plugin helps you to do this in a couple of ways.
- Limit the results by using the appropriate functions. For example,
project = XYZ and issue in parent("status = Open")
will return all subtasks in project XYZ whose parent status is "Open". But JIRA applies the AND operator after the issues are retrieved by project clause and parent function. i.e. it returns N number of issues in XYZ project, M number of issues in the entire instance with "Open" parents and then finds issues in both the result sets. In short, adding the project clause doesn't help in performance.
On the other hand, the below query:
issue in parent("project = XYZ AND status = Open")
will return the same result and will perform better. Here, parent is a single function and returns only issues matching to the query instead of searching the entire instance and then doing the AND operation.
Just by constructing the queries in the right way, you can achieve better results. - Limit functions to selected projects. This will reduce the number of issues in the context and can make a big difference with respect to the aforementioned issue (JRA-39375).
But what is it is not an option to reduce the result set? One of the following might help.
- Limit the functions to selected groups only. The original idea of some of the linking functions was to use them for reporting rather than for day to day work. For example, a normal user won't be able to run them but only an admin/project admin can do this. Initially, we introduced an option to limit all functions to selected groups. This helped a few but some customers wanted selected functions to be restricted for selected groups and leave the other functions to all. We introduced this in version 4.0.
- Increase the memory and CPU available for your JIRA instance. This might help to an extent but you will have to test it and see what are the best memory parameters for your instance. We might be able to recommend something if you are interested. Contact us.
- Use the cache. If you use a bigger cache delay, it will reduce the amount of time it takes to execute some of the performance affecting queries. As with any cache, it also means your results will not be real time and will be based on the cache delay. Again, we had only a global cache initially but 4.0 introduces a separate cache for separate functions.
Cache will not have an impact on JRA-39375 because it only reduces the time taken within the plugin, not while rendering the results in issue navigator. - Disabled the unwanted modules. It is a simple process of disabling the module from Administration > Plugins. Very useful if you are buying this plugin for some specific functions and you don't want to unleash the beast in its full fury!
We hope one of the above will make a difference in your case. Let us know if you want us to help you with any specific setting.