Slime: Application of Apache performance test Tool AB

This article by show according to Lin Feng to provide friendship sponsorship, starting in the mud row world.

Website Performance Stress testing is an essential part of the performance tuning process for server sites. Only let the server in the high-pressure situation, can really reflect the software, hardware and other improper settings exposed problems.

Performance testing tools are now most commonly found in the following categories: AB, Http_load, Webbench, siege. Today we specialize in introducing AB.

AB is an Apache self-brought stress test tool. AB is very practical, it can not only the Apache server site access stress testing, or other types of servers can be stress testing. such as Nginx, Tomcat, IIS, and so on.

Let's start by introducing the use of the AB command:

1, AB's principle

2, the installation of AB

3, AB parameter description

4. AB Performance Index

5, AB actual use

6. Test Nginx Performance

First, the principle of AB

AB is the abbreviation for the Apachebench command.

AB principle: The AB command creates multiple concurrent access threads, simulating multiple visitors accessing a URL address at the same time. Its test target is URL-based, so it can be used to test the load pressure of Apache, as well as other Web servers such as Nginx, Lighthttp, Tomcat, and IIS.

The AB command is very low on the computer that emits the load, and it does not occupy a high CPU or consume a lot of memory. But it will cause a huge load on the target server, which works like a CC attack. You also need to be aware of your own testing, or too much load at a time. May cause the target server resources to run out, serious even causes the panic.

Second, the installation of AB

The installation of AB is very simple, if the source code installed Apache, it is more simple. After Apache is installed, the AB command is stored in the bin directory of the Apache installation directory. As follows:

/usr/local/apache2/bin

If Apache is installed via the Yum RPM package, the AB command is stored in the/usr/bin directory by default. As follows:

which AB

Note: If you do not want to install Apache but want to use the AB command, we can install Apache Toolkit httpd-tools directly. As follows:

Yum-y Install Httpd-tools

To see if AB is successfully installed, you can switch to the above directory and use the AB–V command to detect. As follows:

Ab-v

If the AB installation succeeds, the AB–V command will show the version of the AB, as shown.

Note that the above is installed under the Linux platform, if it is under the Windows platform, we can also download the corresponding version of Apache to install.

At present, the latest version of Apache 2.4.10,apache website has no windows download version. However, we can download the integration package provided by the Apache website as follows:

Third, the AB parameter description

For the use of the AB command, we can view it through the help command. As follows:

AB--help

Let's take a description of these parameters. As follows:

-N The number of requests executed in the test session. By default, only one request is executed.

-c The number of requests produced at a time. The default is one at a time.

The maximum number of seconds that the-t test takes. Its internal implied value is-n 50000, which allows the server to be tested in a fixed total time limit. By default, there is no time limit.

-P contains the files that require post data.

-P provides a Basic authentication trust to a transit agent. The user name and password are separated by a: and sent in Base64 encoded form. This string is sent regardless of whether the server is required (that is, if the 401 authentication requirement code is sent).

The Content-type header information used by the-t post data.

-V Sets the level of detail that displays information-4 or greater displays header information, 3 or greater values can display response codes (404,200, etc.), and 2 or greater values can display warnings and other information.

-V Displays the version number and exits.

-W outputs the result in the format of an HTML table. By default, it is a table with a two-column width on a white background.

-I executes the head request instead of get.

-X sets the string for the <table> property.

-X uses a proxy server for the request.

The string of the-Y setting <tr> property.

-Z Settings <td> properties of the string.

-C attaches a cookie to the request: line. The typical form is a parameter pair of Name=value, which can be repeated.

-H attaches additional header information to the request. A typical form of this parameter is a valid header information row that contains a pair of fields and values separated by colons (for example, "Accept-encoding:zip/zop;8bit").

-A provides a Basic authentication trust to the server. The user name and password are separated by a: and sent in Base64 encoded form. This string is sent regardless of whether the server is required (that is, if the 401 authentication requirement code is sent).

-H Displays the usage method.

-D does not display the message "percentage served within XX [MS] table" (Support for previous versions).

-E produces a comma-delimited (CSV) file that contains the corresponding percentage (in subtle units) of time that is required to process requests for each corresponding percentage (from 1% to 100%). This format is more useful than the ' gnuplot ' format because it is "binary".

-G writes all test results to a ' gnuplot ' or a TSV (tab-delimited) file. This file can be easily imported into Gnuplot,idl,mathematica,igor or even Excel. One of the first behavior headings.

-I executes the head request instead of get.

-K enables the HTTP keepalive feature, which is to execute multiple requests in an HTTP session. By default, the KeepAlive feature is not enabled.

-Q If the number of requests processed is greater than 150,ab per processing of approximately 10% or 100 requests, a progress count is output at stderr. This-Q flag can suppress this information.

Iv. Performance Index of AB

Several indicators are important in the performance testing process:

1. Throughput rate (requests per second)

A quantitative description of the server concurrency processing capability, in REQS/S, which refers to the number of requests processed per unit of time in a concurrent user. The maximum number of requests per unit of time that a concurrent user could process, called the maximum throughput rate.

Remember: The throughput rate is based on the number of concurrent users. This statement represents two meanings:

A, throughput rate and number of concurrent users

b, different number of concurrent users, the throughput rate is generally different

Calculation formula: Total number of requests/time taken to complete these requests, i.e.

Request per second=complete Requests/time taken for tests

It is important to note that this value represents the overall performance of the current machine, and the larger the value the better.

2. Concurrent connections (the number of concurrent connections)

The number of concurrent connections refers to the number of requests received by the server at some point, simply speaking, is a session.

3. Number of concurrent users (Concurrency level)

To be aware of the difference between this concept and the number of concurrent connections, a user may produce multiple sessions at the same time, that is, the number of connections. Under http/1.1, IE7 supports two concurrent connections, IE8 supports 6 concurrent connections, FIREFOX3 supports 4 concurrent connections, so our number of concurrent users will have to be divided by this cardinality accordingly.

4. Average user request wait time (times per request)

Calculation formula: The amount of time spent processing all requests (total number of requests/concurrent users), i.e.:

Time per request=time taken for tests/(complete requests/concurrency level)

5. Average Server request Wait time (Request:across all concurrent requests)

Calculation formula: The amount of time/Total requests processed to complete all requests, namely:

Time taken For/testscomplete requests

As you can see, it is the reciprocal of the throughput rate.

It also equals the average request waiting time/number of concurrent users, i.e.

Time per request/concurrency level

V. Actual use of AB

The command parameters of AB are more, and we often use the-C and-n parameters.

Below we are actually operating, first create a new virtual host a.ilanni.com. As follows:

Cat/etc/httpd/conf/httpd.conf|grep-v ^#|grep-v ^$

Mkdir-p/www/a.ilanni.com

Echo ' <?php phpinfo ();? > ' >/www/a.ilanni.com/index.php

cat/www/a.ilanni.com/index.php

After the virtual host is new, we will launch Apache and access the virtual host a.ilanni.com. As follows:

wget http://a.ilanni.com

Once the virtual host a.ilanni.com is created, we will now test Apache for performance. Use the following command:

Ab-c 10-n http://a.ilanni.com/index.php

-C10 indicates that the number of concurrent users is 10

-N100 indicates that the total number of requests is 100

http://a.ilanni.com/index.php indicates the destination URL of the request

This line represents processing 100 requests at the same time and running the index.php file 10 times.

Through, the test results are also clear, Apache tested throughput rate is: Requests per second:204.89[#/sec] (mean).

In addition, there are some other information that needs to be explained below:

Server Software represents the name of the Web server software being tested.

The Server hostname represents the URL host name of the request.

Server port represents the listening port of the Web server software being tested.

Document path represents the root absolute path in the requested URL, and with the suffix of the file, we can generally understand the type of the request.

Document length represents the body size of the HTTP response data.

Concurrency level represents the number of concurrent users, which is one of the parameters we set.

Time taken for tests represents the total amount of times that all these requests have been processed to complete.

Complete requests represents the total number of requests, which is one of the parameters we set.

Failed requests represents the number of failed requests, where the failure is the case where the request is in connection with the server, sending data, and so on, and when there is no response time out. If the header information of the received HTTP response data contains a status code other than 2XX, another statistic named "Non-2xx responses" is displayed in the test results to count the number of requests that are not counted in the failed request.

Total transferred represents the sum of the response data lengths for all requests, including the header information for each HTTP response data and the length of the body data. Note that this does not include the length of the HTTP request data, only the total length of the application layer data that the Web server flows to the user's PC.

The HTML transferred represents the sum of the body data in all the requested response data, minus the length of the header information in the HTTP response data in total transferred.

Requests per second throughput rate, calculation formula: Complete Requests/time taken for tests

Time per request user average request latency, calculation formula: Timestamp for tests/(complete requests/concurrency level).

Time per Requet (across all concurrent requests) The average request latency of the server, calculated by the formula: Timing taken for tests/complete requests, exactly the reciprocal of the throughput rate. It is also possible to count: Time per request/concurrency level.

Transfer rate represents the length of data that these requests get from the server within a unit time, calculating the formula: Total Trnasferred/time taken for tests, this statistic is a good indication of the capacity of the server to reach the limit of its export broadband demand.

Percentage of requests served within a certain time (MS) This data is used to describe the distribution of each request processing times, such as the above test, 80% of the request processing time is not more than 6ms, This processing time refers to the previous time per request, that is, for a single user, the average processing times for each of the requests.

Six, test Nginx performance

The fifth step tests the performance of Apache and now we test Nginx performance.

First configure the Nginx virtual host, as follows:

Cat/usr/local/nginx/conf/nginx.conf|grep-v ^#|grep-v ^$

After the virtual host configuration is complete, we now access the virtual host. As follows:

wget a.ilanni.com

Note that the virtual host is the same as the Apache virtual host and the same page is requested.

Use the same command as Apache to test Nginx, as follows:

Ab-c 10-n http://a.ilanni.com/index.php

The results are as follows:

Through, the test results are also at a glance, the throughput rate of Nginx test is: Requests per second:349.14[#/sec] (mean).

Compare Apache request This page throughput rate, found that the Nginx throughput rate is higher than Apache. The higher the throughput rate of the requests per second, the better the server performance, according to the performance indicators we mentioned earlier.

This also proves that nginx performance is indeed higher than Apache performance.

Slime: Application of Apache performance test Tool AB