If you are budget tension and time is tight - or even if you are not the case - then, you may want to consider using JMeter to press the web and other applications. IBM's Greg Herringer detail he uses this pure Java application to test the experience of WebSphere middleware solutions.
This document describes how to deploy Apache Open Source Tools JMeter to test the responsiveness of the middleware solution based on IBM WebSphere Application Server and WebSphere Branch Transformation Toolkit (BTT). By designing performance testing, changes in concurrent user load can be simulated, and these user loads use a variety of interactive financial exchange (IFX) request messages. If your project's performance test budget is limited, and your solution uses an XML message, the experience in this article is ended in this article can help you plan your performance test strategy.
Gets the products and tools used in this article. If you are a developerWorks subscriber, you will have a single user license, you can use WebSphere Application Server and other DB2®, Lotus®, Rational®, Tivoli®, and WebSphere® products. - These include Eclipse-based WebSphere Studio IDE to develop, test, evaluate, and demonstrate your app. If you are not an subscriber, you can subscribe now.
Performance testing for high visibility projects Challenges a recent project of a financial institution requires delivery of an intermediate infrastructure for supporting growth applications, which require access to the core financial system. The direction of the architecture is to require all core financial system requests through the intermediate solution, which uses XML-based IFX message standards. Figure 1 shows the middleware infrastructure (bold display) related to the first application, as well as future applications and backend systems (displayed in gray).
Figure 1. Solution to be tested
To make the high visibility items to be recognized, the best performance under various loads must be demonstrated. This is especially important for response time sensitive customers, such as CRM applications in the contact center. Another problem that needs to be considered is that when a new application appears in the "front" and "behind" (later "(shown in Figure 1 showing the future implementation of the consumer credit card service system) ), You need to reuse the selected performance test methods.
User Interface Specifies the first application using the middleware infrastructure is a deposit processing application, which is scheduled to be implemented after the middleware project is completed. This means that the test team has to simulate the production load in the case where no user interface can prepare and submit the middleware request.
Limited budget financial institutions do not have the right toolset to support intermediate performance testing. Therefore, the challenge here is to be sure to report the performance characteristics of the observed middleware, while the budget for tools and preparation remains minimally.
Using JMeter to save a variety of available open source test tools, discovery Apache Jmeter can support middleware performance test requirements. JMeter provides a GUI-based application for designing and executing a variety of reusable test programs. JMeter also supports capture test results in XML format for testing statistical analysis. These two features help test team development and documentation repeatable test results to meet the challenges of "high visibility".
Many open source test tools are designed for testing Web sites, and expect to test how to simulate user interactions with one or more pages or forms. Because the application's web interface is not available while the application is not available, the selected tool must support XML-based messages without browser interaction. JMeter's SOAP / XML request component satisfies this request. Finally, since JMeter is the product of the Apache Software Foundation, this fact means that the project does not require license costs for commercial testing tools to meet the "limited budget".
The target of the design test script performance test is to submit a randomly selected, predefined, IFX encoded request message under various concurrent load conditions, and record the ELAPSED TIME of the response to the IFX encoding. The following five JMETER test plan components are used to prepare performance test scripts.
Test plan This is the main component for testing. Here, the test name is specified based on the naming agreement of the project. At the same time, select Functional Test Mode to capture a complete IFX encoding response in the test results managed by View Results Tree.
Figure 2. JMeter test plan
HTTP HEADER Manager This component is used to specify the value of the HTTP header required for the middleware. Each IFX encoded request sent to the middleware will include the value of these HTTP headers.
Figure 3. JMeter http header manager
Thread Group This component is repeated according to the requirements of the test plan to simulate a specific number of concurrent users. For example, 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 that is Number Of Threads for controlling the number of threads associated with a thread group. Since each Thread Group has a unique randomly selected IFX encoding request set (see SOAP / XML-RPC Request), decide to limit each Thread Group as a thread. If multiple threads are specified for one or more Thread Group, then the same message collection will be sent multiple times, which will violate the target of random selection criteria.
SOAP / XML-RPC Request repeats the component for each of the desired number of IFX encoding requests sent by each Thread Group. The actual IFX encoded request is specified in this component.
Figure 5. JMeter SOAP / XML-RPC Request
View Results Tree This component serves two purposes. When the test is executed, the user interface displays the test process that the message is sent and received. Moreover, the component writes the test result to a file for testing.
Figure 6. Jmeter View Results Tree
The JMeter test plan is designed to simulate a variety of 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, thereby simplifying performance testing.
Building a test script Once you have determined the required JMeter components and have conceived a universal 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 can be reused. The corresponding challenge is to prepare the test script to send up to 8,000 request messages that are randomly selected (for 100 threads, each thread). These messages are randomly selected, thereby better approaching the stable state of the production conditions, and there is no request type under production conditions may be more submitted more than other types. Use the JMeter user interface separately, which means manual cut and paste messages into 8,000 SOAP / XML-RPC Request. In order to make the task further complicate, each request also requires the only RQUID according to the IFX specification of the financial institution. Automatically create test scripts As already mentioned, the performance test method of the project will be reused for future middleware versions. Therefore, the test team puts some energy to prepare a Java application to output JMeter XML encoded test scripts based on the specified parameter. The Java application is called Scripter, which can prepare a performance test script that has a specified number of threads and each thread has a message specified for IFX encoding, random selection by the application. The IFX encoded message is derived from a message set, which is provided in the directory specified by the Scripter's properties file.
From the link in the section of this article, you can download the source code and usage of the Scripter Java application.
Perform test JMeter installed on a dual-channel IBM EServerTM xSeries® 360 server, which has 2 GB RAM and runs 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 metrics included in the middleware response can be analyzed. JMETER TIME observed by JMeter can also be analyzed, although the number also includes network delay between the middleware and JMeter.
The test team performs three performance test cycles and improves the performance of the application by modifying and configuring adjustments after the first two cycles.
The analysis results test team uses the Microsoft® Excel electronic data table to import test results, and perform statistical operations for the consumption time metrics described above. The result is then graphically, thereby displacing the second second-second secondary secondary secondary secondary secondary secondary secondary secondary seconds provided by most test conditions.
The experience gained, JMeter as the performance test tool for the project is an excellent choice. The experience below provides additional details.
JMeter meets our need JMeter easy to install and has medium understanding complexity (see the next experience). The selected JMETER component provides a common structure for all performance test scripts. The XML coding output of the test results is a convenient feature for testing after testing because the option captures performance statistics in the response message included in the IFX encoding.
JMeter users should have technical capabilities to properly prepare performance test scripts, and script developers must understand distributed applications using HTTP and XML protocols. Business users may find difficult to use various JMETER components.
Creating a large script may require additional automation to process our performance test feature (random message pick, concurrency, and unique values included in each IFX encoded request) require an automated method to generate test scripts. Fortunately, the test team has sufficient Java technical capabilities to automate this task. This app is provided for those with similar needs. If time (and capabilities!) Allowable, the team can also develop a new JMeter component that meets the item and submits the component to the Apache organization.
Customized performance metrics can help determine the problem JMeter application to measure the time consumption between the request and the received IFX encoded response. However, this metric does not provide internal information about the potential bottlenecks present in the distributed middleware solution. The middleware development team provides additional performance metrics that will be used for host communication, and the time consumption time of message analysis is separated from the intermediate pieces used for transaction processing. These metrics are included in the IFX encoded response as an XML annotation.
