Apache Bench – 环境设置

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

系统将提示用户 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 命令

  • options – 我们要执行的特定任务的标志

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

了解输出值

我们需要了解不同的metric，才能理解ab返回的各种输出值。列表如下 –

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

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

  • 服务器端口– 这是 ab 连接的端口。如果命令行上没有给出端口，则默认为 http 的 80 和 https 的 443。

  • SSL/TLS 协议– 这是客户端和服务器之间协商的协议参数。只有在使用 SSL 时才会打印。

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

  • 文档长度– 第一个成功返回的文档的大小（以字节为单位）。如果测试期间文档长度发生变化，则响应被视为错误。

  • 并发级别– 这是测试期间使用的并发客户端（相当于 Web 浏览器）的数量。

  • Time Taken for Tests – 这是从创建第一个套接字连接到收到最后一个响应所花费的时间。

  • Complete Requests – 收到的成功响应的数量。

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

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

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

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

  • Time per request – 每个请求花费的平均时间。第一个值使用公式 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 [Kbytes/sec] 接收。

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

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

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

绘制 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 – 这是呼叫开始的日期和时间。

  • seconds – 与 starttime 相同，但采用 Unix 时间戳格式（date -d @1496160697 返回 starttime 输出）。

  • ctime – 这是连接时间。

  • dtime – 这是处理时间。

  • ttime – 这是总时间（它是 ctime 和 dtime 的总和，数学上是 ttime = ctime + dtime）。

  • 等待– 这是等待时间。

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

多个项目

如果我们在终端上工作或图形不可用，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 个请求（从 10th 到 40th)，它增加到 1100 毫秒，依此类推。根据您的out.data ，您的情节必须有所不同。

觉得文章有用？

点个广告表达一下你的爱意吧 ！😁