Monday, August 29, 2011

HP Analysis

The goal of analysis is to find out bottlenecks in the application under test and then investigate the source of bottlenecks.
  • What was the average transaction response time?
  • What was the status of server resources when response time was high?
  • Did we meet the SLA?
  • What component of the system is responsible for decrease in performance?
  • Can we investigate the possible cause of the bottleneck by correlating the performance related data of the system and providing the solution to overcome it?
“After analyzing the Average Transaction Response Time graph, we investigate the reason for high response time at particular instant and using graph auto correlation we come to conclusion that there was some system memory shortage at that particular moment”.

HP Analysis Graphs

Analysis tool shows reports and graphs of the data captured from system under test. There are many graphs like,
  • Running Vusers
  • Hits per Second
  • Throughput
  • Average Transaction Response Time
  • Windows Resources
Let us focus on Average Transaction Response Time graph,



By observing the graph you can say that, the average response time of check_itinerary transaction fluctuate with big difference. It goes to peak value at certain time. If everything is working fine then average response time should be relatively stable.
Use Filters to see what exactly you want to see in graph.

Merging Graphs

You can merge graphs to see the effect of one parameter on other. There are 3 ways to merge graph,
  • Overlay: View contents of 2 charts that share a common X Axis.
  • Tile: View the contents of 2 charts that share a common X Axis, one above the other.
  • Correlate: Plot Y axis of two charts against each other 
You can see in above figure that we have merged the Average Transaction Response Time and Number of Vusers using correlate merge. The average response time increases as the Vusers increases.
When user reaches to 63, 64 there is a sudden raise in the response time, from this you can say that there must be some issue with application so that response time got raised.

Graph Auto Correlation

Click on the Average Transaction Response Time graph. Look at the check_itinerary transaction, you can see that average response time started to increase at time slice of 2-4 minutes.
To auto correlate, right click on the check_itinerary transaction and choose Auto Correlate…





Auto Correlate pop-up will show up. Set the time range according to the peak value range of the response time.

In correlation options there are many components from that select Windows Resource.



When you are done with all settings click on Ok to auto correlate,


From the graph you can see that, Private Bytes and Pool NonPaged Bytes are very high at same time slice. So by this you can say that there may be shortage of system memory at that particular moment when response time for check_itinerary transaction was high.

HP Diagnostics


HP Diagnostics falls into the middle ground between Quality Assurance and Operations Performance Validation.

For developers, having Diagnostics means that tracing code doesn’t have to be added and removed. This is a big side effect of why diagnostics can improve performance.

Diagnostics is the science of pinpointing the root cause of a problem. LoadRunner is the first load testing tool to provide a set of Diagnostics modules that trace, time, and troubleshoot end-user transactions across all tiers of the system. These modules extend LoadRunner to provide a unified view of both end-user experience and application component (method, SQL) level performance. The intuitive visual interface allows the user to drill down from a problematic business process all the way to the poorly performing component. This granularity of results ensures that every load test provides development with actionable results, thus reducing the cost and time required to optimize J2EE/.NET applications.

Diagnostics for J2EE/.NET provides complete visibility into the transaction performance of J2EE/.NET- based applications. Users can drill-down from a poorly performing end user transaction and view JNDI, web, EJB, and JDBC performance. Having identified the top-time layer, users can further drill-down to the Method or SQL level and pinpoint the slow SQL query or method impacting the end-user. This granularity of results data ensures that every load test provides development with actionable results thus reducing the cost and time required to optimize J2EE/.NET applications.

Probe Profiler Tabs



Summary
  • Memory
  • Load
  • Shortest Requests
Hotspots
  • Slowest Methods
  • CPU Hotspots (Methods)
  • Slowest SQL
Metrics
  • System (Host) CPU, Memory Usage, PageInsPerSec, PageOutsPerSec, PageOutsPerSec, Disk, Network
  • JVM: Probe: HeapFree, HeapTotal, HeapUsed
  • Java Platform: Classes, GC, Threads
  • Mercury System
  • WebLogic: EJB, Execute Queues, JDBC, etc.
Threads (JVM 1.5)

All Methods

All SQL

Collections (using LWMD)

Exceptions

Server Requests

Web Services