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

Otestujte waiting room

Podle tohoto návodu otestujte chování čekárny při zátěži. Abyste zátěžovým testem přesně simulovali provoz procházející čekárnou, spusťte testovací skript nebo plánovač po dobu delší než jednu minutu, ideálně déle než 2 až 3 minuty. Zátěžový test můžete spustit pomocí různých nástrojů, například loader.io ↗, jmeter ↗, a postman.com ↗. Můžete také napsat jednoduchý shellový skript, který bude simulovat požadavky uživatelů (každý představuje jednoho unikátního uživatele).

Než začnete s tímto návodem, ujistěte se, že máte:

• Zkontrolovali jsme O službě stránka čekárny.
• V tomto návodu použijeme open source nástroj od Apache, JMeter ↗. Binární soubor si můžete stáhnout z web JMeter ↗.

Nejprve si stáhněte vzorek ↗ plán JMeter (konfigurační soubor) z GitHubu.

Tento vzorový plán simuluje 200 aktivních uživatelů, kteří navštěvují web. Provoz se během první minuty postupně zvyšuje a poté zůstává na 200 aktivních uživatelích po dobu dalších tří minut. Testovací plán pro tento tutoriál odpovídá nastavení popsanému v následujících krocích.

Před spuštěním ukázkového plánu upravte v testovacím plánu čekárnu tak, aby odkazovala na vaši vlastní čekárnu.

1. Vyberte Waiting Room Simulation a rozbalte plán testu, poté vyberte Požadavek na origin server s čekárnou a aktualizujte konfiguraci testu.

2. V HTTP Request aktualizujte Protokol, Server Name or IP, a Cesta polí tak, aby ukazovala na vaši testovací URL adresu s povolenou čekárnou. Pokud například vaše úplná URL adresa vypadá takto https://www.example.com/deals/summer, pak by se pole měla shodovat následovně:

Poté vyberte spustit tlačítko, čímž test spustíte. Mělo by to trvat zhruba 3 až 4 minuty.

• Každý simulovaný uživatel má následující atributy:
  • Obsahuje CookieJar pro perzistenci souborů cookie.
  • 20krát se opakuje.
    • Odesílá požadavek na původní web s povolenou čekárnou.
    • Zaznamenává podrobnosti požadavku.
    • Před obnovením stránky a odesláním dalšího požadavku na origin server počká 10 sekund.

Podle výše uvedeného plánu každý Thread Group ↗ provede výše uvedenou akci jednou. Provoz uživatelů se během první minuty zvyšuje a po dobu dalších tří minut zůstává na stálé úrovni, než uživatelé web opustí. Množství provozu odesílaného v tomto příkladu můžete upravit změnou těchto vlastností.

Chcete-li analyzovat výsledky testu, můžete pomocí Cloudflare GraphQL API dotazovat Waiting Room Analytics (Beta) a zjistit hodnoty Total Active Users a Queued Users pro každou minutu zátěžového testu.

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

Z našeho testu jsme získali následující výsledky (jsou extrahovány z výsledků dotazu pro přehlednost):

• 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

První minutová značka, 15:35:00 UTC, ukazuje 137 aktivních uživatelů, kteří prošli waiting roomem. Je to proto, že náš provoz byl nastaven tak, aby se během první minuty postupně navyšoval, a test nezačal přesně na této minutové značce. Když byla data agregována za následující minutu, 15:36:00 UTC, waiting room nahlásil celkových 200 aktivních uživatelů, které jsme na webu očekávali, jelikož každý „uživatel“ generoval podpožadavky. Počet aktivních uživatelů zůstal stabilní na hodnotě 200, dokud přicházely podpožadavky z provozu generovaného zátěžovým testem.