マルチサイト環境におけるサーバ負荷試験の結果をもとに、処理性能の制限について考察しました。
負荷試験における前提は以下のとおりです。
- 負荷試験ツールには、Apache JMeter (http://jmeter.apache.org) を利用する。
- 同時接続数とリクエストのループ回数、リクエスト間隔のパラメータを調整しながら負荷試験を行う。
- リクエストの対象には、以下の2つのページへのリクエストを利用する。
-
- サイトのトップページ
- 「東京都」を条件にした検索ページ(検索条件の中で、結果データ量が最も多い条件)
負荷試験は、ユーザがトップページを表示した後、「東京都」を条件に検索をかけたオペレーションをシミュレートし、これを指定回数繰り返した時の負荷傾向を確認しました。
なお、リクエストには画像ファイルや、CSSファイルなども含みます。
- 負荷をかけていきながら、単一サーバ構成時のスループット限界値を探る。
試験環境は以下のとおりです。
- サーバーはさくらVPSを利用した。
- WordPressをサーバの Document Root へインストールした。
- Document Root 配下のサブディレクトリに静的コンテンツを配置した。
- WordPressのマルチサイト機能を用いてユーザ専用サイトを構築した。
サーバー構成は以下のとおりです。
考察に利用した負荷試験の結果項目は、以下のとおりです。
- 負荷試験完了までに要した時間
- スループット(1秒間に処理したリクエスト数)
- エラー率
- サーバの1分間ロードアベレージを負荷試験所要時間で平均した値
- サーバのCPU使用率を負荷試験所要時間で平均した値
- サーバのメモリ使用量を負荷試験所要直で平均した値
負荷試験の結果は以下の通りです。なお、結果の「項目○」はそれぞれ上記項目を表します。
# |
条件 |
結果 |
||||||
最大同時 接続数 |
リクエスト総数 |
項目1 (秒) |
項目2 (リクエスト/秒) |
項目3 (%) |
項目4 (ロードアベレージ) |
項目5 (%) |
項目6 (MB) |
|
1 |
10 |
3,400 |
353 |
9.548 |
0.00 |
0.75 |
82.8 |
372.2 |
2 |
20 |
6,800 |
455 |
14.68 |
0.00 |
5.02 |
77.2 |
479.9 |
3 |
30 |
10,200 |
602 |
16.68 |
0.00 |
11.13 |
81.3 |
594.6 |
4 |
40 |
13,600 |
734 |
17.03 |
0.00 |
15.60 |
82.5 |
711.3 |
5 |
50 |
17,000 |
908 |
17.03 |
0.00 |
17.20 |
83.3 |
766.6 |
6 |
60 |
20,400 |
1,083 |
17.03 |
2.61 |
18.14 |
83.4 |
784.2 |
7 |
70 |
23,800 |
1,306 |
17.03 |
15.86 |
19.12 |
83.5 |
791.6 |
負荷試験の結果から、以下のとおり考察しました。
- スループットは、最大同時接続数とリクエスト数の負荷を与えていくことによって、ある一定値までは、数値が上がっています。
これは、増加した負荷をそれだけ処理できていることを示します。 - 一方で、最大同時接続数30、リクエスト総数10,200 をピークに、負荷を与えていくとスループットは横ばいとなっています。
よって、今回の負荷試験におけるスループットの限界値は、「16.69」となります。
また、更に負荷を与えていくと、最大同時接続数0, リクエスト総数20,400のタイミングからエラーが発生するようになり、以降与えていく負荷を増加する度にエラー率は高くなります。 - 2の結果を基に、今回シミュレートしたオペレーションで1日に許容可能な最大リクエスト数を以下に示します。
- 1分間に処理できるリクエスト数:1,000.8 (16.68 × 60秒)
- 1時間に処理できるリクエスト数:60,048 (1,000.8 × 60秒)
- 1日に処理できるリクエスト数:1,441,152 (60,048 × 24)
- 負荷試験の結果から、1日のリクエスト数が1,441,152 リクエストを超えるタイミングを一つの契機とし、負荷分散のためにスレーブサーバの増設を検討します。
補足
今回の負荷試験は、検索ページを対象とし、アクセス毎にデータベースへの処理が発生する環境をシミュレートしました。
この時、試験中の主な負荷要因は、データベースの処理にあることが負荷試験ツール(Apache JMeter)のログから分かりました。
実際のオペレーションでは、データベースのリクエスト結果が一時的にキャッシュされることによる速度および負荷の改善や、常に検索を利用する状況にないことなどを考慮する必要があります。