The J2EE Transaction Breakdown with Mercury’s Optimization Suite
Mercury Interactive’s LoadRunner is a leader in the performance-testing market. Its ability to create large volumes of data is legendary, and its ability to monitor the systems being tested provides great value. The J2EE Transaction Breakdown Diagnostics Module, LoadRunner, brings detailed J2EE transaction analysis into the mix.
Figure 1 illustrates at a high level the degree of monitoring and analysis available to the performance tester. The J2EE Transaction Breakdown allows each tier to be viewed, with detail to the method level for the application and Web servers. In addition, specific database queries can also be viewed.
The module provides for true integration of performance testing and performance monitoring. This allows greater diagnosis capabilities, improved control over the J2EE testing scenarios, and superior ability to pinpoint specific performance issues. For this review, I tested the WebLogic J2EE sample, Avitek Medical Records, using my machine as both the application server and the testing environment. My script exercised the three applications (patient, doctor, and admin), each of which have slightly different application architecture designs so I could expect to see some differences on similar calls.
The first step was to update the startup file for the WebLogic domain. I had to make the following updates to the startup file (startMedRecServer):
set MERC_TXBD_HOME=c:Progra~1Mercur~1J2EE_TXBD_Probe
set CLASSPATH=%WEBLOGIC_CLASSPATH%;%CLASSPATH%;%MERC_TXBD_HOME%dat;
set PATH=%PATH%;MERC_TXBD_HOME%bin
“%JAVA_HOME%binjava” %JAVA_VM% %MEM_ARGS% %JAVA_OPTIONS%
-Xbootclasspath/p:%MERC_TXBD_HOME%classesboot
When the server starts up, look for “Initializing Transaction Break Down Probe” to confirm that the changes had an impact and the Mercury Probe was initiated. After making these changes, I went into the Virtual User Generator and generated a script of the steps to take during processing. These scripts are necessary during performance testing, and the interface was simple to use. I called the URL Web interface for the Avitek Medical Records sample and began recording. Transaction segments are user defined, so you can create transactions to precisely meet your needs.
Once the script was created, I created a Controller Scenario, which utilizes the script to simulate the number of users. The license associated with the copy of the product I had permitted only one user. The next step was to start the scenarios and then monitor the results.
The LoadRunner Controller provides real-time monitoring for users to analyze J2EE component metrics. The metrics are gathered by an agent installed on the application server to collect information on the J2EE components. These measurements are sent from the application server back to the LoadRunner Controller.
The LoadRunner Controller application consists of three tabs: Design, Run, and J2EE Diagnostics. The Design tab allows various scenarios to be grouped and scheduled.
The Run tab (Figure 2) allows a variety of statistics and measurements from the running scripts to be captured and analyzed as graphs and tables. Many of these real-time measurements can be captured and stored as HTML, so any moments that could illuminate can be reviewed later. The viewer determines the number and type of measurements to display at any one time. Of particular interest to J2EE testers and developers are the WebLogic measurements and the Java Performance graphs. Although the setup for the WebLogic measurements required updates to some configuration files (I am using WLS 8.1 and JDK 1.4, not currently expected defaults of the product), the effort proved worthwhile.
The WebLogic measurements use JMX to access application server-specific detail. The measurement alternatives are vast, and include the ability to review measurements about logging, the JVM itself, servlets, EJB components, JMS connections, and the JDBC connection pool. The Java Performance graphs provide method-level detail on average response times and method call per seconds. Evaluating this information for Avitek showed me that my limited load was hardly phasing the application and that my longest-running, server-side transactions were logging in as an admin, denying Avitek patient requests for enrollment. Each had an average response time of about 0.3 seconds and involved the admin application, so I was curious if there was a common cause for their slower (but not slow) response times.
The final tab shows detailed J2EE Diagnostics. The J2EE monitor provides the following information for each J2EE component:
• Average response time per method/query
• Number of method calls per second
With such coverage of the J2EE architecture, users can get an overview of the entire activity within the system. They can very easily correlate the end user response time with the Web server activity (servlets and JSP data), application server activity (JNDI and EJBs), and back-end activity of database requests (JDBC methods and SQL queries). All of these measurements can be drilled down to the specific method level.
I was curious about the Deny Request transaction, so I brought up a Transaction Chain of Calls (see Figure 2). This report shows the measurement diagnostics for a transaction by method, on one screen, providing an immediate breakdown as to the longer parts of the transactional call. Looking at this report, it became apparent that the JDBC SQL execution for getting the patient took about 32% of the total transaction time.
The actual update to the patient itself took only 4% of the time. A similar transaction from the Patient application took much less time. The reason: the method by which the Patient EJB was generated. The Admin transaction used the findByUserEJB method while the Patient looked up by primary key. The difference was the time it took for the query to retrieve, as the following data illustrates:
Patient – Update Profile Transaction
EjbFindByPrimaryKey Query:
Average Response Time: 0.01 seconds
SELECT WL0.id , WL0.address_id , WL0.dob ,
WL0.email , WL0.first_name , WL0.gender ,
WL0.last_name , WL0.middle_name , WL0.phone ,
WL0.ssn FROM patient WL0 WHERE ( WL0.id = ? )
Admin – Deny Request Transaction
EjbFindByUserEJB Query:
Average Response Time: 0.06 seconds
SELECT WL0.id , WL0.address_id , WL0.dob ,
WL0.email , WL0.first_name , WL0.gender ,
WL0.last_name , WL0.middle_name , WL0.phone ,
WL0.ssn FROM patient WL0 WHERE ( WL0.email = ? )
This is obviously just the tip of the iceberg for the type of the analysis that can be performed.
The final part of the toolset that I evaluated was the LoadRunner Analysis tool. This product uses the results of the scripts from the Controller Run efforts for additional review and analysis. The J2EE analysis reports provide transactional response time for the server, time spent in each server element, method calls per second, and average method response time, among others. Multiple scenarios and transactions can be statistically analyzed to determine if any correlation of behavior exists. In addition, all of these reports can be drilled down or broken into their component Transaction Chain of Calls, which can then be printed or stored as HTML.
ConclusionMercury Interactive has created a unique product that will greatly accelerate J2EE performance-testing efforts. By integrating the performance-testing tool with advanced J2EE diagnostics measurements and capabilities, performance problems can be simply diagnosed before production. This was an extremely easy tool to set up, and I was able to monitor any application of my choosing. It should be noted that Mercury Interactive also provides products for J2EE production monitoring and deep diagnostics, but these tools were not reviewed.
Mercury Interactive’s LoadRunner is a leader in the performance-testing market. Its ability to create large volumes of data is legendary, and its ability to monitor the systems being tested provides great value. The J2EE Transaction Breakdown Diagnostics Module, LoadRunner, brings detailed J2EE transaction analysis into the mix. Figure 1 illustrates at a high level the…
The J2EE Transaction Breakdown with Mercury’s Optimization Suite
Mercury Interactive’s LoadRunner is a leader in the performance-testing market. Its ability to create large volumes of data is legendary, and its ability to monitor the systems being tested provides great value. The J2EE Transaction Breakdown Diagnostics Module, LoadRunner, brings detailed J2EE transaction analysis into the mix.
Figure 1 illustrates at a high level the degree of monitoring and analysis available to the performance tester. The J2EE Transaction Breakdown allows each tier to be viewed, with detail to the method level for the application and Web servers. In addition, specific database queries can also be viewed.
The module provides for true integration of performance testing and performance monitoring. This allows greater diagnosis capabilities, improved control over the J2EE testing scenarios, and superior ability to pinpoint specific performance issues. For this review, I tested the WebLogic J2EE sample, Avitek Medical Records, using my machine as both the application server and the testing environment. My script exercised the three applications (patient, doctor, and admin), each of which have slightly different application architecture designs so I could expect to see some differences on similar calls.
The first step was to update the startup file for the WebLogic domain. I had to make the following updates to the startup file (startMedRecServer):
set MERC_TXBD_HOME=c:Progra~1Mercur~1J2EE_TXBD_Probe
set CLASSPATH=%WEBLOGIC_CLASSPATH%;%CLASSPATH%;%MERC_TXBD_HOME%dat;
set PATH=%PATH%;MERC_TXBD_HOME%bin
“%JAVA_HOME%binjava” %JAVA_VM% %MEM_ARGS% %JAVA_OPTIONS%
-Xbootclasspath/p:%MERC_TXBD_HOME%classesboot
When the server starts up, look for “Initializing Transaction Break Down Probe” to confirm that the changes had an impact and the Mercury Probe was initiated. After making these changes, I went into the Virtual User Generator and generated a script of the steps to take during processing. These scripts are necessary during performance testing, and the interface was simple to use. I called the URL Web interface for the Avitek Medical Records sample and began recording. Transaction segments are user defined, so you can create transactions to precisely meet your needs.
Mercury Interactive’s LoadRunner is a leader in the performance-testing market. Its ability to create large volumes of data is legendary, and its ability to monitor the systems being tested provides great value. The J2EE Transaction Breakdown Diagnostics Module, LoadRunner, brings detailed J2EE transaction analysis into the mix. Figure 1 illustrates at a high level the…