# パフォーマンスデータ
Virtual Waiting Room on AWS の負荷テストには、[Locust](https://locust.io/) というツールを使用しました。シミュレート対象のイベントサイズは、10,000～100,000 クライアントです。負荷テストの環境は、次の設定で構成されていました。
+ AWS クラウドのデプロイ用にカスタマイズされた Locust 2.x
+ 4 つの AWS リージョン (`us-west-1`、`us-west-2`、`us-east-1`、`us-east-2`）
+ 1 つのリージョンにつき 10 の `c5.4xlarge` Amazon EC2 ホスト (合計 40)
+ 1 つのホストにつき 32 の Locust プロセス
+ シミュレート対象のユーザーは 1,280 のプロセスに均等に分散
各ユーザーのプロセスで実施したエンドツーエンドの API テストの手順:
1. `assign_queue_num` を呼び出し、リクエスト ID を受け取る。
1. リクエスト ID で、ユーザーのキュー位置が返されるまで `queue_num` のループを実行する (短時間)。
1. 戻り値がユーザーのキュー位置以上になるまで `serving_num` のループを実行する (長時間)。
1. `waiting_room_size` を低頻度で呼び出して、待機中のユーザー数を取得する。
1. `generate_token` を呼び出して、ターゲットサイトで使用する JWT を受け取る。
## 結果
実質的には、待合室で処理できるクライアントの数に上限はありません。
ユーザーが待合室に入るレートは、デプロイされているリージョンにおける Lambda 関数の同時実行クォータに影響します。
ロードテストでは、CloudFront で使用されたキャッシュポリシーにより、デフォルトの API Gateway リクエスト制限である 1 秒あたり 10,000 リクエストを超えることはできませんでした。
`get_queue_num` Lambda 関数の呼び出しレートは、待合室に入るユーザーのレートと比較して、ほぼ 1 対 1 になります。この Lambda 関数は、同時実行数制限またはバースト制限により、入るユーザーのレートが高くなるとスロットリングされることがあります。`get_queue_num` Lambda 関数の呼び出し数が多いためにスロットリングが発生すると、副作用として他の Lambda 関数に影響する可能性があります。このタイプの一時的なスケーリングエラーが生じた際においても、クライアントソフトウェアが再試行またはバックオフロジックで適切に対応できる場合では、システム全体の動作が継続されます。
コアスタックによって設定された CloudFront ディストリビューションでは、デフォルトのクォータ設定において、各ユーザーが少なくとも毎秒 `serving_num` API をポーリングする前提で、250,000 ユーザーを収容する待合室を処理できます。