负载测试简介

介绍

随着网站和Web应用程序的功能更丰富和复杂，性能成为开发人员和用户的主要关注点。 随着研究表明，更快的网站导致更多的用户，更多的销售和更多的流量，重要的是要注意您可以快速地将您的网站提供给您的用户并在浏览器中呈现。

这一知识领域的总称是网络性能优化 ，而且在过去几年中，已经开发出许多最佳实践，技术和技术来改进网络体验。 这些技术中的许多技术集中在减少网页的下载大小，优化JavaScript，并限制页面需要的各个HTTP请求数量。

在本文中，我们将讨论Web性能的另一面：您的服务器可以快速响应用户的请求？ 我们将回顾负载测试的一般情况，逐步通过计划找到服务器的最大实际响应率，并讨论一些开源负载测试软件。

词汇表

在我们开始之前，让我们来澄清一些相关的术语和概念：

• 延迟是服务器响应客户端请求的速度的度量。 通常以毫秒（ms）为单位，延迟通常被称为响应时间 。 较低的数字表示更快的响应 从发送请求到收到响应的时间，在客户端测量延迟。 网络开销包含在这个数字中。
• 吞吐量是服务器在特定时间间隔内可以处理的请求数 ，通常以秒为单位的请求报告。

• 百分位数是一种将结果按整个样本集合的百分比进行分组的方式。 如果您的第50个百分点响应时间为100ms，则表示50％的请求在100ms或更短的时间内被返回。 下图显示了为什么通过百分位数来查看您的测量是有用的：

  

  上图显示了一段时间内Web服务器的延迟。 尽管平均（平均）响应时间相当一致，但在第99百分位数线上有一个大的飙升。 这意味着1％的用户请求比这个第99个百分位数的测量更差 ，而平均值保持相对稳定。 因此，值得一看百分位数，以更准确地了解用户真正体验的内容。

负载测试基础

负载测试是将模拟HTTP流量发送到服务器以便测量性能并回答一些重要问题的做法，例如：

• 服务器是否有足够的资源（CPU，内存等）来处理预期的负载？
• 服务器响应速度足以提供良好的用户体验吗？
• 我们的应用程序是否有效运行
• 我们需要扩展我们的服务器硬件，还是扩展到多个服务器？
• 是否有特别资源密集型的任何页面或API调用？

通过在一台机器（或一组机器）上运行负载测试软件来执行负载测试，以生成对第二台机器（或其他更复杂的Web服务基础架构）上的Web服务器的大量请求。 有很多这样的工具可用，我们稍后会看一些特定的软件。 现在，我们将讨论负载测试，无论您选择什么软件，这些都将是相关的。

负载测试软件的常见用途是找到服务器可以处理的每秒最大请求数 。 这是通过向服务器发送尽可能多的请求并查看其可以成功返回的数量来完成的。

这是理解服务器最大容量的第一步是有用的，但它并没有给我们很多关于延迟和用户体验日常性能的信息。 负载较重的服务器可能能够每秒返回一千个响应，但是如果每个响应需要十秒钟，则您的用户可能会不满意。

下图显示了吞吐量（每秒响应）和延迟之间关系的视图：

这只是一个例子，每个安装都将有一个独特的响应配置文件，但总体趋势是更高的负载（每秒更多的请求）会导致更高的延迟。 为了在给定的负载下获得更加真实的服务器延迟的想法，我们需要以不同的请求率进行多次测试。 并不是所有的负载测试软件都能够实现，但是稍后我们将讨论一个可以执行此功能的命令行负载测试工具wrk2 。

什么是合理的延迟目标？

虽然2-5秒范围内的网站加载时间是常见的，但归因于Web服务器延迟的那段时间通常在50-200毫秒左右。 什么是适合您和您的网站取决于太多的因素（您的受众，市场，网站的目的，站点用户面对或API服务等），以提供更具体的目标号码，但请记住大多数研究表明，每一点点速度，甚至“不可察觉”的改进导致更好的结果，当总体看。

现在我们对负载测试有一个一般的了解，我们来讨论一个具体的计划来探索我们服务器的性能。

负载测试计划

您可以采取一些一般步骤来了解您的服务器和Web应用程序的运行情况以及对负载的响应。 首先，我们将确保在负载测试期间监控正确的系统资源。 然后，我们将找出我们的服务器每秒能够承受的绝对最大请求数。 最后，我们会发现我们的服务器的延迟最大吞吐量会导致用户无法接受的性能。

第1步 - 监控资源

我们的负载测试软件将为我们提供有关请求和延迟的信息，但是监视其他一些系统度量值可以看到服务器在处理高流量时是否受到资源限制。

我们主要关心CPU负载和可用内存：在负载较重的情况下观察这些内容可以帮助您做出更明智的决策，了解如何扩展基础设施以及在开发应用程序时集中精力。

如果您已经设置了一个监控系统（如Prometheus或Graphite和CollectD ），那么您就可以设置好了。 如果没有，请通过SSH登录到您的Web服务器，并使用以下命令行工具实时监控。

要检查可用内存，可以使用free命令。 将其与watch周期性（默认每两秒钟）更新输出：

watch free -h

-h标志free以可读取的格式输出数字，而不是字节：

Output             total       used       free     shared    buffers     cached
Mem:          489M       261M       228M       352K       7.5M       213M
-/+ buffers/cache:        39M       450M
Swap:           0B         0B         0B

上面输出的突出显示的数字表示在减去缓冲区和缓存使用量后的空闲内存。 较新版本的free更改了输出：

Output              total        used        free      shared  buff/cache   available
Mem:           488M        182M         34M         14M        271M        260M
Swap:            0B          0B          0B

新的available列计算略有不同，但通常表示相同的度量标准：当前可用于应用程序使用的内存。

为了从命令行监视CPU使用率，mpstat是一个很好的实用工具，可以给出空闲CPU资源量的更新视图。 默认情况下，Ubuntu没有安装mpstat。 您可以使用以下命令安装它：

sudo apt-get install sysstat

当您启动mpstat您需要告诉它更新之间的秒数：

mpstat 2

这将输出一个标题行，然后每两秒输出一行统计信息：

OutputLinux 4.4.0-66-generic (example-server)     08/21/2017  _x86_64_    (4 CPU)

08:06:26 PM  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
08:06:28 PM  all    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.00
08:06:30 PM  all    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.00

%idle显示了未被使用的CPU资源的百分比。 我们看看多少空闲而不是使用多少是因为CPU利用率通常分为不同的类别，如用户 CPU和系统 CPU。 我们看看空闲的方程式，而不是在飞行中添加这些。

现在我们可以观察我们服务器的资源，让我们运行一个初始的负载测试来找到服务器的最大响应率。

第2步 - 查找最大响应速率

如前所述，大多数负载测试软件特别适用于查找Web服务器的最大响应速率。 通常，您需要设置的唯一选项是期望的并发性和测试的持续时间。

并发性是对服务器进行多少并行连接的度量。 100是一个安全的默认选择，但您可以通过检查Web服务器的MaxClients ， MaxThreads或类似设置来确定可以处理的并发连接数量，从而做出更明智的选择。

除了设置这些选项之外，还需要选择一个用于测试的URL。 如果您的软件一次只能处理一个URL，则可以使用几个不同的URL进行多个测试，因为处理要求可能会有很大差异，例如 - 您的主页和需要多个数据库查询的产品页面。

或者，一些负载测试软件允许您指定多个URL一次测试。 这是更准确地模拟真实世界流量的好方法。 如果您有现有的站点使用数据（来自分析软件或服务器日志），则可以将测试URL与观察值紧密匹配。

当您整理出要测试的URL或URL时，请运行加载测试。 确保您的软件尽可能快地发送请求。 如果您使用的软件需要您选择请求率，请选择几乎确定为过大的值。 如果您的软件在请求之间具有可配置的延迟，请将其减少到零。

您应该看到您的CPU和内存资源正在消耗。 您的CPU空闲可能达到0％，并且您的负载测试客户端可能会收到一些连接错误，因为您的服务器努力跟上所有请求。 这是正常的，因为我们将服务器推到极限。

一旦结束，您的软件将输出一些统计信息，包括每秒的请求数 。 请注意响应时间 ：它可能非常差，因为服务器应该是非常过度的。 因此，每秒请求数不是您的服务器的真实最大吞吐量的一个很好的指标，但它是进一步探索的良好起点。

接下来，我们将拨回负载并再次测试，以获取有关我们的服务器在没有被推到其绝对限制时执行的更多信息。

第3步 - 查找最大实际吞吐量

对于这一步骤，我们需要使用负载测试软件，可以在不同的吞吐量水平下检查我们的服务器的性能。 某些软件通过允许您指定每个请求之间的延迟来执行此操作，但这使得难以定位精确的吞吐量。

幸运的是， wrk2允许您指定每秒精确的请求目标。 它通过首先运行一些校准请求来获得正确的时序。

从上一步中取出您的最大请求率，并将其削减一半。 以这个新速率运行另一个测试，并记录响应时间。 是否仍在可接受范围内？

如果是的话，将速率提升到最大值，测试，直到您的延迟达到您确定为可接受的最大值。 这是您的服务器在您的用户体验性能下降之前可以处理的实际最大响应速率。

注意：如术语表中所述，当测量延迟时，您应该查看类似第99或甚至99.999百分位数的类别，以确保所有用户经常遇到的响应时间达到最大可接受的阈值。 请记住，大多数网页需要几十个请求来获取所有资源（包括图像，JavaScript，CSS文件等）并呈现页面。 如果您的网页需要十个请求完成，而您正在测量第99个百分位数，则页面加载的大约10％仍然会遇到一个具有较高延迟的请求。

接下来，我们将看一些开源软件包，以帮助我们实施我们的负载测试计划。

负载测试软件

有许多可用于负载测试的开源软件包。 此外，还有许多商业服务将为您运行负载测试基础设施，并自动从测试数据创建图表和报告。 这些服务对于需要生成大量负载来测试大型基础设施的企业来说可能是一个很好的选择，因为它们大多数运行的机器集群比单个服务器可以产生更多的请求。

也就是说，一些开源工具也能够以集群模式运行。 我们来浏览一些更受欢迎的开源工具，并总结其功能：

AB

ab（也称为ApacheBench）是一个简单的单线程命令行工具，用于对HTTP服务器进行基准测试。 尽管它最初是作为Apache HTTP Server的一部分分发的，但您可以使用ab来测试任何HTTP或HTTPS服务器。

因为它是单线程的，ab不能利用多个处理器发送大量的请求。 如果您要完全加载功能强大的Web服务器，这可能会受到限制。

ab命令的基本调用如下所示：

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

您指定请求数（ -n ）和并发（ -c ），然后为其提供一个要提取的URL。 输出 - 下面摘录 - 包含每秒请求，请求时间和不同响应时间百分位数的列表：

Output. . .
Requests per second:    734.76 [#/sec] (mean)
Time per request:       136.098 [ms] (mean)
Time per request:       1.361 [ms] (mean, across all concurrent requests)
Transfer rate:          60645.11 [Kbytes/sec] received

Percentage of the requests served within a certain time (ms)
  50%    133
  66%    135
  75%    137
  80%    139
  90%    145
  95%    149
  98%    150
  99%    151
 100%    189 (longest request)

JMeter的

JMeter是Apache Software Foundation的强大且功能丰富的负载测试和功能测试应用程序。 功能测试意味着JMeter还可以测试以确保您的网站或应用程序产生正确的输出。

JMeter有一个用于设置测试计划的Java GUI：

测试计划可以通过使用JMeter的流量记录Web代理和普通浏览器进行记录。 这样就可以测试更逼真地模拟现实世界的流量。

JMeter可以输出HTML报告和其他格式的百分位数信息。

围城

Siege是另一个命令行负载测试工具，类似于ab，但有一些不同的功能。 围攻是多线程的，可以实现相对较高的吞吐量。 它还允许您提供要进行负载测试的多个URL的列表。 一个基本的调用如下：

siege -c 100 -t 30s http://example.com/

这需要100个并发请求（ -c 100 ）和30秒的测试（ -t 30s ）。 围攻输出平均响应时间和请求率：

Output. . .
Transactions:               5810 hits
Availability:             100.00 %
Elapsed time:              29.47 secs
Data transferred:         135.13 MB
Response time:              0.01 secs
Transaction rate:         197.15 trans/sec
Throughput:             4.59 MB/sec
Concurrency:                2.23
. . .

Siege不提供其延迟统计数据的百分点细分。

刺槐

Locust是一个基于Python的负载测试工具，具有用于监视结果的实时Web UI：

您可以在Python代码中编写Locust测试场景，允许一些强大的配置，方便那些已经熟悉该语言的用户。

蝗虫也可以以分布式模式运行，您可以在其中运行一组蝗虫服务器，并使它们以协调的方式产生负载。 这有助于强大的Web服务基础架构的负载测试。

Locust可以在可下载的CSV文件中提供详细的统计信息和百分位数信息。

wrk2

wrk2是一个多线程命令行负载测试工具，能够以指定的请求速率产生负载。 它可以提供详细的延迟统计信息，并且可以使用Lua编程语言编写脚本。

wrk2用wrk命令调用（它是原始wrk的一个fork）：

wrk -t4 -c100 -d30s -R100 --latency http://example.com/

上述选项指定四个线程（ -t4 ，您应该使用计算机上的处理器核心数），100个并发请求（ -c100 ），30秒测试周期（ -d30s ）和每秒100个请求的请求速率（ -R100 ）。 最后，我们以--latency请求详细的延迟输出：

Output. . .
Latency Distribution (HdrHistogram - Recorded Latency)
50.000%    5.79ms
75.000%    7.58ms
90.000%   10.19ms
99.000%   29.30ms
99.900%   30.69ms
99.990%   31.36ms
99.999%   31.36ms
100.000%   31.36ms
. . .

上面的输出是摘录 - 更详细的延迟百分比也被打印出来。

结论

在本文中，我们回顾了一些负载测试术语和基本概念，逐步通过计划找到我们每秒最大的实际请求，观察系统资源，以指导未来有关硬件和开发工作的决策，并查看一些可用的开源负载测试软件。

测量基础架构的性能后，您可能希望对此信息采取行动，以尝试改善响应时间并减少服务器负载。 您可能希望通过多台服务器和负载均衡器来扩展Web服务器硬件。 您可能会尝试微调您的Web服务器配置，以优化其允许的连接数或使用的工作进程或线程数。 您还可以查看缓存内存中经常访问的数据，以减少数据库负载和查询时间。

您将在我们收集的服务器优化标签教程中找到上述主题和更多内容。