Analyze the root cause
At this point, you have successfully used Performance Tester to uncover a performance problem in your application. The next question you will ask yourself is, "What is causing the problem?" To get to the bottom of this question you will use Performance Tester's Root Cause Analysis facilities. In this section, you will re-run your test with additional data collection tools engaged. The additional information will help you determine if you are facing a hardware or software issue and drill down to the root cause of the performance bottleneck.
- Double-click the AdventureBuilderLoadTest schedule in the Test Navigator view.
- Revisit some of the additional execution controls on the schedule: start by selecting the top node of the Schedule Contents again.
- Select the Resource Monitoring tab in the Schedule Element Details area.
Resource monitoring enables Performance Tester to log any system parameter
perfmon, Unix or Linux
rstatd, or Tivoli Monitoring.
- Check Enable resource monitoring.
- Click Add New... to define a new server on which to monitor resources. Note that you may need to scroll down the right portion of the Performance Schedule view to see the button.
- In the Resource Monitoring window, enter
localhostas the host name. Check Windows Performance Monitor. Note that in this trial environment, the Web server, application server, and Performance Tester system are all running on a single machine: localhost. This is, of course, not a realistic situation. In a true performance testing environment, you can define any machines that might be part of your application or test system.
- Select the Resources tab. After a few seconds, you can see the extensive list of counters available. To keep it simple, deselect all counters except Memory > Pages/sec and Processor > % Processor Time.
- Click OK to close the Resource Monitoring window.
- Select the Response Time Breakdown tab in the Schedule Element Details area of the Performance Schedule.
- Check Enable collection of response time data. This enables Performance Tester's response-time data collection infrastructure.
- Since you know the only test that actually visits the Checkout page is PurchaseIslandAdventure, select only that test.
- In the Options area, set the Detail level to High.
- Save the schedule by pressing Ctrl-S.
- Right-click the
AdventureBuilderLoadTestschedule in the Test Navigator. Select Run As > Performance Schedule. Performance Tester launches the test just as before, but this time with resource monitoring and response-time breakdown collection engaged.
- While the performance schedule is executing, select the Resources tab on the
Performance Report. This time, you'll see data for the resources you chose to
collect in the schedule.
Figure 21. The Resources tab on the Performance Report
- The data you see here, although accurate, is not really representative of a
typical load test. In this trial environment, the Performance Tester load
generation, Web server, application server, and database server are all
running on a single machine. You would normally track resources on each tier
of your application. In addition, the load test you just ran was of very short
duration. Normally, performance tests will be significantly longer, allowing
the systems to reach a steady state. Nonetheless, the trial system gives you a
sense of how easy it is to track resource utilization during a performance test.
If you have a concern, you can now go to the Response vs. Time Detail tab, right-click the graph, and click Add/Remove Performance Counters to overlay resource counters onto page response data. This helps you visually correlate any spikes in resource utilization with page activity.
- Since it doesn't appear that the performance issue with Adventure Builder is hardware related, use the response-time breakdown data to find out if it is software related.
- Select the Page Performance tab of the Performance Report.
- Drill down into what went on behind the scenes for the Checkout page. Right-click the bar in the graph for the Checkout page and choose Display Response Time Breakdown Statistics....
- Select the /ab/checkout.do URL from the Selection Wizard and click Finish. The Response Time Breakdown Statistics view lists methods called on the server tiers of the Adventure Builder application. There are various ways to examine this information.
- Switch to the Tree Layout view using the Layout button in the upper-right
corner of the view.
Figure 22. The Tree Layout view
Now sort by descending cumulative time by clicking twice on the Cumulative Time column header.
The top node represents the machine on which the software components ran. In your case, this will be the network name of your machine. In this trial, all system-under-test and test-harness components are running on a single machine. In a real-world test, you would likely see multiple machines listed.
The second-level node labeled J2EE/WebSphere... is the WebSphere application server component. From the information here, you can quickly see that the J2EE facet type consuming the most cumulative time is the Servlet.
- Expand the Servlet node and the
com.sun.j2ee.blueprints.waf.controller.web package, and the
MainServletclass nodes. This tells you that the four invocations of the
doPostmethod in the
MainServletclass consumed 42.113 seconds. Note that your actual values will probably differ.
Figure 23. Response time of the doPost method of MainServlet
- Right-click the
doPostmethod and choose Open Source. Well, what do you know -- you have located the source of your performance problem!
Figure 24. A sleep statement in the source code