コンテンツにスキップ

待機室のテスト

このチュートリアルに従って、負荷に対する待機室の動作をテストします。待機室を通過するトラフィックを正確にシミュレートするために、テストスクリプトまたはプランナーを1分以上、理想的には2〜3分以上実行してください。さまざまなツールを使用して負荷テストを実行できます。例えば、loader.iojmeterpostman.comなどです。また、ユーザーリクエストをシミュレートするためのプレーンシェルスクリプトを書くこともできます(各リクエストは異なるユーザーを表します)。


始める前に

このチュートリアルを始める前に、次のことを確認してください:


1. サンプルスクリプトをダウンロード

まず、GitHubからサンプルのJMeterプラン(設定ファイル)をダウンロードします。

このサンプルプランは、200人のアクティブユーザーがサイトを訪問する様子をシミュレートし、最初の1分間でトラフィックを徐々に増加させ、その後3分間200人のアクティブユーザーを維持します。このチュートリアルのテストプランは、次のステップで説明するセットアップに従います。

2. サンプルプランを編集して実行

サンプルプランを実行する前に、テストプラン内の待機室を自分の待機室を指すように編集します。

  1. 待機室シミュレーションを選択してテストプランを展開し、次に待機室付きのリクエスト元を選択してテスト設定を更新します。

待機室シミュレーションパネルでリクエスト元を選択

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

HTTPリクエストセクションを更新

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

再生ボタンを選択

  • 各シミュレートされたユーザーには次の属性があります:

    • クッキーの持続性のためのクッキージャーを含む。

    • 20回繰り返す。

      • 待機室が有効なオリジンサイトにリクエストを送信します。
      • リクエストの詳細をログに記録します。
      • ページをリフレッシュしてオリジンサイトに別のリクエストを送信する前に10秒間待機します。

ユーザー属性

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

スレッド数の視覚化

3. 結果を分析

テストの結果を分析するには、CloudflareのGraphQL APIを介して待機室分析(ベータ版)をクエリして、負荷テストの各分の総アクティブユーザーとキューに入っているユーザーを確認できます。

例 Curl ステートメント

Terminal window
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のまま安定していました。