待機室のテスト
このチュートリアルに従って、負荷に対する待機室の動作をテストします。待機室を通過するトラフィックを正確にシミュレートするために、テストスクリプトまたはプランナーを1分以上、理想的には2〜3分以上実行してください。さまざまなツールを使用して負荷テストを実行できます。例えば、loader.io ↗、jmeter ↗、postman.com ↗などです。また、ユーザーリクエストをシミュレートするためのプレーンシェルスクリプトを書くこともできます(各リクエストは異なるユーザーを表します)。
このチュートリアルを始める前に、次のことを確認してください:
- すべての前提条件が完了していること。
- このチュートリアルでは、ApacheのオープンソースツールであるJMeter ↗を使用します。バイナリはJMeterのウェブサイト ↗からダウンロードできます。
まず、GitHubからサンプル ↗のJMeterプラン(設定ファイル)をダウンロードします。
このサンプルプランは、200人のアクティブユーザーがサイトを訪問する様子をシミュレートし、最初の1分間でトラフィックを徐々に増加させ、その後3分間200人のアクティブユーザーを維持します。このチュートリアルのテストプランは、次のステップで説明するセットアップに従います。
サンプルプランを実行する前に、テストプラン内の待機室を自分の待機室を指すように編集します。
- 待機室シミュレーションを選択してテストプランを展開し、次に待機室付きのリクエスト元を選択してテスト設定を更新します。

- HTTPリクエストセクションで、プロトコル、サーバー名またはIP、およびパスフィールドを、待機室が有効なテストURLを指すように更新します。たとえば、完全なURLが
https://www.example.com/deals/summerの場合、フィールドは次のように一致する必要があります:
| フィールド | 値 |
|---|---|
| プロトコル | https |
| サーバー名またはIP | www.example.com ↗ |
| パス | deals/summer |

次に、再生ボタンを選択してテストを開始します。これには約3〜4分かかります。

-
各シミュレートされたユーザーには次の属性があります:
-
クッキーの持続性のためのクッキージャーを含む。
-
20回繰り返す。
- 待機室が有効なオリジンサイトにリクエストを送信します。
- リクエストの詳細をログに記録します。
- ページをリフレッシュしてオリジンサイトに別のリクエストを送信する前に10秒間待機します。
-

上記のプランに従って、各スレッドグループ ↗は上記のアクションを1回実行します。ユーザートラフィックは最初の1分間で増加し、次の3分間は持続的なトラフィックを維持します。その後、ユーザーはサイトを離れます。この例で送信されているトラフィックよりも多くまたは少なくトラフィックを送信するには、これらのプロパティを更新できます。

テストの結果を分析するには、CloudflareのGraphQL APIを介して待機室分析(ベータ版)をクエリして、負荷テストの各分の総アクティブユーザーとキューに入っているユーザーを確認できます。
例 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では、137人のアクティブユーザーが待機室を通過したことが示されています。これは、トラフィックが最初の1分間で徐々に増加するように設定されており、テストが正確に分のマークで開始されなかったためです。次の分のデータが集計されると、15:36:00 UTCでは、待機室がサイト上で期待される200人のアクティブユーザーを報告しました。各「ユーザー」がサブリクエストを行ったためです。アクティブユーザーのカウントは、負荷テストによって送信されたトラフィックからサブリクエストを受け取る限り、200のまま安定していました。