Understanding TRIRIGA Performance
Performance of TRIRIGA is a bit complex and there is no one thing that can be done to improve performance. Performance can be impacted by hardware, network connectivity, software versions, queries, and indexes. But there are some things can be reviewed to help point you into a direction where to look and what to do.
Performance on queries is taking a long time to run, which is impacting the ability to use TRIRIGA. If you have a query that is taking more than 1000 milliseconds to run, that is too long.
Performance issues can have many causes: hardware, network connectivity, software versions, queries and indexes to name a few. Some things like hardware and network connectivity are out of our control and need to be reviewed by your own IT department. Though we do provide a list of minimum hardware requirements that TRIRIGA should be running on.
Diagnosing the problem
To help diagnose the problem, TRIRIGA has performance logs that can be enabled, retrieved and analyzed. There is a wiki page that describes the process of enabling the performance log files as well as analyzing them, which can be found here
The wiki will walk you through how to enable the performance log and then analyze the output.
In case of performance concerns, TRIRIGA Administrators should ALWAYS review best practices to ensure they are following recommendations before entering a PMR. The wiki regarding Performance can be found here
Resolving the problem
Once you have the performance log, you can create a pivot table to analyze the results and it will look like the following below.
The columns shown are
The name of the process (A)
The total duration of all executions of that process - in milliseconds (B)
The longest execution of that process out of all executions in milliseconds (C)
The Average execution time of the process (B/E) stored in, in milliseconds (D)
The number of executions the process had during the log generation (E)
We know that anything running longer than 100 milliseconds it long running so those queries should be looked at. So we can see in this example that the issue appears to be in the database, so then appropriate actions against the database should be made.