Apache Performance Test Tool AB use detailed _linux

Web site Performance Stress testing is an indispensable part of the performance tuning process of the server Web site. Only if the server is under high pressure, can the software, hardware and other improper settings be revealed.

Apache vs nginx performance 2017

Performance testing Tools The most common is the following: AB, Http_load, Webbench, siege. Today we specialize in introducing AB.

Apache camel performance

AB is a pressure test tool with the Apache self. AB is very practical,apache performance testing tools, it can not only to the Apache server site access stress testing, but also to the other types of servers for stress testing. such as Nginx, Tomcat, IIS and so on.

Let's begin by introducing the use of the AB command: apache tuning for high performance

Nginx vs apache performance graph

1, the principle of AB

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 that simulate multiple visitors accessing a URL address at the same time. Its test target is URL based, so it can be used both to test Apache load pressures and to test the pressures of other Web servers such as Nginx, Lighthttp, Tomcat, and IIS.

The AB command is very low on the computer where the load is emitted, and it does not consume very high CPU or consume a lot of memory. But it will cause a huge load on the target server, the principle of similar to the CC attack. Your own test use also needs to be noted, otherwise too much load at once. May cause the target server resources to consume, when serious even causes the panic.

Second, the installation of AB

AB installation is very simple, if it is the source code to install Apache, it is much simpler. When Apache is installed, the AB command is placed in the bin directory of the Apache installation directory. As follows:

/usr/local/apache2/bin

If Apache is installed through 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 directly install the Apache Toolkit httpd-tools. 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 for detection. As follows:

Ab-v

If the AB installation succeeds, the AB–V command will display a phase AB version, as shown above.

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

Currently, the latest version of Apache 2.4.10,apache official website has no windows download version. But we can download the integrated packages provided by the Apache website as follows:

Three, AB parameter description

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

AB--help

Here's a description of these parameters. As follows:

The number of requests executed by-N 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 for the-t test. Its internal implied value is-n 50000, which limits the test to the server to a fixed total time. By default, there is no time limit.

-P contains the files that need to post the data.

-P provides Basic authentication trust to a relay agent. The username and password are separated by one: and sent in the form of a base64 encoding. This string is sent regardless of whether the server needs to (that is, whether the 401 authentication requirement code is sent).

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

-V Setting the level of detail for displaying information-4 or greater displays header information, 3 or greater values can display response codes (404,200, and so on), and 2 or greater values can display warnings and other information.

-V Displays the version number and exits.

-W outputs the results in HTML table format. By default, it is a table with two columns of white background width.

-I executes the head request rather than get.

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

-X. Uses a proxy server for the request.

-Y string for setting <tr> properties.

-Z Sets the string for the <td> property.

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

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

-A provides Basic authentication trust to the server. The username and password are separated by one: and sent in the form of a base64 encoding. This string is sent regardless of whether the server needs to (that is, whether the 401 authentication requirement code is sent).

-h shows how to use.

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

-E produces a comma-separated (CSV) file that contains the corresponding percentage (in subtle) time required to process each corresponding percentage request (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 TSV (tab-delimited) file. This file can be easily imported into Gnuplot,idl,mathematica,igor and even excel. One of the first behavioral headings.

-I executes the head request rather than get.

-K enables the HTTP keepalive feature, which executes multiple requests in an HTTP session. The KeepAlive feature is not enabled by default.

-Q Output A progress count in stderr if the number of requests processed is greater than 150,ab per processing of approximately 10% or 100 requests. This-Q tag can suppress this information.

Four, AB performance index

Several metrics are important in the performance testing process:

1. Throughput rate (Requests per second)

A quantitative description of the server's concurrent processing capacity, in units of reqs/s, refers to the number of requests processed within a unit time of a concurrent user. The maximum number of requests processed per unit of time for a concurrent user, called the maximum throughput rate.

Remember that throughput is based on the number of concurrent users. This sentence represents two meanings:

A, throughput and concurrent user count related

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

Calculation formula: Total requests/processing time to complete the number of requests, i.e.

Request per second=complete Requests/time taken for tests

It is important to note that this number 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 a given moment, simply speaking, a session.

3, concurrent user number (concurrency level)

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

4, the average user request waiting time (times per request)

Calculation formula: The amount of time spent processing all requests (total requests/concurrent users), namely:

Time to Request=time taken for tests/(Complete requests/concurrency level)

5, the average server request latency (time of Request:across all concurrent requests)

Calculation formula: The number of time/total requests spent processing all requests to complete, namely:

Time taken For/testscomplete requests

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

At the same time, it is equal to the average number of user requests waiting times/concurrent users, that is

Time/request/concurrency Level

V. Actual use of AB

AB has more command parameters, and we often use the-C and-n parameters.

Below we actually carry on the operation, first creates 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

When the virtual host is finished, we start 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 performance. Use the following command:

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

-C10 indicates a concurrent user number of 10

-N100 represents a total of 100 requests

http://a.ilanni.com/index.php represents the target URL of the request

This line means that 100 requests are processed concurrently and 10 times index.php files are run.

Through the above diagram, the test results are also at a glance, Apache test throughput is: Requests per Second:204.89[#/sec] (mean).

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

The server software represents the name of the Web server software being tested.

The Server hostname represents the requested URL host name.

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

Document path represents the root absolute path in the URL of the request, and the file's suffix name allows us to generally understand the type of the request.

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

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

The time taken for tests represents the total amount spent on all of these requests being processed.

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 refers to a request that has occurred in connection with the server, sending data, and timeout after no response. If the header information for the HTTP response data received contains a status code other than 2XX, a statistic item named "NON-2XX Responses" is displayed in the test result, which is used 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 and body data length of each HTTP response data. Note that this does not include the length of HTTP request data, but only the total length of the application layer data flowing to the user's PC for the Web server.

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, calculation formula: Complete Requests/time taken for tests

Times per request user average requests wait time, calculation formula: Token for tests/(Complete requests/concurrency level).

Time to Requet (across all concurrent request) The server averages the wait times, and calculates the formula, which is the inverse of the throughput rate taken for Tests/complete requests. You can also count: Time of request/concurrency level.

Transfer rate represents the length of data that these requests get from the server in a unit of time, and calculates the formula: Total Trnasferred/time taken for tests, which is a good statistic for the server's ability to handle its export bandwidth when it reaches the limit.

Percentage of requests served within a certain time (MS) This part of the data describes the distribution of processing times per request, 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 requested.

Vi. Test Nginx Performance

The fifth step tested Apache performance and now we're testing the performance of Nginx.

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 requests the same page.

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 above diagram, the test results are also at a glance, nginx test the throughput rate is: Requests per Second:349.14[#/sec] (mean).

Compare Apache's request to this page throughput rate, found Nginx throughput is higher than Apache. According to the performance metrics we mentioned earlier requests per second throughput is higher, server performance is better.

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