应用负载均衡器后端服务的负载测试准则

将后端服务与应用负载均衡器集成时，请务必在没有负载均衡器的情况下单独衡量后端服务的性能。在受控条件下执行负载测试有助于您评估不同维度的性能（例如吞吐量和延迟时间）之间的容量规划权衡取舍。由于细致的容量规划可能仍然低估实际需求，因此我们建议您使用负载测试主动确定系统过载时服务可用性受到的影响。

负载测试目标

典型的负载测试衡量在不同维度的负载下后端服务的外部可见行为。此测试的一些最相关的维度如下：

  • 请求吞吐量：每秒处理的请求数。
  • 请求并发数：并发处理的请求数量。
  • 连接吞吐量：客户端每秒启动的连接数。大多数使用传输层安全协议 (TLS) 的服务具有一些与每个连接相关而与请求处理无关的网络传输和 TLS 协商开销。

  • 连接并发数：并发处理的客户端连接数。

  • 请求延迟时间：从请求开始到响应结束的总时间。

  • 错误率：请求导致错误（例如 HTTP 5xx 错误和过早关闭连接）的频率。

如需评估服务器在负载下的运行状况，负载测试过程还可能会收集以下内部服务指标：

  • 系统资源的使用情况：CPU、RAM 和文件句柄（套接字）等系统资源（通常以百分比表示）。

    这些指标的重要性因服务的实现方式而异。应用在资源耗尽时会出现性能下降、脱载或崩溃的情况。因此，当主机处于高负载时，必须确定资源的供应情况。

  • 使用其他有限资源：可能在负载下（例如，在应用层）耗尽的非系统资源。

    此类资源的一些示例包括：

    • 有限的工作器线程或进程池。
    • 对于使用线程的应用服务器，通常会限制并发运行的工作器线程数。线程池大小限额对于防止内存和 CPU 耗尽非常有用，但默认设置通常非常保守。限额过低可能会阻止系统资源得到充分使用。
    • 某些服务器会使用进程池，而不是线程池。例如，使用 Prefork 多处理模型设置的 Apache 服务器会为每个客户端连接分配一个进程。因此，池的大小限额决定了连接并发数的上限。
    • 作为前端部署到其他服务的服务具有大小有限的后端连接池。

容量规划与过载测试

负载测试工具可帮助您单独衡量不同的扩缩维度。 对于容量规划，请确定多个维度的可接受性能的负载阈值。例如，请考虑衡量以下各项，而不是衡量服务请求吞吐量的绝对限额：

  • 服务能以小于指定毫秒数的第 99 百分位数延迟时间提供服务的请求速率。该编号由服务的 SLO 指定。
  • 不会导致系统资源利用率超过最佳水平的请求速率上限。请注意，最佳利用率因应用而异，并且可能远远低于 100%。例如，峰值内存利用率在 80% 时，应用可能比峰值利用率为 99% 时更好地处理次要负载峰值。

虽然使用负载测试结果来做出容量规划决策非常重要，但了解服务在负载超过容量时的行为方式同样很重要。通常使用过载测试评估的某些服务器行为如下：

  • 减载：当服务收到过多传入请求或连接时，可能会减慢所有请求的速度，或者拒绝某些请求来保持其余请求的可接受性能。我们建议使用后一种方法，以防止在接收响应之前出现客户端超时，并通过降低服务器上的请求并发数来降低内存耗尽风险。

  • 应对资源耗尽的恢复能力：服务通常会避免因资源耗尽而崩溃，因为待处理请求在服务崩溃时很难取得进一步进展。如果后端服务有许多实例，则单个实例的稳健性对于服务的总体可用性至关重要。当实例从崩溃中重启时，其他实例可能会遇到更多负载，从而可能导致级联故障。

常规测试指南

定义测试用例时，请考虑以下准则。

创建小规模测试

创建小规模测试来衡量服务器的性能限制。在服务器容量过大的情况下，测试有可能无法揭示服务本身的性能极限，但可能会发现其他系统（如客户主机或网络层）的瓶颈。

为获得最佳结果，请考虑使用单个虚拟机实例或 Google Kubernetes Engine (GKE) Pod 来独立测试服务的测试用例。如需在服务器上实现完整负载，必要时您可以使用多个虚拟机，但请记住，它们可能会使性能数据的收集变得复杂。

选择开环负载模式

大多数负载生成器使用闭环模式来限制并发请求的数量，并将新请求推迟到上一个请求完成为止。我们不推荐使用这种方法，因为服务的生产客户端可能不会表现出此类限制行为。

相比之下，开环模式能让负载生成器以稳定的速率发送请求，模拟生产负载，而不受服务器响应到达速率的影响。

我们建议对后端服务的负载测试使用以下负载生成器：

Nighthawk

Nighthawk 是与 Envoy 项目协调开发的开源工具。您可以用它来生成客户端负载、直观呈现基准测试并测量 HTTPS 服务大多数负载测试场景的服务器性能。

测试 HTTP/1

如需测试 HTTP/1，请使用以下命令：

nighthawk_client URI \
    --duration DURATION \
    --open-loop \
    --no-default-failure-predicates \
    --protocol http1 \
    --request-body-size REQ_BODY_SIZE \
    --concurrency CONCURRENCY \
    --rps RPS \
    --connections CONNECTIONS

请替换以下内容：

  • URI：要进行基准测试的 URI
  • DURATION：总测试运行时间，以秒为单位
  • REQ_BODY_SIZE：每个请求中 POST 载荷的大小

  • CONCURRENCY：并发事件循环总数

    此数字应与客户端虚拟机的核心数匹配

  • RPS：每个事件循环每秒的目标请求速率

  • CONNECTIONS：每个事件循环的并发连接数

请参阅以下示例：

nighthawk_client http://10.20.30.40:80 \
    --duration 600 --open-loop --no-default-failure-predicates \
    --protocol http1 --request-body-size 5000 \
    --concurrency 16 --rps 500 --connections 200

每个测试运行的输出都会提供一个响应延迟时间直方图。请注意，在 Nighthawk 文档的示例中，第 99 百分位的延迟时间约为 135 微秒。

Initiation to completion
    samples: 9992
    mean:    0s 000ms 113us
    pstdev:  0s 000ms 061us

    Percentile  Count       Latency
    0           1           0s 000ms 077us
    0.5         4996        0s 000ms 115us
    0.75        7495        0s 000ms 118us
    0.8         7998        0s 000ms 118us
    0.9         8993        0s 000ms 121us
    0.95        9493        0s 000ms 124us
    0.990625    9899        0s 000ms 135us
    0.999023    9983        0s 000ms 588us
    1           9992        0s 004ms 090us

测试 HTTP/2

如需测试 HTTP/2，请使用以下命令：

nighthawk_client URI \
    --duration DURATION \
    --open-loop \
    --no-default-failure-predicates \
    --protocol http2 \
    --request-body-size REQ_BODY_SIZE \
    --concurrency CONCURRENCY \
    --rps RPS \
    --max-active-requests MAX_ACTIVE_REQUESTS \
    --max-concurrent-streams MAX_CONCURRENT_STREAMS

请替换以下内容：

  • URI：要进行基准测试的 URI
  • DURATION：总测试运行时间，以秒为单位
  • REQ_BODY_SIZE：每个请求中 POST 载荷的大小

  • CONCURRENCY：并发事件循环总数

    此数字应与客户端虚拟机的核心数匹配

  • RPS：每个事件循环每秒的目标速率

  • MAX_ACTIVE_REQUESTS：每个事件循环的并发活动请求数上限

  • MAX_CONCURRENT_STREAMS：每个 HTTP/2 连接上允许的并发流数上限

请参阅以下示例：

nighthawk_client http://10.20.30.40:80 \
    --duration 600 --open-loop --no-default-failure-predicates \
    --protocol http2 --request-body-size 5000 \
    --concurrency 16 --rps 500 \
    --max-active-requests 200 --max-concurrent-streams 1

ab（Apache 基准测试工具）

ab 是 Nighthawk 没那么灵活的替代方案，但几乎每个 Linux 发行版都以软件包的形式提供了它。建议将 ab 仅用于快速简单的测试。

如需安装 ab，请使用以下命令：

  • 在 Debian 和 Ubuntu 上，运行 sudo apt-get install apache2-utils。
  • 在基于 RedHat 的发行版上，运行 sudo yum install httpd-utils。

安装 ab 后，请使用以下命令运行它：

ab -c CONCURRENCY \
    -n NUM_REQUESTS \
    -t TIMELIMIT \
    -p POST_FILE URI

请替换以下内容：

  • CONCURRENCY：要执行的并发请求数
  • NUM_REQUESTS：要执行的请求数
  • TIMELIMIT：在请求上花费的秒数上限
  • POST_FILE：包含 HTTP POST 载荷的本地文件
  • URI：要进行基准测试的 URI

请参阅以下示例：

ab -c 200 -n 1000000 -t 600 -P body http://10.20.30.40:80

上述示例中的命令以 200 的并发量（闭环模式）发送请求，并在发送 1,000,000（100 万）个请求或经过 600 秒后停止。该命令还包含文件 body 的内容作为 HTTP POST 载荷。

ab 命令与 Nighthawk 一样，会生成类似的响应延迟时间直方图，但其分辨率限制为毫秒，而不是微秒：

Percentage of the requests served within a certain time (ms)
    50%     7
    66%     7
    75%     7
    80%     7
    90%    92
    95%   121
    98%   123
    99%   127
    100%  156 (longest request)

后续步骤