パフォーマンステストの実施
各Webサーバに対してパフォーマンステストを実施します
実施するパフォーマンステストの内容は以下の通りです
# | Protocol | Path | 応答するコンテンツ | 想定最大RPS | RPS/ユーザ | 最大ユーザ数 | 追加ユーザ数/秒 |
---|---|---|---|---|---|---|---|
1 | HTTP | /html/ | 静的HTML | 1800 | 15 | 120 | 10 |
2 | HTTPS | /html/ | 静的HTML | 1800 | 15 | 120 | 10 |
3 | HTTP | / | Wordpress(PHP) | 10 | 1 | 10 | 2 |
4 | HTTPS | / | Wordpress(PHP) | 10 | 1 | 10 | 2 |
0. パフォーマンステスト準備
Note
各Webサーバについて、対象のHTMLファイルやWordpressコンテンツの表示に必要となる設定変更を行っていますが、その他大容量の通信に合わせた設定変更は行っていません
必要となるホストへの接続、Webページを開きます
ホストへの接続
ubuntu04
へ接続してくださいGrafanaへの接続
NGINX Unit / NGINX / Apache Dashboard
を開いてください
ダッシュボード上部の各項目で表示する内容を選択できます。以下の内容を参考に表示内容を変更してください。
また、各項目のメモリの表示で RAM Used
をクリックすると表示がよりシンプルとなります
Locustへの接続・実行
踏み台ホストよりCLIで実行したレポートを確認するWebページを開いてください。URLは http://10.1.1.7/ です。
パフォーマンステストは踏み台ホストよりAnsibleを通じ、Locustでコマンド(Docker Run)を実行します。テストの実施後、こちらのページの表示を更新すると結果が表示されるようになります。 実行するパフォーマンステストのシナリオに関するファイルは こちらの config / senario フォルダに格納しています。
Locustで参照する config / senario のサンプルを以下に示します
以下がConfigファイルのサンプルです。その他詳細なパラメータは Locust Configuration を参照ください。
1 2 3 4 5 6 | headless = true host = http://10.1.1.4 users = 120 spawn-rate = 10 run-time = 120s loglevel = CRITICAL |
- 1行目、headless true を指定する事により、Web GUIなしでLocustを起動します
- 2行目、host がトラフィックを送付する宛先です
- 3行目、最終的にシュミレートする同時接続ユーザ数です
- 4行目、一秒間に増加するユーザ数です
- 5行目、トラフィックを発生させる秒数です
以下がSenarioファイルのサンプルです。Locust ではPythonで発生させるトラフィックの内容を詳細に記述することが可能です。その他詳細は Locust Writing a locustfile を参照してください。
1 2 3 4 5 6 7 8 9 | import time from locust import HttpUser, task, between, constant_throughput, constant class QuickstartUser(HttpUser): wait_time = constant_throughput(15) @task def hello_world(self): self.client.get("/html/index.html") |
- 5行目、
constant_throughput(15)
という表記で、1ユーザが1秒間あたりに task を実施する数を指定しています。つまりこのサンプルでは1ユーザ15rpsのリクエストを送付します - 7行目、
@task
という形でデコレータの記述があり、この内容がシミュレートされるユーザによって実行されます。このサンプルでは記述しておりませんが、複数の task を指定した割合で実行するなどが可能です - 9行目、 このシナリオでは
/html/index.html
に対してGET
を送付する動作となります
1. HTTP - 静的HTML
以下テストを実施します。
# | Protocol | Path | 応答するコンテンツ | 想定最大RPS | RPS/ユーザ | 最大ユーザ数 | 追加ユーザ数/秒 |
---|---|---|---|---|---|---|---|
1 | HTTP | /html/ | 静的HTML | 1800 | 15 | 120 | 10 |
パフォーマンステストの実施
作業用ホストで以下コマンドを実行し、トラフィックを発生させます
# cd ~/f5j-nginx-performance-lab/ansible
ansible-playbook -i inventory/hosts -l locust load-generate/load-http-html-allservers.yaml
1 2 3 4 5 6 7 8 9 10 | PLAY [all] ********************************************************************* TASK [Gathering Facts] ********************************************************* ok: [10.1.1.7] TASK [Locust http to html] ***************************************************** changed: [10.1.1.7] PLAY RECAP ********************************************************************* 10.1.1.7 : ok=2 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 |
結果の確認
Grafanaのダッシュボードを確認してください。サンプルの結果を以下に示します。
- 上から
Locust
、NGINX Unit
、NGINX Plus
、Apache
の結果となります - CPU、Memoryグラフの最大値は記載の通りです
- NGINX Unit、NGINX Plusでは、それぞれの記載のCPU利用率となります。メモリは通信処理時に大きな変化はありませんでした
- Apacheは、12.8% の使用率となり、メモリは通信処理時に 約62MB 増加し、380MB となりました
Locustサーバ Webページ を確認します
画面を更新すると、以下の表にLocustの実行結果が表示されます。各行が各ホストに対する実行結果を示しています。 詳細なレポートを確認する場合、対象の行をクリックしてください。以下にサンプルを示します。
新たなWindowに結果が表示されます。
- 画面左上部に
Target Host
、 そして送付するリクエストの内容を示すScript
が表示されていることが確認できます - Requestの
Fails
からエラーなく通信の処理ができていることが確認できます - Requestの
RPS
から秒間処理リクエスト数が 1517.2 であることが確認できます
2. HTTPS - 静的HTML
以下テストを実施します。
# | Protocol | Path | 応答するコンテンツ | 想定最大RPS | RPS/ユーザ | 最大ユーザ数 | 追加ユーザ数/秒 |
---|---|---|---|---|---|---|---|
2 | HTTPS | /html/ | 静的HTML | 1800 | 15 | 120 | 10 |
パフォーマンステストの実施
作業用ホストで以下コマンドを実行し、トラフィックを発生させます。コマンドの出力結果は HTTP-静的HTML
と同様のため省略します。
# cd ~/f5j-nginx-performance-lab/ansible
ansible-playbook -i inventory/hosts -l locust load-generate/load-https-html-allservers.yaml
結果の確認
Grafanaのダッシュボードを確認してください。サンプルの結果を以下に示します。
- 上から
Locust
、NGINX Unit
、NGINX Plus
、Apache
の結果となります - CPU、Memoryグラフの最大値は記載の通りです
- NGINX Unit、NGINX Plusでは、それぞれの記載のCPU利用率となります。メモリは通信処理時に大きな変化はありませんでした
- Apacheは、 12.2% の使用率となり、メモリは通信処理時に 約59MB 増加し、395MB となりました
Locustサーバ Webページ を更新し結果が表示されることを確認します。詳細なレポートを確認する場合、対象の行をクリックしてください。
- 画面左上部に
Target Host
、 そして送付するリクエストの内容を示すScript
が表示されていることが確認できます - Requestの
Fails
からエラーなく通信の処理ができていることが確認できます - Requestの
RPS
から秒間処理リクエスト数が 1233.2 であることが確認できます
3. HTTP - Wordpress(PHP)
以下テストを実施します。
# | Protocol | Path | 応答するコンテンツ | 想定最大RPS | RPS/ユーザ | 最大ユーザ数 | 追加ユーザ数/秒 |
---|---|---|---|---|---|---|---|
3 | HTTP | / | Wordpress(PHP) | 10 | 1 | 10 | 2 |
このテストではWebサーバとしての機能だけでなく、PHPの実行、SQLサーバの処理があるため、一つのリクエストに対し様々な機能が動作しています。 その動作がどの様に変化するか確認してください。
作業用ホストで以下コマンドを実行し、トラフィックを発生させます。コマンドの出力結果は HTTP-静的HTML
と同様のため省略します。
# cd ~/f5j-nginx-performance-lab/ansible
ansible-playbook -i inventory/hosts -l locust load-generate/load-http-wp-allservers.yaml
Note
稀にNGINX UnitがPHPの応答を返さない状態になる場合があります。その際には、 ubuntu01
に接続し、以下コマンドを実行してください。テスト実施時間の 120秒 経過を待ち、再度テストを行ってください
sudo service unit restart
結果の確認
Grafanaのダッシュボードを確認してください。サンプルの結果を以下に示します。
- 上から
Locust
、NGINX Unit
、NGINX Plus
、Apache
の結果となります - CPU、Memoryグラフの最大値は記載の通りです
- CPU利用率は NGINX Plusが 88.2% 、Apacheが 93% となっています。NGINX Unitでは、NGINX UnitがPHPを実行しています。CPU利用率は 50% となその他Webサーバと比較して利用率が低くなっております
- NGINX Unit、NGINX Plusでは、メモリは大きな増加はありません。Apacheは 約20MB 増加し、447MBとなりました
Locustサーバ Webページ を更新し結果が表示されることを確認します。詳細なレポートを確認する場合、対象の行をクリックしてください。
- 画面左上部に
Target Host
、 そして送付するリクエストの内容を示すScript
が表示されていることが確認できます - Requestの
Fails
からエラーなく通信の処理ができていることが確認できます - Requestの
RPS
から秒間処理リクエスト数が 9.8 であることが確認できます。WordpressへのリクエストではWebサーバの他様々なコンポーネントが動作するため、リクエスト数に対しリソースの消費が大きくなっています
4. HTTPS - Wordpress(PHP)
以下テストを実施します。
# | Protocol | Path | 応答するコンテンツ | 想定最大RPS | RPS/ユーザ | 最大ユーザ数 | 追加ユーザ数/秒 |
---|---|---|---|---|---|---|---|
4 | HTTPS | / | Wordpress(PHP) | 10 | 1 | 10 | 2 |
このテストではWebサーバとしての機能だけでなく、PHPの実行、SQLサーバの処理があるため、一つのリクエストに対し様々な機能が動作しています。 その動作がどの様に変化するか確認してください。
作業用ホストで以下コマンドを実行し、トラフィックを発生させます。コマンドの出力結果は HTTP-静的HTML
と同様のため省略します。
# cd ~/f5j-nginx-performance-lab/ansible
ansible-playbook -i inventory/hosts -l locust load-generate/load-https-wp-allservers.yaml
結果の確認
Grafanaのダッシュボードを確認してください。サンプルの結果を以下に示します。
- 上から
Locust
、NGINX Unit
、NGINX Plus
、Apache
の結果となります - CPU、Memoryグラフの最大値は記載の通りです
- CPU利用率は NGINX Plusが 88% 、Apacheが 96% となっています。NGINX Unitでは、NGINX UnitがPHPを実行しています。CPU利用率は 51% となその他Webサーバと比較して利用率が低くなっております
- NGINX Unit、NGINX Plusでは、メモリは大きな増加はありません。Apacheは 約29MB 増加し、453MBとなりました
Locustサーバ Webページ を更新し結果が表示されることを確認します。詳細なレポートを確認する場合、対象の行をクリックしてください。
- 画面左上部に
Target Host
、 そして送付するリクエストの内容を示すScript
が表示されていることが確認できます - Requestの
Fails
からエラーなく通信の処理ができていることが確認できます - Requestの
RPS
から秒間処理リクエスト数が 8 であることが確認できます
5. 結果の考察
全体的なテストの結果
# | Protocol | Path | 応答するコンテンツ | 想定最大RPS | RPS/ユーザ | 最大ユーザ数 | 追加ユーザ数/秒 |
---|---|---|---|---|---|---|---|
1 | HTTP | /html/ | 静的HTML | 1800 | 15 | 120 | 10 |
2 | HTTPS | /html/ | 静的HTML | 1800 | 15 | 120 | 10 |
3 | HTTP | / | Wordpress(PHP) | 10 | 1 | 10 | 2 |
4 | HTTPS | / | Wordpress(PHP) | 10 | 1 | 10 | 2 |
- html はすべてのWebサーバである程度安定した結果となります
- Wordpress の処理はWebサーバの同一ホスト内でPHP・DBが動作するため少ないリクエスト数でCPU利用率が高くなっています
- Apache
- クライアントが増加する際にWorker Processをforkするため、同時接続ユーザ数に応じてメモリ消費量が増加します
- 大規模の環境で多量のクライアントから多量の通信が発生する場合にはCPU、メモリの増加が見られるため、通信規模に応じたリソースの確保が必要になると想定されます
- forkしたプロセスがリクエストに対して応答するため、想定したクライアント数以下の状況では比較的安定で高速な応答が可能と想定されます
- 通信量に応じたその他多くのパラメータが用意されているため、環境に合わせたチューニングが可能です
- NGINX Plus (NGINX)
- クライアント・通信量の増加に応じてCPUの増加が見られます。その量はApacheと比較すると増加が少ない傾向です
- Apacheの実装とは異なり、Worker Processのforkを行う実装ではありません。このため通信量・接続ユーザ数増加の際に顕著なメモリ消費の増加は見られません
- NGINXはインストール時のデフォルト設定では、動作ホストのCPUコア数分のWorker Processが動作し、各Worker Processで1024コネクションの処理が可能となります
- 大量の通信が発生した場合には、リクエストに対する応答に時間がかかる場合がありますが、大量の処理が可能です
- 通信量に応じたその他多くのパラメータが用意されているため、環境に合わせたチューニングが可能です
- NGINX Unit
- クライアント・通信量の増加に応じてCPUの増加が見られます。その量はApacheと比較すると増加が少ない傾向です
- メモリについてはNGINXと同様に HTML 、PHPにおいても極端に増加するなどの傾向は見られません
- PHPの処理をNGINX UnitのPHPモジュールにて実施しますが、NGINX PlusやApacheの環境に比べてCPU利用率が低くなっています
- NGINXと同様の安定した応答が見られますが、PHPなどプログラムの処理により応答に時間がかかる場合があります
- 動作時のリソース消費などは少ない実装であると確認できますが、通信に対するパラメータチューニングの項目はあまり多くありません
総括
- Apache , NGINX は大規模な環境に適応可能
- NGINX Unit は基本的なWebサーバやProxy機能を持つが、
アプリケーションサーバ
の位置づけであるため、HTTPをベースにした外部との接続とプログラムの安定実行に強みを持つ - Apacheは Worker Process の fork によるメモリ増加、及びWorker Processを超えるクライアントからの接続があった場合に、C10K問題に見られるような限界が発生する可能性がある
- 大規模環境ではクライアント通信を受け付けるLB/ADC/Proxyが必要であり、NGINXを利用しその実装をすることが可能。Webサーバやアプリケーションサーバはその後段で適切な負荷分散を受けて安定したシステム構築が必要