当サイトで紹介している各レンタルサーバーの実際のパフォーマンスをチェックするために、各種のベンチマークテストを実行しています。
これまで PHP Benchmark と PHPspeed というスクリプトを利用して、PHP 関連のベンチマークテストを行いました。
今回は、ApacheBench というベンチマークツールを利用して、Webサーバーのパフォーマンスを確認してみました。
なお、2016年11月の heteml のサーバー環境が一新に伴い、heteml では新環境でテストを実施しています。その結果については「heteml(ヘテムル)が復活!新サーバー環境と「モジュール版PHP」を徹底検証」を参照してください。
ApacheBench とは?
ApacheBench は、Webサーバーのソフトとして広く利用されている Apache に組み込まれている Webサーバーの性能を測定するための負荷テストツールです。当サイトで紹介しているすべてのサーバーでも、この Apache が利用されています。
ちなみに負荷テストとは、意図的にサーバーに負荷をかけることで、高負荷状態になったときに、どのようなパフォーマンスを示すのかを確認するための動作確認テストのことです。実際にアクセス集中した時にもサーバーが落ちたりしないように調整などを行う目的で用いられます。
ApacheBench は単一の URL に対するリクエストを生成し、Webサーバーの様々なパフォーマンスを計測します。静的な HTML サイトだけでなく、動的に生成される WordPress サイトなどでも適用できますが、サーバーのシステム全体の性能の計測を行えるわけではありません。
ApacheBench での計測方法
今回の測定を行うために、すべてのサーバーに以下のような全く同じコンテンツの HTML サイトと WordPress のサイトを構築し、テストをしました。
・文字数 約2,500
・ヘッダー画像 1枚
・本文中画像 1枚
・WordPress のテーマは「Twenty Sixteen」
・不要なプラグインは削除し、「WP Multibyte Patch」のみ有効
ApacheBench は、単一のファイルに対するリクエストを処理するため、同じページ内に含まれる画像などはテストの対象にはならないのですが、一応画像もまったく同じものを貼ってあります。
テストは、同時接続数 10、リクエスト 100で実行します。
これは Webサーバーに対して同時に 10人の人がアクセスし、それぞれ 10のリクエストを行うのと同じ状態を作り出し、その処理が終わるまでのパフォーマンスを計測するという意味です。
ちなみに、サーバーの設定にもよりますが、「1ページを表示する=1リクエスト」というわけではありません。
Webサイトのページは、HTMLファイルと画像ファイル、動画ファイルなどによって構成されていますので、1ページを閲覧する場合、ベースになる HTML ファイルに加えて、そこに含まれる画像や動画の数の分だけさらにリクエストが発生します。そのため、10人がアクセスしたら 10リクエストだけ発生するということにはなりません。
このレベルであれば、サーバーに対してそれほどの負担にはならないと言われていますので、上記の条件で実施しました。
ApacheBench での結果は?
ApacheBench で確認できる要素はたくさんあるのですが、その中で最も重要なパフォーマンスの一つである、1秒間に処理したリクエスト数(Requests per second)を比較してみます。
基本的には、この数値が大きければ、その分処理能力が高いと言えます。
また、HTTP と WordPress などの PHP ファイルに対して実行した結果は、大きく異なる傾向があります。
いわゆる「静的」な HTTP ファイルの場合、サーバーに格納されている HTTP ファイルとそこに含まれる画像などがそのまま送り返されるだけの単純作業ですが、PHP などの「動的」なファイルの場合は、リクエストに応じてその都度データベースサーバーにアクセスしてファイルを生成する処理を行う必要がありますので、PHP 自体の処理速度に加え、MySQL などのデータベースの処理効率なども要素に含まれると言えます。
そのため、HTTP と PHP のファイルに対してのテストを、各サーバーに対してそれぞれ実施しています。
また、他のベンチマークと同様に、平日に時間帯を変えて、全部で 7回実行しました。
時間帯についても、時間ごとのブレを見るために、9時・12時・15時・17時・19時・21時・23時台と、できるだけまんべんなく実施しています。
以下が、その結果の一覧です。(見づらいため小数点以下は四捨五入してあります)
HTTP Requests per second
9:00 | 12:00 | 15:00 | 17:00 | 19:00 | 21:00 | 23:00 | 平均 | 順位 | |
エックスサーバー | 1,629 | 1,640 | 1,725 | 1,696 | 1,687 | 1,665 | 1,645 | 1,670 | 1 |
ABLENET | 1,034 | 1,368 | 1,368 | 1,358 | 1,284 | 945 | 1,240 | 1,228 | 2 |
さくらプレミアム | 1,050 | 1,154 | 1,066 | 917 | 1,485 | 946 | 1,408 | 1,146 | 3 |
カゴヤ | 961 | 893 | 962 | 942 | 858 | 841 | 780 | 891 | 4 |
クローバー | 418 | 400 | 1,086 | 1,119 | 1,103 | 1,130 | 395 | 807 | 5 |
ロリポップ | 404 | 415 | 395 | 379 | 394 | 360 | 283 | 376 | 6 |
heteml | 298 | 341 | 325 | 335 | 340 | 333 | 342 | 331 | 7 |
Bizメール | 233 | 208 | 202 | 231 | 199 | 199 | 131 | 200 | 8 |
WebARENA | 74 | 140 | 193 | 79 | 115 | 182 | 184 | 138 | 9 |
WADAX | 135 | 112 | 121 | 107 | 115 | 43 | 124 | 108 | 10 |
iClusta | 95 | 95 | 93 | 87 | 86 | 73 | 75 | 86 | 11 |
SpeeVer | 65 | 64 | 59 | 64 | 66 | 65 | 64 | 64 | 12 |
お名前.com | 30 | 31 | 27 | 29 | 31 | 30 | 30 | 30 | 13 |
HTTP の処理は、単にサーバー内に格納されている HTML ファイルのデータを送り返すだけのごく単純な処理です。
しかし、HTTP のリクエスト処理数は、上は 4ケタから下は 2ケタまでと大きな差が出ました。
安定して数値が高いのは、エックスサーバーです。さくらインターネットと ABLENET でも 4ケタ台のよい数値が出ています。
一方、SpeeVer や iCLUSTA+、お名前.com は、上位と比べるとかなり低いパフォーマンスになっていますね。
PHP Requests per second
9:00 | 12:00 | 15:00 | 17:00 | 19:00 | 21:00 | 23:00 | 平均 | 順位 | |
ロリポップ | 443 | 424 | 377 | 337 | 385 | 393 | 321 | 383 | 1 |
カゴヤ | 188 | 159 | 148 | 138 | 176 | 171 | 188 | 167 | 2 |
エックスサーバー | 69 | 68 | 68 | 49 | 67 | 97 | 45 | 66 | 3 |
WADAX | 27 | 28 | 37 | 44 | 45 | 35 | 44 | 37 | 4 |
クローバー | 31 | 34 | 14 | 13 | 35 | 32 | 14 | 25 | 5 |
heteml | 25 | 24 | 25 | 23 | 20 | 25 | 24 | 23 | 6 |
ABLENET | 23 | 24 | 24 | 23 | 20 | 23 | 23 | 23 | 7 |
WebARENA | 17 | 16 | 18 | 20 | 14 | 19 | 16 | 17 | 8 |
お名前.com | 24 | 14 | 19 | 13 | 17 | 6 | 6 | 14 | 9 |
iClusta | 14 | 14 | 11 | 12 | 14 | 13 | 12 | 13 | 10 |
さくらプレミアム | 6 | 6 | 6 | 5 | 6 | 5 | 5 | 6 | 11 |
SpeeVer | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 12 |
Bizメール | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 13 |
一方 PHP のリクエスト処理数は、HTML に比べると全体的にぐっと数値が下がります。
これは WordPress サイトの場合、HTTP のように単に格納されているファイルを送り返すだけではなく、MySQL などのデータベースソフトからデータベースにアクセスし、ファイルの情報を構築してから送り返すという作業が必要になるためで、その処理の分パフォーマンスは低下します。
その中でも、ロリポップとカゴヤは 3ケタの数値を保っていますね。
カゴヤは HTML でも 4位につけていますので、高い実力を持っていると言えるでしょう。
ただ、ロリポップに関しては、HTTP の処理数は目立っていいわけではないのにも関わらず、PHP の処理数でもほとんど数値に変化がありません。
また、ロリポップに関してもう一つ気になったのは、「Document Length(アクセス先のファイルサイズ)」が HTTP でも PHP でも変わらず、また他社と比べて数値が少ないことです。HTTP の場合、他社ではおおむね 19,911バイトのところが、ロリポップでは 4,321バイト。PHP の場合は、ほぼ 0バイトで返されるところが、HTTP と同じ 4,321バイトという結果が毎回出ました。
どうしてこのような数値が返されるのかわからないのですが、どこかで何らかのキャッシュ機能のようなものが働いていて、動的ファイルでも静的ファイルと同じように応答が返されるようになっているのかもしれません。
そのため、Webサーバーの本当の実力かどうかという点では、ちょっとわからないところがありますね。
表には載せていないのですが、もう一つコメントしておきたいのは、お名前.com で PHP のすべてのテストにおいて処理の失敗(Failure)が発生している点です。
一般的に ApacheBench でリクエストに対する失敗が発生する場合は、Webサーバーの処理が追いついていない状態が発生しているためと言われています。
ただ、ApacheBench では、レスポンスのサイズが同一ではないと失敗と判断されるケースがあるようです。お名前.com のリクエストの失敗理由はすべて「Length」でこのケースに該当するため、Webサーバーの処理が追いついていないわけではないと推測されます。
ちなみに、エックスサーバーでもファイルの圧縮などの最適化を行う「mod_pagespeed」というモジュールを有効にして ApacheBench を実行した際に、同じように「Length」の失敗が発生しました。
お名前.com に関しては、WordPress のキャッシュプラグインなどを有効にしても効果がないようなので、もともとサーバー側で同種の機能が有効になっていて、その影響で処理の失敗が発生したのかもしれません。
ApacheBench のまとめ
以上、ApacheBench の結果でした。
HTML と PHP では結果に大きく違いがありました。
さくらインターネットは、通常の HTML のサイトの表示は早いが、WordPress などの CMS は重い、という評判をよく聞きますが、実際に今回の調査結果でも HTML では 3位に食い込んでいるにも関わらず、PHP では逆に下から 3位という結果になってしまいました。さくらインターネットは、レンタルサーバーのリーディングカンパニーの一つなので、とても残念な結果です。
また、上位では HTML・PHP のいずれも 5位以内に入っているのは、エックスサーバー・カゴヤ・クローバーです。
エックスサーバーとカゴヤは、PHPbenchmark や PHPspeed でも上位 3位以内に入っていますので、非常に実力が高いレンタルサーバーであることがわかります。