Slow System Performance
Problem
Running SIL scripts causes the system to slow down or increase response times.
Solution
Contrary to what you might be experiencing, running SIL scripts requires very little system recourses and should not impact your system. However, the SIL scripts make Jira/Confluence do many different operations very quickly. Each of these operations may actually kick of several native processes simultaneously in Jira or Confluence. When all these separate processes run at the same time you might begin to experience performance degradation. So the problem may be that your system may not be optimized to run ANY automation in a performant manner. This is the issue that needs to be resolved.
Database connection pool
The first things to check would be with your database configuration. While your current configuration might be working smoothly now, adding automation from any product will increase the number of calls both to and from the database. If the database is not configured properly to handle the volume these extra calls can cause some perceived slowness to some unlucky users. However, some simple connection tuning can quickly resolved the issue. In general, you should have more connections than users. If you have 100 users and only 10 database connections open you are going to experience some performance issues. How could all 100 users use Jira at once if there are only 10 database connections open? Keep in mind that the automation may need to use some of these connections in order to perform its tasks.
See this article for more information about tuning database settings.
Limited system resources
The size of even a very large SIL script is only a couple of kilobytes. It only takes a couple of megabytes of memory to run a SIL script and if running a SIL script causes problems with your system odds are you have bigger problems hidden within your Jira instance. Make sure the system has at least 512mb of memory free - any Jira instance should have gigabytes of available memory but if at least 512mb of free memory is not available your system could experience issues while running a script.
Other tips for keeping Jira running swiftly
Test scripts out before putting into use - if the script does not perform a batch operation and is not dependent on another system, the script should complete running in milliseconds. If it is a basic script and does not complete after several seconds there could be a problem with the script or with the Jira instance.
Do not use the scheduler too often - the SIL scheduler is really designed to kick off batch jobs during off hours. However, there are many use cases that require the scheduler to be run periodically throughout the day. It is not a good idea to run these jobs too close together because they will keep using the system resources in the background. For example, if a script is scheduled to run every 60 seconds it could be constantly consuming systems resources (memory and processor cycles) and overrunning the Java garbage collection system which would spell bad news for your instance. There is probably a better way to solve the problem than to design an solution like this.
Check your Time to Live settings - there is a self preservation system in place for SIL scripts called Time to Live. If a script gets stuck and runs too long then it will automatically get dropped from Jira and the system will attempt to terminate the thread. Make sure this setting is set appropriately and the system is not waiting too long before trying to kill the script. This setting should be set to the shortest time your scripts allow.
Avoid infinite loops in scripts - an infinite loop can occur easily if you write a script that requires Jira to perform an action in order for the loop to break. For example, the script below requires the status of the issue to be updated before it will stop looping:
while(status != "Done") { autotransition("Done", issueKey, true, true, true); }
But, what if the script is run by a user who does not have permission to transition the issue? Answer, the script will keep running and consuming resources until it is killed. Solution, avoid a script like this at all cost. You will most always find these with 'while' or 'do-while' scripts. If writing the code like this is absolutely necessary (and it can be) it is good practice to put in a safety like this:
number loopLimit = 0; while(status != "Done" && loopLimit < 10000) { autotransition("Done", issueKey, true, true, true); loopLimit ++; }
If the action is not completed within 10 thousand loops it probably isn't going to happen at all. A script like this will allow the loop to execute 10,000 times before it stops.
Still having a problem?
Contact support to get more help or even leave a suggestion to be added to this page.