"Go" test WebSphere performance with Apache JMeter

If you have a tight budget and a tight time--or even if you don't--then you might want to consider using JMeter to stress test The WEB and other applications. IBM 's Greg herringer details his experience using this pure Java application to test the WebSphere middleware solution.
This document describes how to deploy the Apache Open Source Tool, JMeter, based on the IBM WebSphere application Server and WebSphere Branch transformation Toolkit (BTT ) to test the responsiveness of the middleware solution. By designing performance tests , you can simulate changing concurrent user loads that use multiple interactive financial Exchange (Interactive financial Exchange,ifx) Request messages. If your project's performance test budget is limited and your solution uses XML messages, the experience gained at the end of this article can help you plan your own performance testing strategy.
Performance testing challenges for high-visibility projects

A recent project for a financial institution needs to deliver a middleware infrastructure to support the growing list of applications that require access to the enterprise's core financial system. The architecture is directed at requiring all core financial system requests to be routed through the middleware solution, which uses the XML-based IFX messaging standard. Figure 1 shows the middleware infrastructure associated with the first application (shown in bold), as well as future applications and back-end systems (shown in gray).

Figure 1. Solutions to test

For this high visibility project to be recognized, the best performance under various loads must be demonstrated. This is especially important for response time-sensitive customers, such as contact center CRM applications. Another problem to consider is that when new applications appear in the "front" and "back" of the middleware (Figure 1 shows a future implementation of the enterprise and Consumer credit card service systems behind the middleware), the chosen performance test method needs to be reused.

No user interface

The first application that specifies a middleware infrastructure is the deposit processing application, which is scheduled to be implemented after the middleware project is completed. This means that the Test team had to simulate the production load without a user interface to prepare and submit the middleware request.

Limited budget

Financial institutions do not have the right toolset to support middleware performance testing. As a result, the challenge here is to reliably report on the observed performance characteristics of the middleware while keeping the budget for tools and preparation to a minimum.

Use JMeter Emergency

By studying the various open source testing tools available, we found that Apache JMeter can support middleware performance testing requirements. JMeter provides a GUI-based application for designing and executing a variety of reusable test plans. JMeter also supports capturing test results in XML format for post-Test statistical analysis. These two features help test teams develop and document repeatable test results to meet the "high visibility" challenge.

Many open-source test tools are designed to test Web sites and expect tests to simulate the interaction of a user with one or more pages or forms. Because the application's Web interface is not available when testing the middleware solution, the selected tool must support XML-based messages without browser interaction. The Soap/xml request component of JMeter satisfies this requirement.

Finally, since JMeter is a product of the Apache Software Foundation, this fact means that the project does not require the payment of license fees for commercial testing tools to meet the "limited budget" conditions.

Designing Test Scripts

The goal of the performance test is to submit a randomly selected, pre-defined, IFX-encoded request message under a variety of concurrent load conditions, and to record the elapsed time of the response received by IFX encoded (elapsed times). The following five JMeter test plan components are used to prepare a performance test script.

Test Plan

This is the primary component for testing. Here, the test name is specified according to the project's naming convention. Also, select functionaltest Mode to capture the full IFX-encoded response in the test results managed by the View Results Tree.

Figure 2. JMeter test Plan

HTTP Header Manager

This component is used to specify the value of the HTTP header required by the middleware. Each IFX-encoded request sent to the middleware will include the values of these HTTP headers.

Figure 3. JMeter HTTP Header Manager

Thread Group

The component repeats as required by the test plan to simulate a specific number of concurrent users. For example, to simulate 5 concurrent users, you need to specify 5 Thread Group.

Figure 4. JMeter Thread Group

Note that the thread group component has a domain labeled number of Threads, which controls how many threads are associated with a thread group. Since each thread group has a unique randomly selected IFX-encoded request collection (see SOAP/XML-RPC requests below), it is decided to limit each thread group to a single thread. If multiple threads are specified for one or more thread Group, the same message collection will be sent multiple times, which will violate the target of the random selection criteria.

Soap/xml-rpc Request

Repeat the component for the desired number of IFX-encoded requests sent by each Thread Group. The actual IFX-encoded request is specified in the component.

Figure 5. JMeter Soap/xml-rpc Request

View Results Tree

This component serves two purposes. When the test executes, the user interface displays the test process that the message was sent and received. Furthermore, the component writes the test results to a file for post-test analysis.

Figure 6. JMeter View Results Tree

The JMeter test plan is designed to simulate multiple concurrent user loads, from a single user to a maximum of 80 concurrent users. For all test plans, the five components described above are deployed in a consistent manner, simplifying performance test execution.

Build a test script

Once you have identified the required JMeter components and have conceived the good one generic test plan design, you must build a test script. Fortunately, the System integration test (see Resources) has more than 300 IFX-encoded model request messages and related test data that can be reused. The corresponding challenge is to prepare a test script that can send up to 8,000 randomly selected request messages (for 80 threads, 100 per thread). These messages are randomly selected to better approximate the stable state of the production conditions, and no request type can be submitted more than other types under production conditions. Using the JMeter user interface alone will mean cutting and pasting messages manually into 8,000 Soap/xml-rpc Request. To further complicate the task, each request also requires a unique rquid, according to the IFX specification of the financial institution.

Automatically create test scripts

As already mentioned, the project's performance testing approach will be reused for future versions of the middleware. Therefore, the test team put in some effort to prepare a Java application to output JMeter XML-encoded test scripts based on the specified parameters. The Java application, called Scripter, prepares a performance test script that has a specified number of threads and each thread has a specified number of IFX-encoded messages, which are randomly selected by the application. IFX-encoded messages originate from a collection of messages that are provided in the directory specified in the Scripter properties file.

From the links in the Resources section of this article, you can download the source code and usage notes for the Scripter Java application.

Perform tests

The JMeter is installed on a dual-channel IBM eserver™xseries® server that has 2 GB of RAM and runs the windows®2000. Figure 7 shows the test configuration.

Figure 7. JMeter Performance Test Configuration

When the test is executed, the IFX encoded response is recorded so that the captured MQ time and total time measurements contained in the middleware response can be analyzed. You can also analyze the JMeter time observed by JMeter, although the number also includes network latency between the middleware and the JMeter.

The Test team performs three performance test cycles and improves application performance by modifying and configuring adjustments after the first two cycles.

Analysis results

The Test team uses the MICROSOFT®EXCEL spreadsheet to import test results and performs statistical operations on the elapsed time metrics described above. The result is then graphically displayed, showing the second-second (sub-second) responsiveness that the application provides for most test conditions.

The experience gained

Overall, JMeter as a performance testing tool for the project is an excellent choice. The experience gained below provides additional details.

JMeter to meet our needs.

The JMeter is easy to install and has a moderate level of understanding complexity (see next experience). The selected JMeter component provides a common structure for all performance test scripts. The XML-encoded output of the test results is a handy feature for post-test analysis because it captures performance statistics contained in the IFX-encoded answer message.

JMeter users should have technical capabilities

In order to properly prepare the performance test script, the scripting developer must have a good understanding of the distributed application using HTTP and XML protocols. Commercial users may find it difficult to use the technical specifications of various JMeter components.

Creating a large script may require additional automated processing

Our performance testing features (random message selection, concurrency, and the unique values contained in each IFX-encoded request) require an automated method to generate test scripts. Fortunately, the Test team has enough Java technology capabilities to automate the task. For people with similar needs, the application is available at the end of this article.

If time (and ability!) If allowed, the team can also develop a new JMeter component that meets the needs of the project and submit the component to the Apache organization.

Customized performance metrics can help identify issues

The JMeter application can measure elapsed time between the transmission of IFX-encoded requests and the receipt of IFX-encoded responses. However, this metric does not provide internal information about the potential bottlenecks that exist in the distributed middleware solution. The middleware development team provides additional performance metrics that isolate the elapsed time for host communications, message analysis, and middleware consumption for transactional processing. These measures are included in the IFX-encoded answer as XML annotations.

"Go" test WebSphere performance with Apache JMeter