InfraRED WEB GUI can be effectively used to diagnose problems in the application. This documentation explains the various aspects of InfraRED and how its features can be leveraged.
Statistics for multiple application instances / Clustered applications: If you have configured InfraRED to work as a centralized server then the Performance Summary page will list all the applications and the hosts for which data is available. You can view data for one application at a time or can select multiple applications or host names and view the aggregated data.
Usage of InfraRED in various environments: InfraRED can be used to debug performance problems that occur in production. You would need to turn on monitoring and JDBC monitoring . This would give you summary information that can be used to narrow down a performance problem, without adversely affecting the application performance. Call tracing can be enabled in the development environment, along with turning on monitoring and JDBC monitoring .
Performance Summary page gives the summary of the layers. Analysis of the statistics can be started from here. It shows you information on how much time is being spent in executing methods in each layer. The time shown includes the time spent in executing methods that belong to this layer as well as any other functions that are called from within those methods (for e.g. the web layer would include the time consumed by the web layer code, as well as time spent in lower layers). From this you can figure out which layer to investigate further. If the JDBC layer is consuming a disproportionate amount of time you can start by investigating that further.
Sql Summary: Clicking on the SQL layer link will take you to a page that has more detailed information about the SQL queries that were executed.
Expensive queries: This section lists the Top 5 expensive queries based on their average execution time. Take a close look at these queries to see if they can be tuned to perform better. Clicking on the SQL query link would show the complete query in a pop-up window. You can copy the SQL into SQL Plus or TOAD for further analysis.
Frequently used queries: The next table lists the TOP 5 most frequently executed queries. Any small improvement that can be made by tuning these queries will have a bigger impact on the overall performance of the application. This can also help you identify if there are any "n+1 query problems".
N+1 Query problem is the situation where, to fetch n objects, one query is fired to fetch the ids of all the objects and n subsequent queries are fired to fetch the attributes of the object, instead of fetching both the ids and the attributes together in a single query. For e.g. if the use case is to fetch a bunch of Accounts and if you see one query to the ACCOUNT table and N queries to the Customer table (one for each Account) n+1 problem would be evident by looking at this data. You can optimize this by modifying the code to get the Accounts as well as Customers in one query by using a join query.
Clicking on any layer will bring up the summary for that layer. This will list all the methods that have been grouped under that layer along with the average time, count, minimum, maximum time etc. You can sort on any of the fields. Also any method with an average execution time above a specified threshold (specified in the infrared-web.properties file) is highlighted with a blue background.
The summary page would point out methods that need further investigation. The average time shown here includes the time spent in executing a given method as well as the time spent in the methods that are directly invoked from within it. To investigate this further you would need to enable the call-tracing feature. Turning on call tracing adds extra overhead (up to 10%), it is not recommended to have it turned on by default in a production environment. You can turn it on for a small duration in case the issue cannot be reproduced in a development environment. Using this information if you can reproduce the problem in a development environment then you can continue the investigation in your development environment. Clicking on any method will take you to the Call traces page, which would display all the child methods that are being called from within this method. You will be able to get this information only if call tracing is turned on. You expand the tree and further drill down to identify the method that is consuming the most amount of time.
SQL queries as part of call tree: If there are any database interactions happening, the JDBC API invoked and the SQL queries executed will also be shown as a part of the call tree. This is useful in figuring out the methods that are invoking expensive SQL queries. This information is difficult to obtain even by looking at the code if you are using a tool (Toplink / Hibernate / EJB CMP) for persistence.
All the information described above is aggregated statistics. If you are debugging a particular request to your application and want to look at what transpires when a request is executed, you can look at the Last Invocations page. This is particularly very useful in dev environment. This page provides the call trace for the last 5 (this can be changed by modifying the infrared-agent.properties) requests that were executed.
