Webサーバーを壊して、大量のHTTPリクエストで埋めます。ゆっくりとすべてをHTTPフラッドで満たし、完全な劣化を観察します。Azureの準備をしてください。笑い事はありません！
もう少し真剣に考えると、AZ-900の一部としてAzureに精通した標準ラボを実行しているときに、Microsoft Azure Fundamentalsは、標準B1仮想マシン（1 GiB RAM、1 vCPU）の最小構成の1つで何ができるかを確認することにしました。
標準的なラボでは、ApacheやIISなどのWebサーバーが仮想マシンにインストールされ、単純なサイトが起動され、ここですべてが終了します。そのような知人では不十分であるように思われ、サーバーが多数の要求にどのように応答するか、応答時間はどうなるか、そして最も重要なことに、仮想マシンのサイズを変更するとどうなるかを見るのが面白くなりました。仕事の質を向上させるのに役立ちます。さらに、サーバーに心配事を追加するために、WordPress（Apache、MySQL、PHP）がUbuntuを備えた仮想マシンで起動されました。テストでは、同じアドレスへのGETリクエストを継続的に生成するPythonスクリプトが使用されました。
単一の要求の場合、サーバーの応答時間は300〜400ミリ秒を超えませんでした。これは、このような構成では非常に許容できるように見えました。
もう1つは、GETがバッチで到着したときに、サーバーがバルク要求にどのように反応するかです。Pythonでは、このような並列リクエストは、非同期呼び出し用の高レベルインターフェイスへのアクセスを提供する「concurrent.futures」モジュールを使用して実装できます。実装のアイデアは、creativedata.streamリソースに触発されました 。その結果、テストでは、サーバーはGETリクエストの波に襲われ、同時リクエストの数は直線的に増加しました。わかりやすくするために、各リクエストの応答時間は10秒に制限されています。試行ごとに、5000件のリクエストが送信されました。試行の間に3分のタイムアウトがあります。
VM標準B1のテスト結果を表に示します。
並列GETリクエストの数 |
テスト時間（秒） |
平均応答時間（秒） |
最大応答時間（秒） |
拒否の数 |
十 |
246 |
0.482504 |
1.393406 |
0 |
20 |
183 |
0.716227 |
1.775027 |
0 |
30 |
158 |
0.925803 |
2.239563 |
0 |
40 |
133 |
1.028995 |
10.389413 |
4773 |
40 , , “200” 100%.
. . .
, . B1s Standard B2s (4GiB RAM, 2 vCPU). ?
, . 10000.
VM Standard B2s
- GET |
() |
() |
() |
|
20 |
198 |
0.387310 |
1.377070 |
0 |
40 |
171 |
0.660414 |
1.481950 |
0 |
60 |
140 |
0.808657 |
1.674038 |
0 |
80 |
130 |
1.001915 |
2.142157 |
0 |
100 |
119 |
1.163476 |
2.252231 |
0 |
120 |
119 |
1.417223 |
2.703418 |
0 |
140 |
119 |
1.654639 |
2.98774 |
0 |
160 |
119 |
1.901040 |
5.622294 |
0 |
. , . , .
160 5Mb/s .
結論の
余地HTTPフラッドと現在の実装を使用したこのテストは、スペースを征服し、ゴールドスタンダードに従うふりをしていません。ただし、テストでは、同時要求の数とCPU、メモリの負荷、および平均応答時間と最大応答時間の間に予想される直接的な関係が示されました。
どうやら、大量のRAM（4Gb対1Gb）を備えたサーバーは、この種の負荷にうまく対処し、要求数が5倍（160対30）になっても、定期的に200OKで応答します。
PS
テストユーティリティの例は、githubのリポジトリにあります。