In a previous blog post, we have looked into the web tools that are available in IIB v9.0 to analyze the performance of the flows and how the tools can be best used to identify why a flow message rate is low or dropping.
Here we’ll look into two other common problems. We’ll continue to use the line charts, making more use of the wealth of information provided by the 23 metrics that are available:
and the node statistics table:
Problem: CPU usage is high or increasing
This might not be a problem by itself, rather a consequence of running at a high rate.
You could select Average CPU Time/Invocation, Total CPU Time, Number of Threads in Pool as the metrics to plot. Look to see if the Average CPU Time/Invocation is stable or increasing over time.
Another idea is to check the size of the messages (choose Total Size of Input Messages or Maximum Size Of Input Messages) to see if it has increased in line with the increase in CPU usage.
If the CPU has recently increased, check the Total number of backouts , Total Number of Errors Processing Messages or Total Number of Messages with Errors.
If you order the Nodes Table by Average CPU time you can find out the most CPU intensive node and its type. Performance tips are available for Java Compute, XSLT or ESQL nodes.
Problem: Response time is high
In this case, the main metrics to use for charts are Average Elapsed time/Invocation or Total Elapsed Time. Possible causes:
- Slow response from an invoked application or service
In this case, you might want to order the Nodes table by Average Elapsed time to find out the node that takes most of the time and determine why the time is high. It may be due tp a problem with another application or service.
- A high number of backouts in message flow processing
Select Total number of backouts , possibly Total Number of Errors Processing Messages, Total Number of Messages with Errors to check if there is a correlation.
- Missing optimization (particularly for flows using HTTP and TCP nodes)
Check the node types in the Nodes Table and verify if the optimizations for each node type have been applied.
- Lack of resource (CPU, IO, memory) for the message flow to process
You might want to check Average Elapsed Time/Invocation, Average CPU Time/Invocation, Total CPU Time, Total Elapsed time, Number of Threads in Pool, Times Maximum Number of Threads Reached and see whether the flow is CPU intensive.
Then check with a system level monitor to ensure that there is sufficient CPU available and that the system is not 100% CPU busy.
- Incomplete processing including problems in a connected message flow
Check Total Number of Backouts and then analyze the connected flows in a different browser tab.
- Insufficient instances of the flow
There may not be sufficient instances of a flow to allow processing to proceed at the required rate. Particularly when a flow is running slow for example. Check Number of Threads in Pool and Times Maximum Number of Threads Reached. Look to see how many instances are defined for the message flow and whether they are all being used. This should tell you whether the peak number of threads is constantly in use.
The flow analysis tools from IIBv9.0 are very rich and flexible. They provide a variety of ways of examine the performance of your flows.