"Go" Apache JMeter Web Performance test instance

　Apache JMeter is a tool that can be used to test applications that utilize HTTP or FTP servers. It is Java-based, and it is also highly extensible through the API provided. Typical jmeter tests include creating loops and thread groups. The loop uses a preset delay to simulate successive requests to the server. Thread groups are designed to emulate concurrent workloads. JMeter provides a user interface. It also exposes APIs that allow users to run JMeter-based tests from Java applications. In order to create a load test in jmeter, you need to build a test plan. In practice, JMeter needs to perform a series of operations. The simplest test plan typically includes the following components:
Thread groups-these components are used to specify the number of threads to run and the wait period. Each thread impersonates one user, while the wait period is used to specify when all threads are created. For example, the number of threads is 5, the wait time is 10 seconds, and the interval between each thread is created is 2 seconds. The number of loops defines the run time of the thread. With the scheduler, you can also set the start time of the run.
Samplers-These components are configurable requests for server HTTP, FTP, or LDAP requests. This tutorial focuses only on Web services requests.
Listeners-these components are used to request post-processing of data. For example, you can save data to a file or use a chart to illustrate the results. The JMeter chart does not offer many configuration options at this time, but it is extensible and can always add additional visualizations or data processing modules.
　　
A detailed description of the available components is given on the Apache JMeter website. In some cases, if the available components are not suitable for a particular test, the developer can write his or her own script or Java class and embed it in the test plan by placing the jar file in the \lib\ext\ directory where the JMeter is installed.

The version we used in this article is JMeter 2.1. Download the executable binaries from the Web site, unzip them, and then use the application on a Windows or UNIX platform. If you are working in the Windows operating system, go to the Bin folder to start the application with Jmeter.bat or Jmeterw.bat. As shown in the initial user interface 1.

　　

Create a Load test
　　
Using the load test feature of JMeter, you can generate high loads on the server and determine their capacity and limits. Note: To use a Web services sample, you need available Mail.jar and Activation.jar, which can be obtained from Sun Microsystems (see the link below). Because of authorization restrictions, Apache did not distribute these libraries. After downloading these two jar files, place them in the Java classpath or install the JMeter lib directory.

　　

Now right-click on Test plan and add the thread group and loop Controller. We use these two components to set the number of concurrent users to simulate and the duration of the test. Under the tree-like loop controller, add "WebService (SOAP) Request" and graph,2 as shown. If the webservice request cannot be added to the test plan, there may be no mail.jar or Activation.jar in the path.

Type the number of threads, the wait period, and the number of loops. In this tutorial we use 5, 10, and 100, respectively. Set the loop controller count to 1. If the WebLogic server that is configured with Web services is still not running, either start it manually or start from the WebLogic workshop.

Configuring Load Tests
　　
As shown in 3, we need to set the SOAP request parameters that are sent to the server. If a link (URL) to the WSDL file is available, paste the link into the WSDL URL field and click Load WSDL. The available methods are displayed in the Web methods combo box. Next, you need to click Configure to populate server name or IP, Port number, path, and SOAPAction.

　　

If there are no WSDL links available, you can also manually type the values for the server name, port number, path, and soap operation. The final step is to fill in the SOAP request in the SOAP/XML-RPC data area. The user can also load from a file using the SOAP XML data option.

After you enter all the fields in the Web Services Request dialog box, click Ctrl+s to save the JMeter project. To visualize the data, we added the chart elements "graph results" and "Spline Visualizer". In addition, we can also send a response to a file by adding a "Save responses to a file" component, which is useful when checking for SOAP response errors. To simulate a more realistic order of client requests, we inserted a timer element in the tree-"Gaussian Random timer". After doing this, the client's request is distributed more chaotic, and the server is clicked randomly instead of at equal intervals. We set the Gaussian random time to deviate from 100ms and the constant delay offset to 300ms.

Run a Load test
　　
Users can run a load test by clicking Ctrl+r or by selecting Run from the menu and clicking Start to run the load test. Click the graphic symbol and you will see that the chart is populated and the data represents a request to the server, 4 to 6

Shown

　　

Figure 4: A chart that illustrates the test results. Number of threads = 5, wait time = 10, number of loops = 100. The loop controller is set to 1.
We chose to show three parameters in the chart--throughput (green Line), median (Purple Line), and average (blue line). We modify the parameters of the test. To simulate a higher load on the server, we increased the number of threads to 10 and 50 and compared the server's response time. Click Start again and look at the results shown in the chart, see Figure 5 and Figure 6.
　　　　

Figure 5: A chart that illustrates the test results. Number of threads = 50, wait time = 5, number of cycles = 20, loop controller set to 1.
The parameters at the bottom of the chart have the following meanings:
Throughput is the number of requests that the server processes per minute.
The average is the total elapsed time divided by the number of requests sent to the server.
The median is the number representing the time, and half of the server response time is below that value and the other half is above the value.
Deviations indicate the server response time change, the size of the discrete measure, or, in other words, the distribution of the data.
The final sample is the last completed request.
By observing these three runs and their corresponding graphs, we can get the following valuable results:

　　

The response time is obviously increased as the thread increases. To proceed with the test, we can make more thread count, wait period, and number of loops. Note: We did not change or adjust the configuration of the server. WebLogic Server 9.0 has a thread pool that can be configured automatically, with limited configuration scope (see Naresh Revanuru compose Workload Management in WebLogic Server 9.0, Dev2dev), The table above shows that the increase in the number of clients has a non-linear effect on the server response time. In fact, increasing this number by twice or 10 times times will not have a noticeable impact! However, you should be aware of running the same experiment using the number of threads that are close to or exceeding the default server limit. To verify that the response received from the server is a real SOAP response rather than an HTTP error, we observe the contents of the following output file. This is a SOAP response that meets the above requirements

<soapenv:envelope xmlns:soapenv= "http://schemas.xmlsoap.org/soap/envelope/" > <soapenv:Header/> <soapenv:Body> <m:calculatearearesponse xmlns:m= "Http://myservice" > <m:return>12</m:return> </m:calculateAreaResponse> </soapenv:Body> </soapenv:Envelope> ：

To make the test results more visible, add Spline Visualizer to the plan , which is close to the Graph Results. Spline Visualizer provides a view of all sample times. It draws a continuous line with the segmented insertion function, spanning 10 points at the time of drawing, and each point represents a sample of 10﹪. A smooth distribution view based on a polynomial approximation algorithm is provided by replacing the connection point with a straight line in a spline chart. as shown in result 7

　　

Multiple jmeters
The JMeter also has a very useful remote start feature that allows users to start jmeter tests from multiple machines. The client host address can be entered in the "jmeter.properties" file located under the Bin folder. Locate the Remote_hosts property and add the remote host name there, separating it with a comma. Restart JMeter, click Remote Start or remote start all in the Run menu. Some Web and application servers can continuously process multiple requests for the same IP address and process requests for different IP addresses in parallel, so you can use this option to perform operations that are critical to requesting a different machine or distributing the test load to several clients.

"Go" Apache JMeter Web Performance test instance