← Cloudflare Waiting Room / waiting-room / additional-options

Проверка зала ожидания

Следуйте этому руководству, чтобы проверить поведение зала ожидания под нагрузкой. Для точной имитации трафика через зал ожидания в нагрузочном тесте запускайте тестовый скрипт или планировщик дольше одной минуты, желательно более 2-3 минут. Провести нагрузочное тестирование можно с помощью различных инструментов, включая loader.io ↗, jmeter ↗, а также postman.com ↗. Вы также можете написать простой shell-скрипт для имитации запросов пользователей, где каждый запрос представляет отдельного пользователя.

Прежде чем приступить к этому руководству, убедитесь, что у вас есть:

• Проверили Обзор страница Waiting Room.
• В этом руководстве мы будем использовать инструмент с открытым исходным кодом от Apache, JMeter ↗. Скачать бинарный файл можно сайт JMeter ↗.

Сначала скачайте выборка ↗ план JMeter (файл конфигурации) с GitHub.

Этот пример плана имитирует 200 активных пользователей, посещающих сайт: трафик плавно нарастает в течение первой минуты, а затем в течение следующих трёх минут удерживается на уровне 200 активных пользователей. Тестовый план в этом руководстве соответствует настройке, описанной в следующих шагах.

Перед запуском примера плана отредактируйте зал ожидания в тестовом плане так, чтобы он указывал на ваш собственный зал ожидания.

1. Выберите Имитация Waiting Room чтобы развернуть тестовый план, а затем выберите Запрос к источнику при использовании зала ожидания чтобы обновить конфигурацию теста.

2. В HTTP Request разделе обновите Протокол, Server Name or IP, а также Путь поля, чтобы указать на тестовый URL с включённым залом ожидания. Например, если полный URL выглядит так: https://www.example.com/deals/summer, в этом случае поля должны соответствовать следующему:

Затем выберите воспроизвести кнопку, чтобы запустить тест. Это должно занять примерно 3-4 минуты.

• Каждый смоделированный пользователь обладает следующими атрибутами:
  • Содержит CookieJar для сохранения cookie между запросами.
  • Повторяется 20 раз.
    • Отправляет запрос к сайту-источнику при включённом зале ожидания.
    • Записывает подробности запроса в журнал.
    • Приостанавливается на 10 секунд, а затем обновляет страницу, чтобы отправить новый запрос к исходному сайту.

Согласно приведённому выше плану, каждый Thread Group ↗ выполняет указанное выше действие один раз. Трафик пользователей нарастает в течение первой минуты и остаётся стабильным следующие три минуты, после чего пользователи покидают сайт. Вы можете отправлять больше или меньше трафика, чем в этом примере, изменяя эти параметры.

Чтобы проанализировать результаты теста, вы можете запросить данные Waiting Room Analytics (Beta) через GraphQL API Cloudflare и проверить значения 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, пока продолжали поступать подзапросы от трафика нагрузочного теста.