测试等候室

按照本教程测试您的等候室在负载情况下的行为。要通过负载测试准确模拟通过等候室的流量，请运行您的测试脚本或计划器超过一分钟的时间，理想情况下超过 2-3 分钟。您可以使用各种工具运行负载测试，包括 loader.io ↗、jmeter ↗ 和 postman.com ↗。您还可以编写一个简单的 shell 脚本来模拟用户请求（每个请求代表一个不同的用户）。

在开始本教程之前，请确保您已经：

• 查阅了等候室关于页面。
• 在本教程中，我们将使用 Apache 的开源工具 JMeter ↗。您可以从 JMeter 的网站 ↗下载二进制文件。

首先，从 GitHub 下载示例 ↗ JMeter 计划（配置文件）。

此示例计划模拟 200 个活动用户访问该网站，在第一分钟内慢慢增加流量，然后在接下来的三分钟内维持 200 个活动用户。本教程的测试计划遵循后续步骤中概述的设置。

在运行示例计划之前，请编辑测试计划中的等候室，使其指向您自己的等候室。

1. 选择 Waiting Room Simulation（等候室模拟） 以展开测试计划，然后选择 Request origin with waiting room（使用等候室请求源站） 以更新测试配置。

2. 在 HTTP Request（HTTP 请求） 部分，更新 Protocol（协议）、Server Name or IP（服务器名称或 IP） 和 Path（路径） 字段，使其指向启用了等候室的测试 URL。例如，如果您的完整 URL 看起来像 https://www.example.com/deals/summer，则字段应匹配如下：

然后，选择 **play（播放）**按钮以开始测试。这大约需要 3-4 分钟。

• 每个模拟用户具有以下属性：
  • 包含用于 cookie 持久性的 Cookie jar。
  • 重复 20 次。
    • 向启用了等候室的源站点发出请求。
    • 记录请求详细信息。
    • 暂停 10 秒钟，然后刷新页面以向源站点发出另一个请求。

根据上面的计划，每个 Thread Group（线程组） ↗执行一次上述操作。用户流量在第一分钟内增加，并在接下来的三分钟内保持持续流量，然后用户离开站点。通过更新这些属性，您可以发送比此示例中发送的更多或更少的流量。

要分析测试结果，您可以通过 Cloudflare 的 GraphQL API 查询等候室分析 (Waiting Room Analytics)（测试版），以检查负载测试中每一分钟的 Total Active Users（活动用户总数）和 Queued Users（排队用户数）。

echo '{
  "operationName": "UsersQueuedOverTimeQuery",
  "variables": {
    "filter": {
      "datetime_geq": "2022-10-17T15:34:00Z",
      "datetime_leq": "2022-10-17T15:40:00Z",
      "waitingRoomId": "<YOUR_WAITING_ROOM_ID>"
    },
    "zoneId": "<YOUR_ZONE_ID>"
  },
  "query": "query UsersQueuedOverTimeQuery($zoneId: string, $filter: ZoneWaitingRoomAnalyticsAdaptiveGroupsFilter_InputObject) {\n  viewer {\n    zones(filter: {zoneTag: $zoneId}) {\n      timeseries: waitingRoomAnalyticsAdaptiveGroups(limit: 5000, filter: $filter, orderBy: [datetimeMinute_ASC]) {\n        avg {\n          totalActiveUsers\n          totalActiveUsersConfig\n          totalQueuedUsers\n          __typename\n        }\n        max {\n          totalQueuedUsers\n          totalActiveUsers\n          totalActiveUsersConfig\n          __typename\n        }\n        min {\n          totalActiveUsersConfig\n          __typename\n        }\n        dimensions {\n          ts: datetimeMinute\n          __typename\n        }\n        __typename\n      }\n      total: waitingRoomAnalyticsAdaptiveGroups(limit: 1, filter: $filter) {\n        max {\n          totalQueuedUsers\n          totalActiveUsers\n          __typename\n        }\n        __typename\n      }\n      __typename\n    }\n    __typename\n  }\n}\n"
}' | tr -d '\n' | curl \
  -X POST

从我们的测试中，我们得到了以下结果（为了便于阅读，这些是从查询结果中提取的）：

• 15:35:00 UTC

  • "totalActiveUsers": 137,
  • "totalActiveUsersConfig": 300,
  • "totalQueuedUsers": 0

• 15:36:00 UTC

  • "totalActiveUsers": 200,
  • "totalActiveUsersConfig": 300,
  • "totalQueuedUsers": 0

• 15:37:00 UTC

  • "totalActiveUsers": 200,
  • "totalActiveUsersConfig": 300,
  • "totalQueuedUsers": 0

• 15:38:00 UTC

  • "totalActiveUsers": 200,
  • "totalActiveUsersConfig": 300,
  • "totalQueuedUsers": 0

第一分钟标记 15:35:00 UTC 显示有 137 个活动用户通过了等候室。这是因为我们的流量设置为在第一分钟内逐渐增加，而且测试并没有完全在分钟标记处开始。当聚合下一分钟（15:36:00 UTC）的数据时，随着每个“用户”发出子请求，等候室报告了我们在站点上预期的总共 200 个活动用户。只要从负载测试发送的流量接收到子请求，活动用户数就保持稳定在 200。