パフォーマンステストの実施

各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 へ接続してください
接続手順の詳細は WindowsホストへのRDP接続 を参照してください

Grafanaへの接続

踏み台ホストよりGrafanaを開いてください。URLは http://10.1.1.8:3000/ です。
ログインが求められる場合には、 user:admin , password:admin でログインしてください
../../_images/grafana-top.png

NGINX Unit / NGINX / Apache Dashboard を開いてください

../../_images/grafana-open-dashboard.png

ダッシュボード上部の各項目で表示する内容を選択できます。以下の内容を参考に表示内容を変更してください。

../../_images/grafana-dashboard.png

また、各項目のメモリの表示で RAM Used をクリックすると表示がよりシンプルとなります

../../_images/grafana-dashboard2.png

Locustへの接続・実行

踏み台ホストよりCLIで実行したレポートを確認するWebページを開いてください。URLは http://10.1.1.7/ です。

../../_images/locust-cliresult-top.png

パフォーマンステストは踏み台ホストよりAnsibleを通じ、Locustでコマンド(Docker Run)を実行します。テストの実施後、こちらのページの表示を更新すると結果が表示されるようになります。 実行するパフォーマンステストのシナリオに関するファイルは こちらの config / senario フォルダに格納しています。

Locustで参照する config / senario のサンプルを以下に示します

以下がConfigファイルのサンプルです。その他詳細なパラメータは Locust Configuration を参照ください。

Config ファイルサンプル (http_10-1-1-4_html.conf)
1headless = true
2host = http://10.1.1.4
3users = 120
4spawn-rate = 10
5run-time = 120s
6loglevel = CRITICAL

  • 1行目、headless true を指定する事により、Web GUIなしでLocustを起動します

  • 2行目、host がトラフィックを送付する宛先です

  • 3行目、最終的にシュミレートする同時接続ユーザ数です

  • 4行目、一秒間に増加するユーザ数です

  • 5行目、トラフィックを発生させる秒数です

以下がSenarioファイルのサンプルです。Locust ではPythonで発生させるトラフィックの内容を詳細に記述することが可能です。その他詳細は Locust Writing a locustfile を参照してください。

Senario ファイルサンプル (html.py)
1import time
2from locust import HttpUser, task, between, constant_throughput, constant
3
4class QuickstartUser(HttpUser):
5    wait_time = constant_throughput(15)
6
7    @task
8    def hello_world(self):
9        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

パフォーマンステストの実施

作業用ホストで以下コマンドを実行し、トラフィックを発生させます

su ubuntu
cd ~/f5j-nginx-performance-lab/ansible
ansible-playbook -i inventory/hosts -l locust load-generate/load-http-html-allservers.yaml
実行結果サンプル
 1PLAY [all] *********************************************************************
 2
 3TASK [Gathering Facts] *********************************************************
 4ok: [10.1.1.7]
 5
 6TASK [Locust http to html] *****************************************************
 7changed: [10.1.1.7]
 8
 9PLAY RECAP *********************************************************************
1010.1.1.7                   : ok=2    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

結果の確認

Grafanaのダッシュボードを確認してください。サンプルの結果を以下に示します。

../../_images/grafana-http-html.png

  • 上から Locust 、 NGINX Unit 、 NGINX Plus 、 Apache の結果となります

  • CPU、Memoryグラフの最大値は記載の通りです

  • NGINX Unit、NGINX Plusでは、それぞれの記載のCPU利用率となります。メモリは通信処理時に大きな変化はありませんでした

  • Apacheは、12.8% の使用率となり、メモリは通信処理時に 約62MB 増加し、380MB となりました

Locustサーバ Webページ を確認します

../../_images/locust-web-http-html.png

画面を更新すると、以下の表にLocustの実行結果が表示されます。各行が各ホストに対する実行結果を示しています。 詳細なレポートを確認する場合、対象の行をクリックしてください。以下にサンプルを示します。

../../_images/locust-web-http-html-report.png

新たな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 と同様のため省略します。

su ubuntu
cd ~/f5j-nginx-performance-lab/ansible
ansible-playbook -i inventory/hosts -l locust load-generate/load-https-html-allservers.yaml

結果の確認

Grafanaのダッシュボードを確認してください。サンプルの結果を以下に示します。

../../_images/grafana-https-html.png

  • 上から Locust 、 NGINX Unit 、 NGINX Plus 、 Apache の結果となります

  • CPU、Memoryグラフの最大値は記載の通りです

  • NGINX Unit、NGINX Plusでは、それぞれの記載のCPU利用率となります。メモリは通信処理時に大きな変化はありませんでした

  • Apacheは、 12.2% の使用率となり、メモリは通信処理時に 約59MB 増加し、395MB となりました

Locustサーバ Webページ を更新し結果が表示されることを確認します。詳細なレポートを確認する場合、対象の行をクリックしてください。

../../_images/locust-web-https-html-report.png

  • 画面左上部に 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 と同様のため省略します。

su ubuntu
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のダッシュボードを確認してください。サンプルの結果を以下に示します。

../../_images/grafana-http-wp.png

  • 上から 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ページ を更新し結果が表示されることを確認します。詳細なレポートを確認する場合、対象の行をクリックしてください。

../../_images/locust-web-http-wp-report.png

  • 画面左上部に 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 と同様のため省略します。

su ubuntu
cd ~/f5j-nginx-performance-lab/ansible
ansible-playbook -i inventory/hosts -l locust load-generate/load-https-wp-allservers.yaml

結果の確認

Grafanaのダッシュボードを確認してください。サンプルの結果を以下に示します。

../../_images/grafana-https-wp.png

  • 上から 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ページ を更新し結果が表示されることを確認します。詳細なレポートを確認する場合、対象の行をクリックしてください。

../../_images/locust-web-https-wp-report.png

  • 画面左上部に 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サーバやアプリケーションサーバはその後段で適切な負荷分散を受けて安定したシステム構築が必要