このチュートリアルでは、負荷に対する Waiting Room の動作をテストします。負荷テストで Waiting Room を通過するトラフィックを正確にシミュレートするには、テストスクリプトまたはプランナーを 1 分より長く、できれば 2〜3 分以上実行します。loader.io ↗、jmeter ↗、postman.com ↗ など、さまざまなツールで負荷テストを実行できます。ユーザーリクエスト（それぞれが別のユーザーを表す）をシミュレートする単純なシェルスクリプトを書くこともできます。
このチュートリアルを始める前に、次を確認してください。
- Waiting Room の 概要 ページを確認していること。
- このチュートリアルでは、Apache のオープンソースツール JMeter ↗ を使います。バイナリは JMeter のサイト ↗ からダウンロードできます。
まず、GitHub から サンプル ↗ の JMeter プラン（設定ファイル）をダウンロードします。
このサンプルプランは、200 人のアクティブユーザーがサイトを訪れる状況をシミュレートします。最初の 1 分でトラフィックをゆっくり増やし、その後 3 分間は 200 人のアクティブユーザーを維持します。このチュートリアルのテストプランは、次の手順で説明する構成に従います。
サンプルプランを実行する前に、テストプラン内の Waiting Room を自分の Waiting Room を指すように編集します。
- Waiting Room Simulation を選択してテストプランを展開し、Request origin with waiting room を選択してテスト設定を更新します。
- HTTP Request セクションで、Protocol、Server Name or IP、Path フィールドを、Waiting Room を有効にしたテスト URL を指すように更新します。たとえば、完全な URL が
https://www.example.com/deals/summerの場合、各フィールドは次のようになります。
| フィールド | 値 |
|---|---|
| Protocol | https |
| Server Name or IP | www.example.com ↗ |
| Path | deals/summer |
次に、play ボタンを選択してテストを開始します。所要時間はおよそ 3〜4 分です。
- シミュレートされる各ユーザーには、次の属性があります。
- Cookie を保持する Cookie jar を持ちます。
- 20 回繰り返します。
- Waiting Room を有効にしたオリジンサイトへリクエストします。
- リクエストの詳細を記録します。
- 10 秒待機してからページを更新し、オリジンサイトへ再度リクエストします。
上記のプランでは、各 Thread Group ↗ がこの操作を 1 回実行します。ユーザートラフィックは最初の 1 分で増加し、その後 3 分間は一定のトラフィックを維持してからサイトを離れます。これらのプロパティを更新すると、この例より多い、または少ないトラフィックを送れます。
テスト結果を分析するには、Cloudflare の GraphQL API で Waiting Room Analytics（Beta）を照会し、負荷テストの各分について Total Active Users と Queued Users を確認できます。
curl の例
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
最初の 1 分（15:35:00 UTC）では、Waiting Room を通過したアクティブユーザーは 137 人です。トラフィックを最初の 1 分で徐々に増やす設定にしており、テスト開始がちょうど分の境界ではなかったためです。次の 1 分（15:36:00 UTC）にデータが集計されると、各「ユーザー」がサブリクエストを行った結果、Waiting Room はサイト上で想定どおり 200 人のアクティブユーザーを報告しました。負荷テストから送ったトラフィックのサブリクエストを受け続けている限り、アクティブユーザー数は 200 で安定しました。