Shulou(Shulou.com)06/01 Report--

This article shows you how to use JMeter to complete commonly used stress tests, the content is concise and easy to understand, can definitely brighten your eyes, through the detailed introduction of this article, I hope you can learn something.

Use JMeter to complete common stress tests

The basic concepts related to JMeter are introduced here. Taking JMeter as an example, this paper introduces the methods, steps and matters needing attention of stress testing by using it to complete the three most commonly used types of servers, namely, Web server, database server and message middleware.

Overview

JMeter was first born 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 the testing of Web servers, but covers the testing capabilities of database, JMS, Web Service, LDAP and other objects. In the latest 2.1.1, it also provides testing for JUNIT.

JMeter is easy to install and can be downloaded from the official website and unzipped to use. The command is run under% JMETER_HOME%/bin, and for Windows users, the command is jmeter.bat. Before running, please check the documentation of JMeter to see if the relevant operating conditions are available. For the latest version (that is, 2.1.1), the version that requires JDK is JDK 1.4.

The main test components of JMeter are summarized as follows:

1. The test plan is the starting point for testing with JMeter, which is the container for other JMeter test components.

two。 A thread group represents a certain number of concurrent users, which can be used to simulate concurrent users sending requests. The actual request content is defined in Sampler and is contained by the thread group.

3. The listener is responsible for collecting test results and is also told how the results are displayed.

4. The logic controller can customize the behavior logic of JMeter sending requests, and it can be used with Sampler to simulate complex request sequences.

5. Assertions can be used to determine whether the result of the request response is as expected by the user. It can be used to isolate the problem domain, that is, to perform stress tests while ensuring that the function is correct. This limitation is very useful for effective testing.

6. The configuration component maintains the configuration information required by the Sampler and modifies the content of the request according to the actual need.

7. The pre-processor and the post-processor are responsible for completing the work before and after generating the request. The front processor is often used to modify the settings of the request, while the post processor is often used to process the response data.

8. The timer is responsible for defining the delay interval between requests.

JMeter is very easy to use, and the article Using JMeter on ONJava.com provides a very good introduction.

Common test

Stress testing is different from functional testing, the correctness of the software is not the focus of its testing. What it values is the execution efficiency of the software, especially the response speed of the software when the number of access users increases explosively in a short period of time. Stress testing is often carried out after functional testing. In the actual development process, the potential efficiency bottleneck of software is generally those nodes that may be accessed by multiple users at the same time.

As far as the software developed under the current Java EE platform is concerned, such nodes may usually be: Web server, database server and JMS server. They are the main places where the request occurs, the request frequency is higher than other nodes, and is on the critical path of the request sequence. If their efficiency cannot be improved, it will have a fatal impact on the efficiency of the whole software. And large-scale data exchange generally takes place on these nodes, sometimes including business logic processing, which is the first thing to be considered in stress testing.

Taking these three nodes as examples, this paper introduces how to use JMeter to complete the stress test for them.

Web server

For most projects, you don't develop your own Web server, so the object of the Web server stress test is actually the software released to the Web server. The simplest Web test plan requires only three JMeter test components, as shown in the following figure:

Where:

The thread group defines the number of threads, the time at which the thread was generated, and the number of test cycles.

Define the server, port, protocol and method, request path, and so on in the http request.

The form listener is responsible for collecting and displaying results.

This setting is not enough for web applications that include security mechanisms. Typical web applications will:

1. There is a login page, which is the entrance to the entire application. When the user logs in, the application will put the user-related security information into the session.

two。 There is a filter that intercepts requests and checks whether the session associated with each request contains user security information. If not, the request is redirected to the login page, asking the user to provide security information.

If the above test plan is applied in this configuration, all requests except the login page will actually be located to the login page because of the lack of user security information. If there is no assertion, then all requests are successful in the eyes of the listener. In fact, none of these requests finally got to where they were supposed to go. Obviously, this kind of test result is not what we expected.

For successful testing, there are at least two ways:

Method one, remove the security settings of the program, such as filter, so that you can access restricted content without user security information.

Second, do not modify the program, use the "Http URL rewrite modifier" or "Http Cookie Manager" provided by JMeter.

For the first method, there are limitations:

You need to modify the program configuration, such as removing the settings for secure filter in web.xml. Multiple versions of web.xml need to be maintained, such as separate web.xml for stress tests and functional tests, which increases maintenance costs and may forget to change the web.xml back after testing.

There is nothing you can do for some pages that need user security information, such as some business audit operations that require user security information to record. Because of the lack of such information, the test is doomed to failure. If the program is further modified in order to solve this problem, then because there are multiple versions of the program, then its maintenance will be greatly increased.

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, it is ideal to choose the second method. The following is a simplified example to illustrate the configuration steps using method 2.

1. The example consists of the following files:

AuthorizenFilter.java, the filter is responsible for verifying the existence of user information in the session. If not, then go to login.jsp. Its main method, 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 login page, do not go to if (uri.equalsIgnoreCase ("/ 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 the user's information. For simplicity, the login operation here only allows you to specify a user name and password. The main contents are 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. Where login.jsp is responsible for generating the User object and calling the login of User. Go to welcome.jsp when login returns true. The code for its validation section:

Web.xml, configure filter to intercept all requests for access to JSP pages:

Authorizen org.foxgem.jmeter.AuthorizenFilter authorizen * .jsp

two。 Create a Web test plan with the following structure:

The main test components are described as follows:

The http request default value is responsible for recording the default value of the request, such as server, protocol, port, and so on.

The first http request, request login.jsp, is appended with the parameters needed for validation (user=foxgem,pwd=12345678,Submit=Submit); it contains response assertions that verify that the url contains "welcome.jsp", which can be reflected in the program.

The second http request, which is the response assertion contained in welcome.jsp;, verifies that the response text contains "foxgem", which is part of the logic of the welcome.jsp page.

The http cookie manager is responsible for managing the cookie used throughout the test, and it does not need to set any properties.

The loop controller sets the number of cycles to send the second request, and the table listener is responsible for collecting and displaying the test results of the second request.

After starting the test plan, the order of execution is as follows: first, the first request login page for login; after successful login, use the loop controller to execute the second request. When a welcome.jsp is requested, the response assertion is used to verify that the welocme.jsp is indeed processing the request, not because of other pages. One thing to pay attention to in this test plan is the http cookie manager. It is because of its role that the second request can be successfully sent to welcome.jsp for processing, rather than because of the lack of user security information forwarded to login.jsp.

In this example, we don't use cookie in the program (using session), so how does the http cookie manager work? This is because there are two ways to track the status of session in the servlet/jsp specification:

Using cookie, sessionid is retained and passed. It does not require the program to have any special handling of url, but requires the browser to allow cookie. In this case, this is the case.

Using url rewriting, explicitly pass sessionid between the browser and the server each time. It requires the program to encode url and has no requirements for browsers.

For the second case, you can use the http url rewrite modifier in the JMeter front manager. For the Tomcat,Session parameter jsessionid, the path extension uses ";". When using url encoding, it is important to note that the browser's cookie function must be turned off. Because url encoding functions, such as encodeURL, determine whether sessionid needs to be encoded into url. When the browser allows cookie, it will not be encoded.

If cookie instead of session is used to store user security information, then use the http cookie manager directly. At this point, you need to write the used cookie parameters and values directly to the manager, which is responsible for managing it. The same is true for other cookie uses.

After the login problem is resolved, there is no difficulty in testing the Web server. The rest is to flexibly use the relevant test components to build the test plan according to the actual needs. (of course, there are other usage scenarios for security issues. When using it, you need to be clear: whether JMeter supports it, and if so, which test component to solve. )

Database server

The database server is indispensable in most enterprise projects, and stress tests are conducted 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 to be optimized.

JMeter uses JDBC to send requests to complete testing of the database. For a database test plan, just establish the following structure:

Where:

JDBC connection configuration, which is responsible for configuring database connection-related information. Such as: database url, database driver class name, user name and password, etc. In these configurations, the "variable name bound to the pool" (Variable Name Bound to Pool) is a very important attribute, which is referenced in the JDBC request. Through it, the JDBC request is associated with the JDBC connection configuration. Before testing, please put the required database driver into the classpath of JMeter.

JDBC request, which is responsible for sending the request for testing.

Graphic results, collect and display test results.

In a real project, there are at least two types of JDBC requests that require attention: select statements and stored procedures. The former reflects whether the select statement is efficient and whether the index of the table needs to be optimized, while the latter reflects whether the algorithm of the stored procedure is efficient. If they are inefficient, they will inevitably lead to unsatisfactory responses. For these two requests, the configuration of the JDBC request is slightly different:

Select statement

Stored procedure

For Oracle, if you are testing a function, you can also use the select statement to configure it, and you can use the: select function (input parameter) from dual statement to test, where dual is the keyword of oracle and represents a dumb table. For database products from other vendors, please find the manual.

JMS server

As a platform for message data exchange, MOM is also a potential link that affects the efficiency of application execution. In the Java program, it interacts with MOM through JMS. As a stress testing tool implemented by Java, JMeter can also use JMS to test the message exchange and related data processing capabilities of the application. This should not be difficult to understand, because throughout the testing process, the focus of JMeter testing should be on the capabilities of the producers and consumers of the message, not the MOM itself.

According to the JMS specification, there are two ways to exchange messages: publish / subscribe and peer-to-peer. JMeter provides different Sampler support for these two situations. In the following MOM, we use ActiveMQ 3.2.1 to describe how these two message exchanges are tested with JMeter.

1. Preparation before testing (both cases apply)

Although JMeter can use JMS to test MOM, it does not provide the packages that JMS needs to use. Therefore, you need to copy these packages to% JMETER_HOME%/lib before testing. For ActiveMQ, it is to copy% ACTIVEMQ_HOME%/lib. % ACTIVEMQ_HOME%/optional is an optional package and you can consider whether to copy it or not according to the actual situation.

JMeter uses JNDI when testing, and in order to provide information about the JNDI provider, you need to provide jndi.properties. At the same time, you need to put jndi.properties in the classpath of JMeter, and it is recommended that you package it with the ApacheJMeter.jar under bin. The example for ActiveMQ,jndi.properties is as follows:

Java.naming.factory.initial = org.activemq.jndi.ActiveMQInitialContextFactoryjava.naming.provider.url = tcp://localhost:61616# specifies the jndi name of the connectionFactory, which can be separated by commas. # for topic, use (TopicConnectionFactory) context.lookup ("connectionFactry") # for queue, (QueueConnectionFactory) context.lookup ("connectionFactory") connectionFactoryNames = connectionFactory# to register queue, format: # queue. [jndiName] = [physicalName] # when using: (Queue) context.lookup ("jndiName"), here MyQueuequeue.MyQueue = example.MyQueue# Registration topic, format: # topic. [jndiName] = [physicalName] # when using: (Topic) context.lookup ("jndiName") Here is MyTopictopic.MyTopic = example.MyTopic

two。 Publish / subscribe

In actual testing, publishers and subscribers do not need to appear at the same time. For example, sometimes we might want to test the message output of a message publisher per unit of time, so we don't need a message publisher, just a subscriber. In order to illustrate the use of these two types of Sampler, this example establishes the following test plan:

The properties of JMS Publisher and JMS Subscriber: select "use jndi.properties", the connection factory is connectionFactory, the theme is MyTopic, and the others use the default configuration. For JMS Publisher, you also need to provide text messages for testing.

Start ActiveMQ and run the test plan. If the configuration is correct, the relevant information will be printed in the background of the ActiveMQ after a successful connection to the JMeter. During the testing process, JMeter background printing may appear java.lang.InterruptedException information, which is a normal phenomenon and will not affect the test process and results. This can be seen in jmeter.log under bin.

3. Point to point

For peer-to-peer, JMeter provides only one Sampler:JMS Point-to-Point. In the example, create a test plan for the following figure:

Where: Communication style is Request Only. For another style: Request Response, the JMSCorrelationID in the JMS Header that received the message is verified to determine whether it is a response to the request message.

The above is how to use JMeter to complete common stress tests. Have you learned any knowledge or skills? If you want to learn more skills or enrich your knowledge reserve, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.