LoadRunner TnT » J2EE Diagnostics http://www.loadrunnertnt.com Performance Testing, LoadRunner Tips & Tricks Mon, 08 Mar 2010 07:57:02 +0000 http://wordpress.org/?v=2.9.2 en hourly 1 Implementing Mercury J2EE Diagnostics with LoadRunner! http://www.loadrunnertnt.com/how-tos/implementing-mercury-j2ee-diagnostics-with-loadrunner/ http://www.loadrunnertnt.com/how-tos/implementing-mercury-j2ee-diagnostics-with-loadrunner/#comments Mon, 21 Apr 2008 16:46:59 +0000 TnT Admin http://www.loadrunnertnt.com/?p=42 You should have the following with you prior the entire setup. If you are still unsure of the different components in a Mercury J2EE Diagnostics setup, I recommend you to revisit the article, “What’s Diagnostics?”, to gain a better understanding better before proceeding:

    1. Mercury Diagnostics Server Installation Disc
    2. Mercury Diagnostics J2EE Probe Installation Disc
    3. Mercury LoadRunner Installation Disc (prior to LR 9.0, the AddIn is found on the Additional Feature Disk).
    4. J2EE Diagnostics Module license for LoadRunner
    5. Mercury Diagnostics license for Diagnostics Server
    6. Mercury Diagnostics Server and Probe Installation and Configuration Documentation

What you need to know in advance:

    1. The JRE information of the Application Server.
    2. The location of the application startup script (not the WebLogic server startup script).

We will use the term Profiler and Probe interchangeably for the purpose of this article. In the setup, I’m using the following:

    1. Mercury Diagnostics Server 6.5
    2. Mercury Diagnostics Probe 6.5
    3. Mercury LoadRunner 8.1 FP4
    4. BEA Weblogic 8.1 SP5
    5. BEA sample Application Server – Avitek TM Medical Records
    6. Sun JRE 1.4.2_08
    7. TCP 2006 opened for two-way communication from LoadRunner Controller machine to Diagnostics Server machine
    8. TCP 2612 opened for two-way communication from Diagnostics Server machine to Application Server machine
    9. TCP 35000 opened locally on Application Server machine.

Also, note that the explanation will be based on Windows environment although concepts are generally similar. Therefore, if you are installing in a Unix environment, please refer to the Mercury Diagnostics Installation and Configuration Guide. The implementation will also be based on the following illustration.

Mercury J2EE Diagnostics Implementation

Enough said, let’s walk through the steps for installation and configuration together.

An overview of the implementation is as followed:

    1. Install the Diagnostics Server
    2. Install the Diagnostics AddIn on the LoadRunner Controller
    3. Install the Diagnostics J2EE Probe on the Application Server
    4. Run the Diagnostics J2EE Instrumenter and instrument the application startup script.
    5. Ensure that statistics are collected and displayed on the Diagnostics J2EE Probe/Profiler
    6. Ensure that statistics are collected and displayed on the Diagnostics Server
    7. Ensure that statistics are collected and displayed on the LoadRunner Controller.

Installation

1. Verify the compatibility of the Diagnostics Server, Probe and LoadRunner with the support crew first. Sometimes, the server may not be fully integrated with LoadRunner and may end you up in circles without the proper support.

2. Install Diagnostics Server on a machine in the network with the Mercury Diagnostics Server Installation Disk.

a. The installation process is pretty straight-forward so just follow through it. Once you’ve reached the selection of the Diagnostics Server Mode, select “Commander Mode” as there is only one Diagnostics Server available in the setup. The following setup are optional and dependent on your existing architectural setup.

b. Once the installation has completed, on the Diagnostic Server machine, select All Programs > Mercury Diagnostics Server > Administration to launch Diagnostics Server in the browser. If it is not started, select All Programs > Mercury Diagnostics Server > Start Mercury Diagnostics Server. By default, Diagnostics Server service should be started after the installation as well as every startup of the OS.

Tip:
For any reason, that username and password is required, the default is username: admin and password: admin.

c. Place the Mercury Diagnostics license information here. (In anyway, you won’t be able to view any data in the Diagnostics Server if the license information is not entered and also it will consistently prompt you for the license.)

d. Verify the Diagnostics Server is working such as the functionality by launching the browser and pointing to the following URL:

    http://localhost:2006

    or

    http://{diagnostics-server}:2006 where {diagnostics-server} is the hostname of the Diagnostics Server.

Note:
If you have a complex setup of mutliple J2EE Application Servers that you would like to monitor, you may need to spread the load of the Diagnostics Commander Server to many Diagnostics Mediator Server. The Mediator Servers are to ease the processing of the information before being consolidated at the Diagnostics Commander. For more information, refer to the article, “What’s Diagnostics?”.

3. Install the Diagnostics AddIn on the LoadRunner Controller machine using the Mercury LoadRunner Installation Disc. If you are working on LR8.1FP4 and earlier, the AddIn is found in the Additional Feature disc. After the installation, place the J2EE Diagnostics Module license information in LoadRunner and connect to the Diagnostics Server at port 2006. This is done by configuring in the LaunchPad (Select All Programs > Mercury LoadRunner > LoadRunner > Configuration > Diagnostics for J2EE/.NET setup)

4. Install the Mercury Diagnostic J2EE Probe on the Application Server. The installation process is pretty straight-forward so just follow through it. Once you’ve reached the selection for installing it as a standalone Profiler to work with a Diagnostics Server, select to “Install the probe to work with a Mercury Diagnostics Server” since we’ve got the Diagnostics Server ready.

a. Provide a Probe Name for the the probe, e.g. Avitek_J2EE_Probe. You can also provide the Probe Group which we will use the “Default” Probe Group. (Refer to the Mercury Diagnostics User’s Guide for more information of the names and groups in Diagnostics and if you need to change the names and groups in future).

b. Provide the Diagnostics Server Mediator Host information which include the hostname and the port that the Diagnostics Server is utilizing. By default, it’s port 2006.

Note:
1. You can install the probe as a standalone profiler and it will still work with the proper instrumentation. However, the result that is been displayed at the profiler will be runtime and you will not be able to store it for analyzing at a later stage. This will be useful if you need to monitor the application server with minimal setup.

2. In the Instrumentation Tool, you can also add JVMs if they are not detected by the tool.

Instrumentation

5. After the installation, run the JRE Instrumenter from All Programs > Mercury Diagnostics J2EE Probe > JRE Instrumenter. Select the JRE that was previously configured in the probe installation process (Sun JRE 1.4.2_08 in C:\MercuryDiagnostics\JavaProbe\classes\Sun\1.4.2_08) and the JVM parameter is displayed in the bottom window. This JVM parameter will be added to the application startup script for instrumentation purposes. As such, click “Copy Parameter” to copy the JVM parameter.

6. Locate the application startup script. For the sample application, Avitek Medical Record, it’s located in the following directory. Open the startup script with a notepad to edit the startup process.

C:\bea\weblogic\samples\domains\medrec\startMedRecServer.cmd

Tip:
If you are unsure of the location, check with the developers or the Application Server team. Alternatively, you can also find the directory with the console that starts the application server.

7. Find the statement that starts the application server and add the JVM parameter from point [5]. Two samples of the startup script before and after are included for your reference and can be downloaded in the respective link.

    Before-Instrumentation

    “%JAVA_HOME%\bin\java” %JAVA_VM% %MEM_ARGS% %JAVA_OPTIONS%
    -Dweblogic.Name=%SERVER_NAME%
    -Dweblogic.ProductionModeEnabled=%PRODUCTION_MODE%
    -Djava.security.policy=”%WL_HOME%\server\lib\weblogic.policy”
    weblogic.Server

    After-Instrumentation

    “%JAVA_HOME%\bin\java” %JAVA_VM% %MEM_ARGS% %JAVA_OPTIONS%
    -Dweblogic.Name=%SERVER_NAME%
    -Dweblogic.ProductionModeEnabled=%PRODUCTION_MODE%
    -Djava.security.policy=”%WL_HOME%\server\lib\weblogic.policy” “-Xbootclasspath/p:C:\MercuryDiagnostics\JAVAProbe\classes\Sun\1.4.2_08;
    C:\MercuryDiagnostics\JAVAProbe\classes\boot”
    weblogic.Server

8. Save the amended application startup script and restart the entire application server. (Not necessarily the Weblogic Server needs to be restarted.)

9. Now, from the Start menu, select All Programs > Mercury Diagnostics J2EE Probe > Diagnostics Profiler for J2EE. This will launch the J2EE Profiler in its applet format. Click on the link, “Connect to Mercury Diagnostics Profiler” and wait awhile for the profiler loads. When the Profiler is fully loaded, you should be able to see statistics being collected (below) and displayed in the profiler if the steps taken from [5] to [7] were completed successfully.

Diagnostics Profiler for J2EE

You can also launch a browser with the following URL to view the statistics as illustrated in the below diagram.

    http://localhost:35000

    or

    http://{application-server}:35000 where {application-server} is the hostname of the Application Server

Diagnostics Profiler for J2EE via Browser

Tip:
For any reason, that username and password is required, the default is username: admin and password: admin.

Connecting to the Diagnostics Server

10. Go to the Diagnostics Server. Launch a browser and enter the following URL:

    http://localhost:2006

    or

    http://{diagnostics-server}:2006 where {diagnostics-server} is the hostname of the Diagnostics Server.

With a valid license, you should be able to see statistics from the browser.

Connecting to the LoadRunner Controller

11. Go to the LoadRunner Controller machine. Click on the Diagnostics for J2EE/.NET Tab, you should be able to see the JVM statstics being collected and displayed. It’s a similar interface as the Diagnostics Server which means all data are successfully collected and transmitted from the Probe to the Diagnostics Server and finally to the LoadRunner Controller. Hopefully you can understand that it is necessary to have the probe working, followed by the Diagnostics Server working before LoadRunner Controller can displayed and log the data.

For the usage and advanced configuration of the Diagnostics Server and Probe, I highly recommend you to go through the Mercury Diagnostics User’s Guide and Mercury Diagnostics Installation and Configuration Guide.

With that, I hoped I provide sufficient information for you to fully

]]> http://www.loadrunnertnt.com/how-tos/implementing-mercury-j2ee-diagnostics-with-loadrunner/feed/ 13 What’s Diagnostics? http://www.loadrunnertnt.com/products/hello-world/ http://www.loadrunnertnt.com/products/hello-world/#comments Mon, 21 Apr 2008 15:07:33 +0000 TnT Admin http://www.loadrunnertnt.com/?p=1 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.

The following illustrates a typical Diagnostics setup with the LoadRunner Controller and as you can see, the sequence of the Diagnostics is straight-forward.

J2EE Diagnostics

Mercury HP Diagnostics LoadRunner
    1. The application servers are installed with J2EE probes.
    2. Then after they are instrumented.
    3. The statistics are then collected and sent to the Diagnostic Server which does the processing of the data.
    4. This data is then sent to Controller to consolidate into the load test results. i. The runtime data of the application server can be view locally at the browser on via http://localhost:35000 or via the Java Profiler.
    ii. On the Diagnostic Server, use http://localhost:2600 to view the running probes, configuration as well as the statistics collected from the instrumented probes connected to the server.

If the proper port is opened (35000 and 2006), you will be able to view the statistics from other machines. As such, this comes to my the end of the Diagnostics overview. Hope you have a better understanding of how Diagnostics works and the limitations with it. I will be walking through the implementation in future posts.

]]> http://www.loadrunnertnt.com/products/hello-world/feed/ 2