Apache Bench - 环境设置


在本章中,我们将指导您如何在 VPS 上设置 Apache Bench 环境。

系统要求

  • 内存- 128 MB

  • 磁盘空间- 无最低要求

  • 操作系统- 无最低要求

安装 Apache 工作台

Apache Bench 是一个独立的应用程序,不依赖于 Apache Web 服务器安装。以下是安装 Apache Bench 的两步过程。

步骤 1 - 更新包数据库。

# apt-get update

请注意,终端命令之前的符号 # 表示 root 用户正在发出该命令。

步骤 2 - 安装 apache2 utils 包以访问 Apache Bench。

# apt-get install apache2-utils

Apache Bench 现已安装。如果您想测试托管在同一 VPS 上的 Web 应用程序,那么仅安装 Apache Web 服务器就足够了 -

# apt-get install apache2

作为一个 Apache 实用程序,Apache Bench 会在安装 Apache Web 服务器时自动安装。

验证 Apache Bench 安装

现在让我们看看如何验证 Apache Bench 安装。以下代码将帮助验证安装 -

# ab -V

输出

This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

当您看到上述终端输出时,表示您已成功安装 Apache Bench。

创建特权 Sudo 用户

从安全角度来看,系统管理员创建 sudo 用户而不是 root 被认为是一个很好的做法。为此,我们将创建一个名为 test 的测试用户 -

# useradd -m -d /home/test -g sudo test

让我们为新用户设置密码 -

# passwd test

系统将提示用户输入新密码进行测试。您可以输入一个简单的密码,因为我们只是测试,而不是部署到生产服务器。通常 sudo 命令会提示您提供 sudo 用户密码;建议不要使用复杂的密码,因为过程会变得繁琐。

输出

Enter new UNIX password:
Retype new UNIX password:   
passwd: password updated successfully

测试 Apache.org 网站

在本节中,我们将测试 Apache.org 网站。让我们首先切换到 sudo 用户测试 -

# su test

首先,我们将测试 Apache 组织的网站https://www.apache.org/。我们将首先运行命令,然后了解输出 -

$ ab -n 100 -c 10 https://www.apache.org/

这里-n是为基准测试会话执行的请求数。默认情况下仅执行单个请求,这通常会导致不具有代表性的基准测试结果。

-c是并发度表示一次执行多个请求的数量。默认为一次一个请求。

因此,在本次测试中,Apache Bench 将向 Apache 组织服务器发出 100 个并发数为 10 的请求。

输出

This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking www.apache.org (be patient).....done

Server Software:        Apache/2.4.7
Server Hostname:        www.apache.org
Server Port:            443
SSL/TLS Protocol:       TLSv1.2,ECDHE-RSA-AES256-GCM-SHA384,2048,256

Document Path:          /
Document Length:        58769 bytes

Concurrency Level:      10
Time taken for tests:   1.004 seconds
Complete requests:      100
Failed requests:        0
Total transferred:      5911100 bytes
HTML transferred:       5876900 bytes
Requests per second:    99.56 [#/sec] (mean)
Time per request:       100.444 [ms] (mean)
Time per request:       10.044 [ms] (mean, across all concurrent requests)
Transfer rate:          5747.06 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:       39   46  30.9     41     263
Processing:    37   40  21.7     38     255
Waiting:       12   15  21.7     13     230
Total:         77   86  37.5     79     301

Percentage of the requests served within a certain time (ms)
  50%     79
  66%     79
  75%     80
  80%     80
  90%     82
  95%     84
  98%    296
  99%    301
 100%    301 (longest request)

运行我们的第一个测试后,很容易识别该命令的使用模式,如下所示 -

# ab [options .....]  URL

在哪里,

  • ab - Apache Bench 命令

  • 选项- 我们要执行的特定任务的标志

  • URL - 我们要测试的路径 url

了解输出值

我们需要了解不同的指标才能了解 ab 返回的各种输出值。清单如下:

  • 服务器软件- 这是在第一次成功返回的 HTTP 标头中返回的 Web 服务器的名称。

  • 服务器主机名- 它是命令行上给出的 DNS 或 IP 地址。

  • 服务器端口- 这是 ab 连接的端口。如果命令行上未指定端口,则 http 的端口号默认为 80,https 的端口号默认为 443。

  • SSL/TLS 协议- 这是客户端和服务器之间协商的协议参数。仅当使用 SSL 时才会打印此信息。

  • 文档路径- 这是从命令行字符串解析的请求 URI。

  • 文档长度- 这是第一个成功返回的文档的大小(以字节为单位)。如果测试期间文档长度发生变化,则响应被视为错误。

  • 并发级别- 这是测试期间使用的并发客户端(相当于网络浏览器)的数量。

  • 测试所用时间- 这是从创建第一个套接字连接到收到最后一个响应所花费的时间。

  • 完成请求- 收到的成功响应的数量。

  • 失败的请求- 被视为失败的请求数。如果该数字大于零,将打印另一行,显示由于连接、读取、内容长度不正确或异常而失败的请求数。

  • Total Transferred - 从服务器接收的字节总数。该数字本质上是通过线路发送的字节数。

  • HTML Transferred - 从服务器接收的文档字节总数。该数字不包括 HTTP 标头中收到的字节

  • 每秒请求数- 这是每秒的请求数。该值是请求数除以所用总时间的结果。

  • 每个请求的时间- 每个请求花费的平均时间。第一个值的计算公式为 concurrency * timetaken * 1000 / done,而第二个值的计算公式为 timetaken * 1000 / done

  • 传输率- 通过公式 Totalread / 1024 / timetaken 计算得出的传输率。

负载测试输出的快速分析

了解了 ab 命令的输出值的标题后,让我们尝试分析和理解初始测试的输出值 -

  • Apache 组织正在使用他们自己的 Web 服务器软件 - Apache(版本 2.4.7)

  • 由于 https,服务器正在侦听端口 443。如果是 http,则为 80(默认)。

  • 100 个请求传输的总数据量为 58769 字节。

  • 测试在 1.004 秒内完成。没有失败的请求。

  • 每秒请求数 - 99.56。这被认为是一个相当不错的数字。

  • 每个请求的时间 - 100.444 毫秒(10 个并发请求)。因此,对于所有请求,它是 100.444 ms/10 = 10.044 ms。

  • 传输速率 - 接收到 1338.39 [千字节/秒]。

  • 在连接时间统计中,您可以观察到许多请求必须等待几秒钟。这可能是由于 apache Web 服务器将请求放入等待队列。

在我们的第一个测试中,我们测试了托管在不同服务器上的应用程序(即 www.apache.org)。在本教程的后面部分,我们将测试托管在运行 ab 测试的同一服务器上的示例 Web 应用程序。这是为了便于学习和演示的目的。理想情况下,主机节点和测试节点应该不同,以便进行准确测量。

为了更好地学习 ab,您应该在本教程中进行比较并观察不SymPy况下输出值的变化情况。

绘制 Apache Bench 的输出

在这里,我们将绘制相关结果,以了解随着请求数量的增加,服务器花费了多少时间。为此,我们将在上一个命令中添加-g选项,后跟将保存 ab 输出数据的文件名(此处为 out.data) -

$ ab -n 100 -c 10 -g out.data https://www.apache.org/

现在让我们在创建绘图之前查看out.data -

$ less out.data

输出

starttime       seconds ctime   dtime   ttime   wait
Tue May 30 12:11:37 2017        1496160697      40      38      77      13
Tue May 30 12:11:37 2017        1496160697      42      38      79      13
Tue May 30 12:11:37 2017        1496160697      41      38      80      13
...

现在让我们了解out.data文件中的列标题-

  • starttime - 这是呼叫开始的日期和时间。

  • - 与开始时间相同,但采用 Unix 时间戳格式(date -d @1496160697 返回开始时间输出)。

  • ctime - 这是连接时间。

  • dtime - 这是处理时间。

  • ttime - 这是总时间(它是 ctime 和 dtime 的总和,数学上 ttime = ctime + dtime)。

  • wait - 这是等待时间。

有关这些多个项目如何相互关联的图形可视化,请查看下图 -

多个项目

如果我们在终端上工作或者图形不可用,gnuplot是一个不错的选择。通过以下步骤我们将很快理解它。

让我们安装并启动 gnuplot -

$ sudo apt-get install gnuplot  
$ gnuplot

输出

G N U P L O T
Version 4.6 patchlevel 6    last modified September 2014
Build System: Linux x86_64

Copyright (C) 1986-1993, 1998, 2004, 2007-2014
Thomas Williams, Colin Kelley and many others

gnuplot home:     http://www.gnuplot.info
faq, bugs, etc:   type "help FAQ"
immediate help:   type "help"  (plot window: hit 'h')

Terminal type set to 'qt'
gnuplot>

当我们在终端上工作并假设图形不可用时,我们可以选择哑终端,它将通过终端本身以 ASCII 形式提供输出。这有助于我们通过这个快速工具了解我们的绘图是什么样的。现在让我们为 ASCII 绘图准备终端。

gnuplot> set terminal dumb

输出

Terminal type set to 'dumb'
Options are 'feed  size 79, 24'

我们的 gnuplot 终端现在已准备好进行 ASCII 绘图,让我们绘制out.data文件中的数据-

gnuplot> plot "out.data" using 9  w l

输出

  1400 ++-----+------+-----+------+------+------+------+-----+------+-----++
       +      +      +     +      +      +      +"out.data" using 9 ****** +
       |                                                                   |
  1200 ++                       ********************************************
       |     *******************                                           |
  1000 ++    *                                                            ++
       |     *                                                             |
       |     *                                                             |
   800 ++   *                                                             ++
       |    *                                                              |
       |    *                                                              |
   600 ++   *                                                             ++
       |    *                                                              |
       |    *                                                              |
   400 ++   *                                                             ++
       |    *                                                              |
   200 ++   *                                                             ++
       |    *                                                              |
       +****  +      +     +      +      +      +      +     +      +      +
     0 ++-----+------+-----+------+------+------+------+-----+------+-----++
       0      10     20    30     40     50     60     70    80     90    100

我们绘制了第 9 列中的 ttime,即总时间(以毫秒为单位)与请求数量的关系。我们可以注意到,对于最初的 10 个请求,总时间接近 100 毫秒,对于接下来的 30 个请求(从第 10 个第 40),它增加到 1100 毫秒,依此类推。您的绘图必须根据您的out.data有所不同。