All about Diagnostics module in LoadRunner
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/MediatorCommander 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.The Profiler/Probe is installed on the application server (e.g. BEA WebLogic) and instrumented in order to collect statistics. The instrumentation is in the form of adding an additional parameter for the startup script for the application server. The instrumentation also deviates with each type of application server specifically to the JVM type (e.g. HotSpot JVM, JRockit JVM). By default, you can view the data locally on port 35000 or via the Java Profiler application.
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.
Having mentioned the above, Diagnostics do have it’s caveats which it is important for you to take note: (1) Diagnostics can only report modules/calls that are made on the Application Server. Therefore, Store Procedure Calls on the Database Servers will not be reported during the profiling. (2) The probe is considered an intrusive agent as it is required to be installed on the application server (which maybe scrutinized with security or server team causing inconvenience). (3) Lastly, the probe creates a monitoring overhead in the application server as it examines the byte codes in the JVM. For this, the recommendation is not to perform a large load test in conjunction with the Diagnostics but rather, run a mini load test of about 10% of the actual load. Another good tip before kicking off with Diagnostics, log a service request with HP to verify the compatibility for the probe with the Application Server . They should be able to tell you what they had tested (QAed) before and this will greatly save you alot of unnecessary time when the setup of Diagnostics really take place. Having said that, the instrumentation and compatibility is quite dependent on the type of JVM that the Application Server is running on. Therefore, know the version and type of JVM well before proceeding.
Troubleshooting; when the probes are not reporting the data back to the Controller (in a LoadRunner setup), it can be tied to various reasons. However, the main ones maybe caused by (1) unsuccessful or no instrumentation (remember, you need to instrument the application server after the installation), (2) ports between the Controller, Diagnostics and Probe are not opened, or (3) application server or Diagnostics server are not running When working with LoadRunner/Performance Center, always ensure that the Diagnostics setup is fully functional before adding the Diagnostics Module into the LoadRunner monitoring. This is an effective method in troubleshooting Diagnostics/LoadRunner integration problems in a load test setup.
Licensing; Diagnostics is bounded by (1) the number of probes that can be installed and (2) the number of Diagnostics Server that is been implemented. This license is solely used for Diagnostics only which should not be associated with the one in LoadRunner. In order for Diagnostics to work with LoadRunner/PC, an additional license used by LoadRunner called, Diagnostics Module License is required. This will allow the monitoring data from the Diagnostic server to be incorporated into the load test result.
To start familiarizing the Diagnostics Software (Probe and Commander), it will be advisable to spend at least two days to explore the features and getting used to the setup/instrumentation. BEA WebLogic offers free downloads (after you have registered) of their J2EE application server with a working example, Avitek Medical Record application server that can be used for your familiarization.
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/MediatorCommander 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.The Profiler/Probe is installed on the application server (e.g. BEA WebLogic) and instrumented in order to collect statistics. The instrumentation is in the form of adding an additional parameter for the startup script for the application server. The instrumentation also deviates with each type of application server specifically to the JVM type (e.g. HotSpot JVM, JRockit JVM). By default, you can view the data locally on port 35000 or via the Java Profiler application.
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.
Having mentioned the above, Diagnostics do have it’s caveats which it is important for you to take note: (1) Diagnostics can only report modules/calls that are made on the Application Server. Therefore, Store Procedure Calls on the Database Servers will not be reported during the profiling. (2) The probe is considered an intrusive agent as it is required to be installed on the application server (which maybe scrutinized with security or server team causing inconvenience). (3) Lastly, the probe creates a monitoring overhead in the application server as it examines the byte codes in the JVM. For this, the recommendation is not to perform a large load test in conjunction with the Diagnostics but rather, run a mini load test of about 10% of the actual load. Another good tip before kicking off with Diagnostics, log a service request with HP to verify the compatibility for the probe with the Application Server . They should be able to tell you what they had tested (QAed) before and this will greatly save you alot of unnecessary time when the setup of Diagnostics really take place. Having said that, the instrumentation and compatibility is quite dependent on the type of JVM that the Application Server is running on. Therefore, know the version and type of JVM well before proceeding.
Troubleshooting; when the probes are not reporting the data back to the Controller (in a LoadRunner setup), it can be tied to various reasons. However, the main ones maybe caused by (1) unsuccessful or no instrumentation (remember, you need to instrument the application server after the installation), (2) ports between the Controller, Diagnostics and Probe are not opened, or (3) application server or Diagnostics server are not running When working with LoadRunner/Performance Center, always ensure that the Diagnostics setup is fully functional before adding the Diagnostics Module into the LoadRunner monitoring. This is an effective method in troubleshooting Diagnostics/LoadRunner integration problems in a load test setup.
Licensing; Diagnostics is bounded by (1) the number of probes that can be installed and (2) the number of Diagnostics Server that is been implemented. This license is solely used for Diagnostics only which should not be associated with the one in LoadRunner. In order for Diagnostics to work with LoadRunner/PC, an additional license used by LoadRunner called, Diagnostics Module License is required. This will allow the monitoring data from the Diagnostic server to be incorporated into the load test result.
To start familiarizing the Diagnostics Software (Probe and Commander), it will be advisable to spend at least two days to explore the features and getting used to the setup/instrumentation. BEA WebLogic offers free downloads (after you have registered) of their J2EE application server with a working example, Avitek Medical Record application server that can be used for your familiarization.
Comments
Post a Comment