Apache Benchmark：Web 性能测试利器

1. 简介介绍​

Apache Benchmark（简称 ab）是 Apache HTTP Server 项目开发的一款开源性能测试工具，专门用于对 HTTP 服务器开展基准测试。它通过模拟大规模并发请求，全面评估服务器在不同负载条件下的性能表现。无论是个人搭建的小型网站，还是大型企业级的 Web 应用，ab 都能助力开发者与运维人员快速洞察服务器的处理能力，精准定位潜在性能瓶颈，为优化服务器配置和应用程序代码提供关键依据。​

2. 原理​

ab 的工作机制较为直观。它创建多个并发的 HTTP 请求进程，向目标服务器发送大量 HTTP 请求。在请求发送过程中，ab 会记录每个请求从发出到接收服务器响应的时间，以及服务器返回的状态码等信息。通过对这些数据的统计分析，ab 能够计算出请求的平均响应时间、服务器的吞吐率、并发连接数等重要性能指标。例如，按照设定的并发级别，ab 会同时发起多个请求，模拟众多用户同时访问网站的场景，进而观察服务器对这些并发请求的处理方式，以此评估服务器性能。​

3. Linux 系统安装及校验是否成功​

安装​

在大多数基于 Debian 或 Ubuntu 的 Linux 系统中，可使用以下命令安装 ab：​

sudo apt-get update​

sudo apt-get install apache2-utils​

对于基于 Red Hat 或 CentOS 的系统，则需使用 yum 命令：​

sudo yum install httpd-tools​

校验安装​

安装完成后，可通过执行ab -V命令来验证是否安装成功。若安装无误，该命令将输出 ab 工具的版本信息，大致如下：​

This is ApacheBench, Version 2.3 <$Revision: 1843412 $>​

Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/​

Licensed to The Apache Software Foundation, http://www.apache.org/​

4. 参数说明​

-A auth-username:password
向服务器提供基本身份验证凭据。用户名和 密码由单个:并在电线上发送 base64编码。无论服务器是否需要发送字符串 它 (i.e.,已发送需要的401身份验证)。
-b windowsize 
TCP发送/接收缓冲区的大小 (以字节为单位)。
-B local-address
进行传出连接时要绑定到的地址。
-c concurrency
一次执行的多个请求的数量。默认是一个 一次请求。
-C cookie-name=value
添加一个Cookie:行的请求。参数是 通常以 对。此字段是可重复的。name=value
-d
不显示 “XX [毫秒] 表内服务的百分比”。(旧版 支持)。
-e csv-file
写一个逗号分隔值 (CSV) 文件，其中包含每个 百分比 (从1% 到100%) 服务所花费的时间 (以毫秒为单位) 请求的百分比。这通常比 'gnuplot' 文件; 因为结果已经是 'binned'。
-E client-certificate-file
连接到SSL网站时，使用提供的客户端证书 以PEM格式向服务器进行身份验证。该文件应 包含客户端证书，后跟中间证书， 其次是私钥。可在2.4.36和更高版本。
-f protocol
指定SSL/TLS协议 (SSL2、SSL3、TLS1、TLS1.1、TLS1.2或ALL)。 2.4.4及更高版本提供TLS1.1和TLS1.2支持。
-g gnuplot-file
将所有测量值写出为 “gnuplot'” 或TSV (制表符分隔 值) 文件。这个文件可以很容易地导入到像Gnuplot这样的包中， IDL，Mathematica，Igor甚至Excel。标签在的第一行 文件。
-h
显示使用信息。
-H custom-header
将额外的标头附加到请求中。该参数通常在 有效标题行的形式，包含冒号分隔的字段值 对 (i.e.,"Accept-Encoding: zip/zop;8bit")。
-i
做HEAD请求，而不是GET。
-k
启用HTTP KeepAlive功能，i.e.,执行多个 一个HTTP会话中的请求。默认值为no KeepAlive。
-l
如果响应的长度不是恒定的，则不报告错误。这个 可用于动态页面。 在2.4.7和更高版本中可用。
-m HTTP-method
请求的自定义HTTP方法。 可在2.4.10和更高版本。
-n requests
要为基准测试会话执行的请求数。默认的 只是执行一个请求，通常会导致 非代表性基准结果。
-p POST-file
包含要发布的数据的文件。记得还要设置-T。
-P proxy-auth-username:password
在途中向代理提供基本身份验证凭据。的 用户名和密码由单个:并发送 base64编码的导线。发送字符串，而不管 代理需要它 (i.e.,已发送407代理身份验证 需要)。
-q
当处理超过150个请求时，ab输出a 进度依靠stderr每10% 或100个左右的请求。的 -q标志将抑制这些消息。
-r
不要退出套接字接收错误。
-s timeout
套接字超时前等待的最大秒数。 默认值为30秒。 在2.4.4和更高版本中可用。
-S
不显示中值和标准偏差值，也不显示 当平均值和中位数大于 相隔一到两倍的标准偏差。并默认为 最小值/平均值/最大值 (旧版支持)。
-t timelimit
基准测试花费的最大秒数。这意味着一个 -n 50000内部。使用它来对服务器进行基准测试 固定的总时间。默认情况下，没有timelimit。
-T content-type
用于POST/PUT数据的Content-type标头，例如。 application/x-www-form-urlencoded。 默认为text/plain。
-u PUT-file
包含要放置的数据的文件。记得还要设置-T。
-v verbosity
设置详细级别-4及以上打印信息 标题，3以上打印响应代码 (404，200等)， 2以上打印警告和信息。
-V
显示版本号并退出。
-w
在HTML表格中打印结果。默认表为两列宽， 白色背景。
-x <table>-attributes
要用作属性的字符串<table>。属性 已插入。<table here >
-X proxy[:port]
对请求使用代理服务器。
-y <tr>-attributes
要用作属性的字符串<tr>。
-z <td>-attributes
要用作属性的字符串<td>。
-Z ciphersuite
指定SSL/TLS密码套件 (请参阅openssl密码)

5. 性能指标​

5.1 吞吐率（Requests per second）​

吞吐率指服务器在单位时间内处理的请求数量，单位为 “请求数 / 秒”。它直观反映了服务器的处理能力，数值越高，表明服务器在该测试场景下能够处理的请求越多。例如，若测试结果显示吞吐率为 200 requests per second，意味着服务器平均每秒能够成功处理 200 个请求。不过，较高的吞吐率需结合其他指标（如响应时间）综合评估，因为可能存在为提升吞吐率而牺牲响应时间的情况。​

5.2 并发连接数（The number of concurrent connections）​

并发连接数表示在某一时刻，服务器同时处理的连接数量。这取决于服务器的硬件资源（如 CPU、内存等）以及软件配置（如最大连接数限制）。在 ab 测试中，可通过设置-c参数模拟不同的并发连接数场景。例如，设置-c 100进行测试时，可观察服务器在同时处理 100 个连接时的性能表现。若服务器在高并发连接数下性能急剧下降，可能是其连接处理能力不足，需要优化服务器配置或代码。​

5.3 并发用户数（Concurrency Level）​

在 ab 测试中，并发用户数与并发连接数紧密相关，通过-c参数设置。可将其理解为同时向服务器发送请求的虚拟用户数量。例如，设置-c 50，即模拟有 50 个用户同时访问网站。该指标有助于了解服务器在面对不同数量同时在线用户时的性能状况。较高的并发用户数可能导致服务器负载增加，进而影响响应时间和吞吐率。​

5.4 用户平均请求等待时间（Time per request）​

该指标指每个请求从客户端发出到接收到服务器完整响应所耗费的平均时间，单位为毫秒。它反映了单个用户请求的响应延迟情况。例如，若测试结果显示用户平均请求等待时间为 500ms，说明平均每个请求需 0.5 秒才能得到服务器的响应。较长的等待时间会影响用户体验，通常需进一步分析服务器端或网络端的问题以进行优化。​

5.5 服务器平均请求等待时间（Time per request:across all concurrent requests）​

该指标计算的是在所有并发请求情况下，服务器处理每个请求的平均时间。它与用户平均请求等待时间不同，考虑了并发因素。例如，在 100 个并发请求的场景下，服务器处理这些请求的总时间为 50 秒，那么服务器平均请求等待时间为 50000ms（50 秒换算为毫秒）除以 100，即 500ms。此指标有助于评估服务器在高并发负载下的处理效率。​

6. 实际使用​

假设要测试一个简单的 Web 服务器http://example.com的性能，可使用以下命令：​

ab -n 1000 -c 100 http://example.com​

此命令表示对http://example.com发起 1000 次请求，并发用户数设置为 100。在测试过程中，ab 会持续向服务器发送请求，并实时记录相关数据。测试结束后，将输出详细的测试报告，涵盖上述各类性能指标。若要测试一个需要 POST 数据的接口，假设 POST 数据存放在postdata.txt文件中，数据类型为application/json，可使用如下命令：​

ab -n 500 -c 50 -p postdata.txt -T application/json http://example.com/api/post​

该命令会以 50 个并发用户，总共发送 500 次 POST 请求到http://example.com/api/post接口。​

7. 结果分析​

当 ab 测试完成后，会输出一系列测试结果。例如：​

Server Software: Apache/2.4.29​

Server Hostname: example.com​

Server Port: 80​

​

Document Path: /​

Document Length: 1221 bytes​

​

Concurrency Level: 100​

Time taken for tests: 5.233 seconds​

Complete requests: 1000​

Failed requests: 0​

Total transferred: 1328000 bytes​

HTML transferred: 1221000 bytes​

Requests per second: 191.09 [#/sec] (mean)​

Time per request: 523.308 [ms] (mean)​

Time per request: 5.233 [ms] (mean, across all concurrent requests)​

Transfer rate: 248.49 [Kbytes/sec] received​

​

Connection Times (ms)​

min mean[+/-sd] median max​

Connect: 0 1 0.9 1 4​

Processing: 29 520 205.4 498 1200​

Waiting: 29 519 205.4 498 1200​

Total: 30 521 205.4 499 1200​

​

Percentage of the requests served within a certain time (ms)​

50% 499​

66% 531​

75% 552​

80% 567​

90% 608​

95% 644​

98% 710​

99% 760​

100% 1200 (longest request)​

从上述结果可知，吞吐率为 191.09 requests per second，表明服务器每秒能处理约 191 个请求。用户平均请求等待时间为 523.308ms，

服务器平均请求等待时间为 5.233ms。

通过分析连接时间部分，可了解连接建立时间（Connect）、请求处理时间（Processing）以及等待时间（Waiting）的分布情况。

例如，50% 的请求在 499ms 内完成，90% 的请求在 608ms 内完成，这有助于评估服务器响应时间的稳定性。​

8. 服务器信息​

在 ab 测试结果中，会包含服务器相关信息，如上述例子中的Server Software: Apache/2.4.29、Server Hostname: example.com以及Server Port: 80。

这些信息有助于了解被测试服务器的基本配置，包括服务器软件类型及版本、服务器主机名和监听端口。不同的服务器软件和版本在性能表现上可能存在差异，了解这些信息对分析性能测试结果至关重要。例如，若发现某个特定版本的服务器软件在高并发下性能欠佳，可能需要考虑升级服务器软件版本。​

9. 文档信息​

关于 ab 工具的详细文档，可在 Apache 官方网站获取。文档中包含更全面的参数说明、使用示例以及常见问题解答。对于深入了解 ab 工具的高级特性和进行复杂场景的性能测试，官方文档是极具价值的参考资料。此外，在一些开源技术论坛和社区中，也有大量关于 ab 工具使用的讨论和经验分享，开发者和运维人员可通过搜索相关关键词，获取更多实际应用中的技巧和解决方案。​

10. 重要指标​

在 ab 测试结果的众多指标中，吞吐率、并发用户数、用户平均请求等待时间是较为关键的指标。吞吐率直接反映服务器的处理能力；

并发用户数决定测试场景的负载规模，通过调整并发用户数可模拟不同程度的用户访问压力；

用户平均请求等待时间与用户体验紧密相关，较长的等待时间可能导致用户流失。在优化服务器性能时，通常需重点关注这几个指标，通过调整服务器配置、优化应用代码或升级硬件等方式，提高吞吐率，降低用户平均请求等待时间，同时确保服务器能够承受一定规模的并发用户数。​

11. 网络上消耗的时间的分解​

在 ab 测试结果的连接时间部分（Connection Times），对网络上消耗的时间进行了分解。Connect表示从客户端发起连接请求到与服务器建立连接所花费的时间，主要受网络延迟、服务器连接队列长度等因素影响。Processing时间指服务器从接收到请求到处理完成并开始发送响应的时间，反映服务器端应用程序的处理效率。Waiting时间实际上是Processing时间的一部分，更确切地说是客户端等待服务器发送响应数据的时间。Total时间则是从客户端发起请求到完全接收到服务器响应的总时间，即Connect + Processing的时间总和。通过分析这些时间的分布情况，能够定位性能瓶颈是出在网络连接阶段，还是服务器端的处理阶段。例如，若Connect时间过长，可能是网络带宽不足或服务器连接配置不合理；若Processing时间过长，则可能需要优化服务器端的应用程序代码或数据库查询。​