Analysis Tools

---

In this section we will provide a brief overview of the tools available for stress testing the performance and scalability of web applications, as well as analyzing and profiling performance and scalability related issues of J2EE web applications. We will cover both leading commercial and freeware tools.

Stress Testing Tools

The tools we will cover in this section that can be used for stress testing performance and scalability. We will look at:

• Microsoft Web Application Stress is a commercial tool available from http://webtool.rte.microsoft.com/

• Apache JMeter is a freeware available from http://www.apache.org/jmeter

Most of these tools provide a browser-like user interface for accessing your web applications and recording the various HTTP GET and POST requests. After the user actions are recorded, you can use the tool for stress testing the application. The tool will send the recorded GET and POST requests with a simulated load by spawning multiple threads from the client.

Microsoft Web Application Stress

Microsoft Web Application Stress simulates multiple browsers requesting pages from a web application. The tool is easy to use and provides a variety of features for testing the performance and scalability of web applications.

The main features of the tool include:

• We can test scripts which may be run using any number of client machines, controlled by one centralized client

• The tool takes care of synchronizing the clients on allocating simulated client threads, gathering and recording test data

• It supports the creation of multiple users for stress testing authenticated and personalized web sites

• Supports HTTP sessions and cookies

• Provides bandwidth throttling, to simulate modem throughput and increasing numbers of concurrent users

• Provides a tool to import, store, and edit complex request parameter name-value pair collections

• Supports DNS names, so you can use the IP address of a specific server or use the DNS name to have the tool round-robin among the servers in your cluster

• Can define groups of request pages to organize the request sequence and hit percentage

• Supports changeable delay between requests to test race conditions

• Provides a user-friendly graphical user interface

• Supports customizable request headers and form encoded data

Apache JMeter

Apache JMeter is a generic test tool developed as desktop Java application designed to load test functional behavior and measure performance. It can be used to test the performance of both on static and dynamic content. It can simulate a heavy load on the web container for testing scalability under varying load. Please note that JMeter is not only designed for web applications but can be used for other kinds of applications as well.

The main features of JMeter include:

• Can load and performance test HTTP and FTP servers, and arbitrary databases

• It is completely written in Java and hence is highly portable

• Provides an excellent user interface

• Supports concurrent sampling by many threads and simultaneous sampling of different functions by separate thread groups

• Provides faster operation and precise timings

• Supports caching and offline analysis/replaying of test results

JMeter is also highly extensible, it supports:

• Pluggable Samplers allow unlimited testing capabilities

• Several load statistics may be chosen with pluggable timers

• Data analysis and visualization plug-ins allow great extensibility as well as personalization

Using JMeter

JMeter may be started by running the jmeter.bat file present in the /bin directory of the JMeter installation.

The user interface is divided into two sections. The left-panel contains a tree that represents the test configuration. A test may consist of one or more subtests. The display on the right-panel is controlled by the element that is selected on the tree in the left-panel.

The test configuration tree initially contains the TestPlan and WorkBench elements. The TestPlan element contains the elements that make up a test. The WorkBench may be used to store test elements while you are running a test.

A TestPlan may contain one or more ThreadGroups. ThreadGroups may be added to the TestPlan by right clicking on the TestPlan in the tree.

The following elements may be added to a ThreadGroup:

• A Timer element defines the time interval between requests sent by JMeter. You can have constant timers, ramped timers, and so on. A Timer can be added to a ThreadGroup using the right mouse button.

• A Listener receives information about the response when the test is run. JMeter provides different types of listeners that plot the data graphically, provide an XML representation of the response data, and so on. You can click on a Listener when a test is run, to access real-time information about the test. A Listener can be added to a ThreadGroup using the right mouse button.

• Controllers are used for performing various kinds of tests. JMeter provides both logic controllers and generative Controllers. Generative Controllers may be used for testing web applications. A Controller can be added to a ThreadGroup using the right mouse button.

• Config elements are used for defining configuration information for the different test protocols like JDBC connection pools, SQL queries, web applications, and so on. A Config element can be added to a ThreadGroup using the right mouse button too.

A ThreadGroup also defines the number of threads available for testing.

Now we will have a quick look at using JMeter for running web applications. First start JMeter by running the batch file. This will display the window shown below,

Right click on the TestPlan element to Add a new ThreadGroup, and then define the number of client threads as five:

Add a new Generative Controller for Web (application) Testing by right clicking on the ThreadGroup.

Then define the host address, port number and URL path of the web application you are testing as shown above. I have added the index page on Tomcat root running locally on my machine at port 8080. You may also define the HTTP method, request parameters and so on.

Right click on ThreadGroup and Add a Listener, a Spline Visualizer, to provide real time feed back of the test. Then start the test from the main Run menu and select the Spline Visualizer element in the tree. You should see something like this:

Here, the curve represents the history of the test; in other words it shows graphically how the response changed over time. Relevant statistics such as maximum and minimum response times are displayed too.

Profiling Tools

In this section we will briefly discuss the commercial tools available for profiling and analyzing performance-related issues with J2EE web applications.

Profiling provides detailed information about your application, such as the most frequently accessed methods, the most instantiated objects, stack traces, and so on. This will help you significantly when you need to identify the performance hotspots within your applications.

The tools we are going to cover include the suite of products that comprise:

• JProbe available at http://www.jprobe.com

• Optimizeit available at http://www.vmgear.com

We will also provide a brief overview of the hprof option that can be used with the JVM.

The general features of a profiling tool are...

• Report generation - depicting object instantiation, method access, stack dumps, and so on

• Thread monitoring

• Monitoring VM heap utilization

• Monitoring CPU cycle utilization

JProbe ServerSide Suite

The JProbe ServerSide Suite from Sitraka Software (formerly KL Group) provides performance profiling, memory debugging, code coverage and thread analysis capabilities in an integrated suite, focusing on server-side Java. JProbe provides efficient source code profiling. The JProbe suite of products provides an intuitive user interface for everything from memory usage to calling relationships. The suite is comprised of:

• Profiler (with fully integrated JProbe Memory Debugger) - to eliminate performance bottlenecks and memory leaks in your Java code

• Threadalyzer - to detect deadlocks, stalls and race conditions

• Coverage - to locate and quantify untested Java code

JProbe ServerSide Suite provides servlet and server-side application-tuning capabilities, as well as comprehensive and convenient integration with popular web applications.

Optimizeit

Optimizeit ServerSide Suite from VM Gear provides a similar set of tools to those provided by JProbe:

• Profiler - provides useful information on issues such as CPU utilization, memory leaks

• Thread debugger - provides comprehensive real-time information on running threads, monitor locks, and so on

• Code Coverage - provides a real time matrix describing the number of times each line of code within the application is executed

JDK hprof

If you don't want to spend a huge amount of money on commercial profiling tools, the JDK comes with an option for profiling your applications. The hprof option provided with the JVM can provide you with a wealth of information about object allocation, CPU cycle contention, stack traces, thread information, and so on. In this section we will provide a brief overview of using JDK hprof.

The hprof option can be used for profiling Java applications when the JVM is invoked as shown below:

    java -Xrunhprof[:help]|[<option>=<value>, ...] MyClass 

Here MyClass is the class to be profiled. To use hprof to analyze your servlets, you will need to modify your web container startup script to invoke the JVM with the hprof option. For example, in Tomcat you may modify the catalina.bat file to add the hprof option. The table below describes the hprof options available:

Option	Description
heap	This is used for profiling the VM heap. The possible values are dump, sites and all with the default value being all.
cpu	This is for profiling CPU usage. The possible values are samples, times and old. By default this option is not enabled. With sampling, the JVM regularly pauses execution and checks to see which method call is active. With enough samples (and a decent sampling rate), you can pinpoint where your code spends its time
monitor	This enables profiling monitor lock contention. The possible values are y and n, with the default value being n.
format	This option defines the output format. A value of a indicates ascii and b indicates binary. The default value is a.
file	This option identifies the file to which the output is written.
net	This option can be used to define an IP address and port of the output is to be sent over a remote socket.
depth	This can be used to define the stack depth and the default value is 4.
cutoff	This can be used to define the output cutoff size and the default value is 0.0001.
lineno	If this option is set to y, the stack trace will show the line number. The default value is n.
thread	If set to y shows the thread in stack traces. The default value is n.
doe	A value of y dumps the output on VM exit. The default value is y.

---