Use jmeter to complete common stress tests [go]

When it comes to testing, the first thing that comes to mind is the testing of software correctness, that is, functional testing. However, it is not enough to make the software functional correctly. In actual development, other non-functional factors also play a decisive role, such as the software response speed. There are many factors that affect the software response speed, some because the algorithm is not efficient enough, and some may be affected by the number of concurrent users. In various types of software tests, stress testing is aimed at testing the software response speed, especially when a large number of concurrent users access the software in a short period of time. This document uses jmeter as an example to describe how to use it to perform common stress testing: Web Testing, database testing, and JMS testing. Summary jmeter was first created to test the execution efficiency of jserv, the predecessor of Tomcat. So far, its latest version is 2.1.1, and its testing capability is no longer limited to testing Web servers, it covers the testing capabilities of databases, JMS, Web Service, LDAP, and other objects.

In the latest 2.1.1, it also provides JUnit testing. Jmeter installation is very simple. download it from the official website and unzip it to use it. Run the command in % jmeter_home %/bin. For Windows users, the command is jmeter. bat. Check the jmeter documentation to check whether the relevant running conditions are met. For the latest version (2.1.1), JDK 1.4 is required.

The main test components of jmeter are summarized as follows:

1. the test plan is the starting point for testing using jmeter, which is a container for other jmeter testing components.

2. A thread group represents a certain number of concurrent users. It can be used to simulate concurrent users to send requests. The actual request content is defined in sampler, Which is contained by the thread group.

3. The Listener is responsible for collecting test results, and is also notified of how the results are displayed.

4. The logic controller can customize the behavior logic for jmeter to send requests. It can be used with sampler to simulate complex request sequences.

5. assertions can be used to determine whether the request response result is as expected by the user. It can be used to isolate problem domains, that is, to perform a stress test while ensuring the functionality is correct. This restriction is very useful for effective testing.

6. The Configuration component maintains the configuration information required by sampler and modifies the request content as needed.

7. The Preprocessor and the postprocessor are responsible for completing the work before and after the request is generated. The front-end processor is often used to modify the request settings, while the back-end processor is often used to process the response data.

8. The timer defines the latency interval between requests. Jmeter is very easy to use. The using jmeter article on onjava.com provides an excellent entry point. Back to Top: stress testing is different from functional testing. The correctness of software is not the focus of stress testing. It focuses on the execution efficiency of software, especially the response speed of software when the number of Access Users rapidly increases in a short period of time. stress testing is usually carried out after functional testing. In the actual development process, the potential efficiency bottleneck of the software is generally those nodes that may be accessed by multiple users at the same time. For software developed on the Java EE platform, such nodes are usually Web servers, database servers, and JMS servers. They are the main locations where requests occur. The request frequency is higher than that of other nodes, and they are on the critical path of the request sequence. If they cannot be improved, they will have a fatal impact on the efficiency of the entire software. In addition, large-scale data exchange occurs on these nodes, and sometimes business logic processing is included. They must be considered before stress testing. This article uses these three nodes as an example to describe how to use jmeter to perform stress tests on them. For most projects, the web server does not develop a web server on its own. Therefore, the target of the Web server stress test is the software released to the web server.

The simplest web test plan only requires three jmeter test elements, such as: * define the number of threads in the thread group, the time when the thread is generated, and the number of test cycles. * Define servers, ports, protocols and methods, and request paths in HTTP requests. * Table listeners collect and display results.

This setting is not enough for Web applications that contain security mechanisms. Typical Web applications generally use the following settings:

1. There is a logon page, which is the portal of the entire application. After a user logs on, the application puts the user-related security information into the session.

2. There is a filter that intercepts the request and checks whether the session related to each request contains user security information. If no, the request is redirected to the logon page and the user is required to provide security information. If the above test plan is applied in this configuration, all requests except the logon page will be directed to the logon page because of the lack of user security information. If no assertions are added, all requests are successful in the listener. In fact, these requests do not eventually reach the place where they should go. Obviously, this test result is not what we expect.

For a successful test, there are at least two methods: * Method 1: remove the program's security settings, such as filter, so that restricted content can be accessed without user security information; * method 2, use the "http url rewriting modifier" or "HTTP cookie manager" provided by jmeter without modifying the program ".

The first method has its limitations: * You need to modify the program configuration, such as removing the security filter settings in Web. xml. You need to maintain multiple versions of web. XML, such as stress testing and functional testing respectively. XML, which increases the maintenance cost, and may forget. XML modified back. * You can't do anything about pages that require user security information. For example, some business audit operations require user security information to be recorded. The lack of such information doomed the failure of the test. If the program is further modified to solve this problem, the maintenance difficulty will be greatly increased because there are multiple versions of the program.

Although the second method is more difficult to configure, it does not need to modify the program. You can also save the test plan as a file for reuse. Therefore, the second method is ideal.

The following is a simplified example to describe how to use method 2.

1. The example consists of the following files: * authorizenfilter. Java, which checks whether user information exists in the session. If not, go to login. jsp.

The main method of dofilter is as follows:

Public void dofilter (servletrequest request, servletresponse response, filterchain chain) throws ioexception, servletexception

{

Httpservletrequest Req = (httpservletrequest) request;

Httpservletresponse res = (httpservletresponse) response;

Httpsession session = Req. getsession (); User user = (User) Session. getattribute ("user ");

If (null = user)

{

String uri = Req. getrequesturi (); // if the request page is a logon page, do not redirect

If (URI. Uri signorecase ("/gweb/login. jsp "))

{

Chain. dofilter (request, response );

}

Else {

Res. sendredirect ("/gweb/login. jsp ");

}

}

Else

{

Chain. dofilter (request, response );

}

}

* User. Java: the user class is responsible for recording user information. To simplify the process, only the user name and password can be specified for logon. The main content is as follows:

Public class user

{

Private string user;

Private string PWD;

Public user (string user, string PWD)

{

This. User = user; this. Pwd = PWD;

}

Public Boolean login ()

{

Return user. Equals ("foxgem") & PWD. Equals ("12345678 ");

}

Public String getuser ()

{

Return user;

}

Public void setuser (string user)

{

This. User = user;

}

}

* Login. jsp and welcome. jsp. Login. jsp generates the user object and calls the user's login. When login returns true, It redirects to welcome. jsp.

The verification code is as follows:

<% IF (request. getparameter ("Submit ")! = NULL)

{User ur = new user (request. getparameter ("user"), request. getparameter ("PWD "));

If (Ur. login ())

{

Session. setattribute ("user", ur );

Response. sendredirect ("/gweb/welcome. jsp ");

}

Else

{

Session. setattribute ("login_error_msg", "invalid user. Possible cause: the user does not exist or is disabled. ");

Response. sendredirect ("/gweb/index. jsp ");

Return;

}}%>

* Web. xml: configure the filter to intercept all requests to access the JSP page: authorizen org. foxgem. jmeter. authorizenfilter authorizen *. jsp

2. Create a web test plan with the following structure: the main test components are described as follows: * The default value of an HTTP request is used to record the default value of the request, such as the server, protocol, and port.

* The first HTTP request is login. JSP, and add the parameters required for verification (user = foxgem, Pwd = 12345678, submit = submit); the response assertions contained in the validation URL include "welcome. JSP ", which can be reflected in the program.

* The second HTTP request is welcome. jsp. The response text contained in the response assertions contains "foxgem", which is part of the page logic of welcome. jsp.

* The HTTP cookie Manager manages the cookies used throughout the test. It does not need to set any attributes.

* The loop controller sets the number of cycles for sending the second request. The table listener collects and displays the test results of the second request.

After the test plan is started, the execution sequence is as follows: first, log on to the first request logon page; after successful logon, use the loop controller to execute the second request. When requesting welcome. jsp, the response assertions are used to verify whether it is indeed welocme. jsp to process the request, rather than because of other pages. Note the HTTP cookie manager in this test plan. Because of its function, the second request can be smoothly sent to welcome. jsp for processing, rather than being forwarded to login. jsp due to lack of user security information.

In this example, we have not used cookies in the Program (session is used). How does the HTTP cookie manager work? This is because the servlet/jsp specification provides two methods for session state tracking: * use cookies to retain and pass sessionid. It does not require the program to perform any special processing on the URL, but requires the browser to allow cookies. This is the case in this example.

* Use URL rewriting to explicitly transfer the sessionid between the browser and the server. It requires the program to encode the URL and has no requirements on the browser. In the second case, you can use the http url rewriting modifier in the jmeter premanager. For tomcat, the session parameter is JSESSIONID, and ";" is used for Path Extension ";". When using URL encoding, you must disable the cookie function of the browser. Because the URL encoding function, such as encodeurl, will determine whether to encode the sessionid to the URL. When the Browser allows cookies, no encoding is performed. If the cookie is used instead of the session to save the user's security information, simply use the HTTP cookie manager. In this case, you need to directly write the cookie parameters and values used to the Manager for management. This is also true for other cookies. After the login problem is solved, there is no difficulty in testing the web server. The rest is to use relevant test components to build a test plan based on actual needs. (Of course, there are other scenarios for security issues. When using jmeter, make it clear whether jmeter is supported. If any test component is supported .) Database Server database server is indispensable in most enterprise projects. It is tested to find out whether database objects can effectively withstand access from multiple users. These objects are mainly indexes, triggers, stored procedures, and locks. By testing SQL statements and stored procedures, jmeter can indirectly reflect whether database objects need optimization. Jmeter sends a request using JDBC to test the database.

You can create the following structure for a database test plan: * JDBC connection configuration, which is used to configure database connection information. For example, Database URL, database Driver Class Name, user name, and password. In these configurations, "variable name bound to the pool" (variable name bound to pool) is a very important attribute that will be referenced in the JDBC request. The JDBC request is associated with the JDBC connection configuration. (Put the required database driver in the classpath of jmeter before testing ).

* A jdbc request is used to send a request for testing. * Graphical results: Collect and display test results. In actual projects, there are at least two types of JDBC requests to be concerned: Select statements and stored procedures. The former reflects whether the SELECT statement is efficient and whether the table index needs optimization; the latter reflects whether the Stored Procedure algorithm is efficient. If they are inefficient, they will inevitably lead to unsatisfactory responses. For these two types of requests, the JDBC request configuration is slightly different: * select statement * If the stored procedure is Oracle and the function is tested, you can also use the SELECT statement for configuration, in this case, you can use the select function (input parameter) from dual statement to test the table. The dual is the Oracle keyword, indicating the table is flushed. For database products of other vendors, find the manual. As a platform for message data exchange, the JMS server Mom is also a potential link that affects application execution efficiency. In Java programs, it interacts with mom through JMS. As a stress testing tool implemented by Java, jmeter can also use JMS to test application message exchange and related data processing capabilities. This should not be difficult to understand, because throughout the test, the focus of jmeter testing should be on the capabilities of message consumers and consumers, rather than Mom itself. According to the JMS specification, there are two methods for message exchange: publish/subscribe and point-to-point. Jmeter provides different sampler support for these two scenarios. Here we use activemq3.2.1 to describe how the two message exchange methods use jmeter for testing.

1. Preparations before testing (applicable in both cases) Although jmeter can use JMS to test Mom, it does not provide the packages required by JMS itself. Therefore, you need to copy these packages to % jmeter_home %/lib before testing. For activemq, % activemq_home %/lib is copied. % Activemq_home %/optional is an optional package. You can check whether to copy the package based on the actual situation. Jmeter uses JNDI during testing. to provide information about the JNDI provider, it needs to provide JNDI. properties. At the same time, you need to put the JNDI. properties in the classpath of jmeter. We recommend that you package it with apachejmeter. jar in the bin. For activemq, JNDI. the example of properties is as follows: Java. naming. factory. initial = org. activemq. JNDI. activemqinitialcontextfactory Java. naming. provider. url = TCP: // localhost: 61616 # specify the JNDI name of connectionfactory. Multiple names can be separated by commas. # For a topic, use (topicconnectionfactory) context. lookup ("connectionfactry") # For queue, (queueconnectionfactory) context. lookup ("connectionfactory") connectionfactorynames = connectionfactory # register the queue. Format: # queue. [jndiname] = [physicalname] # used: (Queue) context. lookup ("jndiname"), here is myqueue queue. myqueue = example. myqueue # register a topic. Format: # topic. [jndiname] = [physicalname] # topic) context. lookup ("jndiname"). Here is the mytopic topic. mytopic = example. mytopic

2. When publishing/subscribing is being tested, publishers and subscribers do not need to appear simultaneously. For example, sometimes we may want to test the message generation of the message publisher per unit time. In this case, the message publisher is not required, but the subscriber is required. In this example, to illustrate the use of the two sampler types, create the following test plan: the attributes of JMS publisher and JMS subscriber: Select "use JNDI. properties ", the connection factory is connectionfactory, the topic is mytopic, and other default configurations are used. For JMS publisher, text messages for testing are also required. Start activemq and run the test plan. If the configuration is correct, the relevant information will be printed in the jmeter background after the connection with activemq is successful. During the test, the jmeter background may display the java. Lang. interruptedexception information, which is normal and does not affect the test process and results. This can be seen from jmeter. Log in Bin.

3. for point-to-point, jmeter only provides sampler: JMS point-to-point. In the example, create a test plan, for example, where: communication style is request only. For another style: Request Response, the jmscorrelationid In the JMS header that receives the message is verified to determine whether it is a response to the request message. Back to the top CONCLUSIONS This article describes how to use jmeter to perform stress testing for the three most common types of servers. These three types of stress testing cover a large part of the use cases, however, you must remember that a tool is a tool after all. If the effect is good, the key lies in the use of people. Furthermore, for stress testing, the quality of the test plan is critical. For different situations, tests are conducted after analysis, which is much more efficient than brute-force attacks.