はじめに
Azure Web Apps で、メンテナンスページや、ソーリーページを表示する際に、どのレベルのインスタンスを、何台用意すればいいのか調べたくてパフォーマンス計測しました
計測方法
表示するページは画像無し、独立したCSSファイル無しのHTMLのみ13KBのファイルを使用。ab で同時接続200、10万回リクエストした際のパフォーマンスを計測
結果
| プラン | インスタンス数 | Requests per second | Time per request | Transfer rate |
|---|---|---|---|---|
| D1 (Shared) | 5214.99 | 38.351 | 66847.56 | |
| S1 (Standard) | 1 | 4017.83 | 49.778 | 51501.96 |
| S2 (Standard) | 1 | 4677.41 | 42.759 | 59956.67 |
| S3 (Standard) | 1 | 5326.19 | 37.55 | 68273.04 |
| P1V2 (Premium) | 1 | 4212.95 | 47.473 | 54003.07 |
| P3V2 (Premium) | 1 | 5454.53 | 36.667 | 69918.17 |
| P3V2 (Premium) | 2 | 5469.99 | 36.563 | 70116.29 |
その他状況と考察
- どのプランでもほとんどのリクエストを1秒以内に返していた。S1だけ、時々、リクエストに数十秒かかることはあったが、エラーになることは無かった。ということから、静的ファイルを返すだけなら、どのプランでも問題なさそう。
- D1の元々4コアマシンで動いているので、妙にパフォーマンスがよさそうにみえるが、Shared というくらいなので、同一サーバーに乗っかっている他のウェブサーバーの状況の影響を受けそうなのと、SLA が無いので、実際には、S1 や、今回テストしていない、B1 を選ぶの良さそう。
- 単一ファイルを読み出す場合は、当たり前だが、ストレージのパフォーマンスの影響は無さそう。
- 全体のスループットとしては、今回の13KBの単一ファイルの場合、トータル60～70MB/Secくらいに限界がある感じ。送信するファイルサイズを変えてみたら、230MB/Sec程度まで向上した。上限値は不明。Storage でHTMLをレスポンスした場合60MB/Secが上限なので、単一ファイルを送り出すだけなら、Storage よりもパフォーマンスは優れている。
- App Service のキャッシュパラメーターをイロイロ変更してみたが、ほとんど影響無し。
まとめ
大規模ウェブサイトの場合、メンテナンスページやソーリーページには B1 インスタンスと CDN の併用で対処、それ以外は、B1 インスタンスだけでも良いかも。
追伸 Web Apps on Linux でも同様の計測を実施
マイクロソフトが提供している PHP の実行環境を利用し同様な計測を実施。
| プラン | インスタンス数 | Requests per second | Time per request | Transfer rate |
|---|---|---|---|---|
| S1 (Standard) | 1 | 579.27 | 345.260 | 7507.37 |
S2やS3とったスケールアップをしても、10%程度の向上しか認められなかったので、PHP の実行環境の Apache 設定等々を変更しないと、Web apps on Linux では、IIS ベースの Web Apps の7分の1程度のパフォーマンスになってしまう。羽フォーマンスを犠牲にしても.htaccess を使いたいというような理由が無い限り、通常の Web Apps の方がコストパフォーマンスが高いという結論。