Unlike httpunit, jmeter performs stress testing. In addition, jmeter can not only test web applications, but also test FTP servers and LDAP servers. This article describes how to use jmeter to test web applications.
The first is to create a new testplan and a threadgroup, and then add various components in it. That is to say, after understanding these components of jmeter, the test can be done, so the testplan file of easycluster is provided first:
More intuitive:
First, we create a threadgroup. Number of threads indicates how many users are simulated for testing. ramp-up period indicates how long it takes to start all threads. That is to say, every ramp-up period/number of threads starts a thread. Loop count indicates the number of test requests sent by a thread. For our web application, it indicates the number of HTTP requests sent.
Then add an HTTP request defaults. With this, you do not need to fill in the server IP address and port in the HTTP request every time for convenience. Then, add a cookie manager, for some applications that use cookies to implement the session, this is required; then we add a once only controller, which is a logic controller that represents the HTTP request under this controller, each thread is only performed once and does not loop. Therefore, we put the home page and login action under this, and finally create an interleave controller (alternate Controller), which is also a logic controller, indicates the HTTP request under the controller. The thread will execute the request in sequence instead of in disorder. Another case is that if the thread repeatedly executes the same HTTP request, the web server will have a cache, so this test is not ideal. This alternative controller is used, each request to the Web server is different, so the effect will be better, especially for the function of "search information". Finally, add a table viewing tool, which belongs to the listener component, in this component, you can define the path and name of the output file. Without this component, jmeter has no output. In this component, you can test the request and success in a table.
Finally, configure the URL rewriting modifier, because Tomcat's session implementation is not implemented through cookies, but through session IDs. That is to say, after a user logs on to a session, tomcat maintains a session ID, and each request requires that the session ID be included in each HTTP request URL! Therefore, we create an http url re-writing modifier, and then fill in a "session argument name" in its attributes, because in Tomcat, the URL re-writing mode is used, the URL is as follows: http: // 192.168.0.2: 8080/easycluster/login. EC; JSESSIONID = b1a75f512fb84ef0d52091d2ade91491
Therefore, here we need to fill in "JSESSIONID" in this item, jmeter will go to the URL and follow this parameter to capture the above session ID, then, this stuff is included in each request. You must note that you need to check "Path Extension (use"; "as separator)" here because, the session ID in Tomcat URL re-writing is added to the URL by a semicolon. Therefore, you need to check this option. For some Web servers, the session is the same as the common URL parameter? And & this method is added. In this case, this checkbox does not need to be checked!
Everything is ready. Select Run to start the test! In addition, if the checkbox "function test mode" is selected in the test plan, jmeter records the HTML code obtained in each request, which affects performance very much, but for the first test, it is also useful to test whether our configuration is correct.
/Files/super119/jmeter.rar
