Welcome back to the first blog of the new year 2020, and this time I will be discussing the tips and tricks to improve the performance of the Footprints application. Below are the points
Influence of Time-Based Rules against a large data set:
Consider increasing the number of threads available for processing Time-Based Rules if the total number of Time-Based Rules that execute at the same time is large or there are many Time-Based Rules that perform complex tasks like creating new tickets. The number of threads available for processing Time-Based Rules can be configured in the Administration Console under System Management / System Settings / Miscellaneous. The default value is 10 threads and should be sufficient for typical deployments. Increasing this number does not necessarily guarantee that all Time-Based Rules will be executed faster; it depends on how many rules actually end up executing concurrently and their complexity.
Depending on when specific Time-Based Rules are set up to run, the number of rules whose execution schedule happens to coincide is divided amongst the number of threads specified. For example, if a deployment has 3 workspaces with a total of 40 Time-Based Rules, and at a given time 30 of those rules need to execute then 30 rules divided into 10 threads result in 3 rules executed in each thread. The number of threads that can be specified depends on an operating system, platform and available hardware resources (i.e. CPUs and memory) allocated to the FootPrints application server (i.e. Tomcat.)
Use caution when increasing the number of threads for it may in turn negatively impact the performance of other parts of the application if hardware resources allocated to the FootPrints application server (i.e. Tomcat) are insufficient to deal with the increased processing load.
Introduce an archiving process as a good practice:
In version 12.X/20.X, all business rules; Time-Based ones included; are executed for all existing tickets in a workspace. The automated process is only checking for each and every ticket, if it is compliant with the business rule's criteria you have set in place. If you do this against a handful of tickets, let's say a few hundred, then no problem at all, the system can cope with it.
If you have thousands, tens of thousands, or even hundreds of thousands of tickets in a single workspace, then you start having a performance problem and sometimes cause delays in other rules to be applied to your tickets...
For time-based ones, this happens every XX minutes (it is recommended not to set below 15 minutes) and takes a really long time.
We need to archive the older tickets.
Tickets will remain accessible, but we stop the automation on them.
Please find below the article for the archive process.
Below are some pointers which need to check-points for better performance:
1.) Has your SQL server been configured as per this article? The setting shown in the article is required for FP to operate optimum condition. Failing to this setting will lead to SQL deadlocks.
2.) Did you optimize your Antivirus/Malware Tool not to interfere with Tomcat and Footprints app folders and files? If yes then we need to exclude and Tomcat and Footprints folder from Antivirus/Malware scanning. It is not recommended though to exclude the attachment folder.
3.) Did you alter/customize your Tomcat server.xml? Or do you use the out-of-the-box configuration?
4.) Did you optimize your java options? I assume you still use the out-of-the-box configuration?
5.) When was the last time the database was properly backed up and re-indexed?
6.) I assume the instance is virtualized? If so, is the hardware/hypervisor under strain in memory and disk IO? The FootPrints application server by default is configured to use up to 450 connections. The database server and application server must be configured accordingly; otherwise, performance will be affected. Note that by increasing the number of connections on the database server, the database host will experience increased CPU, memory and I/O activity so make sure the hosting hardware adequately supports the additional processing load.
7.) Are you sure that the CPU allocated to the server at least 2GHz or higher? Consider that system requirement minimum requirement mentioned in the article, for better-performing application and database server it is crucial to understand that having more CPU is more beneficial.