The HP Diagnostics Software is a standalone software of its own that is fully functional by itself. It is designed to profile J2EE, .NET or ERP/CRM application, by capturing duration at the module level, displaying chain of calls, monitoring heap size and garbage collection. Of course, these are some things that you may be interested in J2EE from the overview level and Diagnostics have more to offer than the mentioned.

For sales talk which is not part of the scope here, you might want to refer to the official vendor website. Before we go further,the discussion here will be specified to performance testing (LoadRunner/Performance Center) and J2EE.

The Diagnostics setup comprises of the Probe/Profiler and the Server (Commander). Note that Probe and Profiler will be use interchangeably in this article. Previous version of Diagnostics, 4.2 and earlier have the Probe/Mediator/Commander however that was been incorporated into just the Probe and Commander which reduces the amount of setup effort. Note as of this writing, the latest Diagnostics is 6.6.

A Commander is installed to collect all the monitoring data from the probes. The processing of the monitoring individual probes are then performed on the Commander where you can view it via port 2006 on the browser. The Commander also servers as the centralizing the entire Diagnostics collecting the data from all the probes that is connected to it.

So with Diagnostics, how does it compliment LoadRunner? LoadRunner does not report specified/drill down to module-level, or provide information of problematic modules (that maybe causing the bottleneck). It only reports system bottleneck in a bigger picture, such as CPU, Memory, Network or Disk usage. With Diagnostics, you can go a step further by monitoring the memory usage of the application server, breaking them down to each module level.

For example, in a J2EE application launched from BEA WebLogic, the process that runs the application is a java.exe. From an OS-level monitoring perspective, we can only know the CPU, Memory or Disk utilization on the process level, or even further to a thread level. However, we do not know what are the internals that maybe causing the bottlenecks, such as Garbage Collection type and frequency, the amount of objects created in the JVM or the method in the JVM that is using the most processing time. As such, Diagnostics will come into play to fill up the gap.Through this implementation, you can work down from the server-level (OS) into the application-level systematically.