ここから本文です

“いきなり1000倍高速”WordPress仮想マシン「KUSANAGI」は、実際にどれだけ速いのか

@IT 8月26日(金)5時10分配信

 前回は、“いきなり1000倍高速”を実現するWordPress高速化チューニング済み仮想マシン「KUSANAGI」で得られる、「7つのメリット」を紹介しました。

【その他の画像】KUSANAGIを利用できるパブリッククラウドサービス(2016年8月現在)

 今回は、実際にKUSANAGIをパブリッククラウド上で起動させ、「本当に速いのか」を確かめましょう。「Amazon Web Services(以下、AWS)」対応版の「KUSANAGI for AWS」を用い、本連載の第2回~第10回で実践してきた高速化チューニングの結果と比べます。

 なお、2016年8月現在、KUSANAGIは10種類のパブリッククラウドサービス(IaaS:Infrastructure as a Service)での仮想マシンイメージとして使えます。今回はAWSの仮想クラウドサーバ「Amazon Elastic Compute Cloud(以下、Amazon EC2)」上にインスタンスを構築して検証しますが、それ以外のクラウドサービスを使っている人も、AWS固有の表記などを適宜読み替えることで応用していただけます。

●AWS上でKUSANAGIを起動して、WordPressをインストールする

 Amazon EC2上にインスタンスを用意します。第2回「WordPressを2.5倍速くするPHPアクセラレータ“APC”」で導入したものと同様に、「t2.medium」インスタンスを「東京リージョン」で作成します。以下のサイトを参考に、KUSANAGIの仮想マシンにSSHでログインし、管理者ユーザーに切り替えるまで作業を進めてください。

・【1】「KUSANAGI for AWS」のインストール方法(https://kusanagi.tokyo/cloud/kusanagi-for-aws/)

 マシンイメージは「KUSANAGI for AWS」を選びます。KUSANAGI for AWSは、AWS Marketplaceの「Amazonマシンイメージ(AMI)」コーナーに登録されています。なお、KUSANAGIでの本運用においては4GiB以上のメモリを割り当てたインスタンスを推奨しますが、今回のテスト用途ならば2GiB程度のメモリがあれば大丈夫です。

 ここから、「ホスト名(パブリックDNS)での名前解決が可能であり、ホスト名で仮想マシンへ外部からアクセスできる環境にある」として話を進めます。名前解決は、クライアントマシンのhostsファイル設定によるものでも構いません。また、本稿でのホスト名は「ec2-xxx.xxx.compute.amazonaws.com」とダミー文字列で記述しますので、適宜自身の環境に置き換えて設定を進めてください。

 KUSANAGIの初期設定とプロビジョニングを行います。以下のサイトを参考に、作業を進めてください。

・【2】「KUSANAGI」の初期設定方法(https://kusanagi.tokyo/document/kusanagi-init/)
・【3】「KUSANAGI」のプロビジョニング(https://kusanagi.tokyo/document/kusanagi-provision/)

 プロビジョニングの作業によって、WordPressのインストールに必要なディレクトリの生成やファイル群の配置などが行われます。hostnameの設定では、「ec2-xxx.xxx.compute.amazonaws.com」と仮想マシンにアクセス可能なホスト名を入力します。なお、今回は外部へ公開しないテスト用途としますので、「SSL」および「Let's Encrypt」の設定は省略して構いません。Let's Encryptの設定の場面で、「Enter」キーを2回押して処理をスキップできます。

 KUSANAGIにWordPressをインストールします。以下のサイトを参考に、作業を進めます。

・【4】「KUSANAGI」へのWordPressのインストール方法(https://kusanagi.tokyo/document/kusanagi-init/)

 無事WordPressの初期トップページ画面を確認できましたら、一度SSHコンソールに戻って、kusanagiコマンドを利用して現在のステータスを確認します。

kusanagi status

・表示される内容
[root@ip ~]# kusanagi status
Profile: kusanagi_html
KUSANAGI Version 7.8.3
aws
*** nginx ***
● nginx.service - The NGINX HTTP and reverse proxy server
Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; vendor preset: disabled)
Active: active (running) since Mon 2016-07-04 02:31:38 JST; 4min 25s ago
*** Apache2 ***
● httpd.service - The Apache HTTP Server
Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled; vendor preset: disabled)
Active: inactive (dead)
*** HHVM ***
● hhvm.service - HHVM virtual machine, runtime, and JIT for the PHP language
Loaded: loaded (/etc/systemd/system/hhvm.service; enabled; vendor preset: disabled)
Active: active (running) since Mon 2016-07-04 02:31:38 JST; 4min 25s ago
*** php-fpm ***
● php-fpm.service - The PHP FastCGI Process Manager
Loaded: loaded (/usr/lib/systemd/system/php-fpm.service; disabled; vendor preset: disabled)
Active: inactive (dead)
*** php7-fpm ***
● php7-fpm.service - The PHP FastCGI Process Manager
Loaded: loaded (/usr/lib/systemd/system/php7-fpm.service; disabled; vendor preset: disabled)
Active: inactive (dead)
*** Cache Status ***
fcache off
bcache off
Done.

 冒頭には、「現在選択されているプロファイル」「KUSANAGIのバージョン」「クラウドサービス」が表示されます。この例では、kusanagi_htmlがプロファイルとして選択されており、KUSANAGIのバージョンは7.8.3、クラウドサービスはAWSであることが分かります。

 プロファイルは、前述したWordPressのプロビジョニング時に指定したものです。ここでは、複数のバーチャルホストが有効になっているときに、どのバーチャルホストが現在のkusanagiコマンドでの操作対象となっているかを示しています。

 中段は、WebサーバとPHP処理系の状態が表示されます。この例では、Webサーバは「Nginx」、PHP処理系は「HHVM」が有効であり、既に実行されていることを示しています。

 下段のCache Status以下は、KUSANAGIが持つ2つのページキャッシュの状況を示す項目です。この例では、NginxのFastCGIキャッシュ(fcache)が「無効」、WordPressのKUSANAGI専用プラグインとして同梱されているページキャッシュ(bcache)も「無効」であることを示しています。

●インスタンスの状態を確認する

 ベンチマーク測定の前に、現在のインスタンスのメモリとCPUの状態も確認しておきましょう。まず、メモリから確認します。

free -m


 次のようなステータスが表示されます。

[[root@ip ~]# free -m
total used free shared buff/cache available
Mem: 3534 360 2714 8 458 2969
Swap: 9211 0 9211


 この例では、約3.5GBが利用可能であることを確認できます。

 続いてCPUの状態も確認します。

cat /proc/cpuinfo


 次のようなステータスが表示されます。
[root@ip ~]# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 62
model name : Intel(R) Xeon(R) CPU E5-2670 v2 @ 2.50GHz
stepping : 4
microcode : 0x416
cpu MHz : 2500.026
cache size : 25600 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx rdtscp lm constant_tsc rep_good nopl xtopology eagerfpu pni pclmulqdq ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm fsgsbase smep erms xsaveopt
bogomips : 5000.05
clflush size : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:
processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 62
model name : Intel(R) Xeon(R) CPU E5-2670 v2 @ 2.50GHz
stepping : 4
microcode : 0x416
cpu MHz : 2500.026
cache size : 25600 KB
physical id : 0
siblings : 2
core id : 1
cpu cores : 2
apicid : 2
initial apicid : 2
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx rdtscp lm constant_tsc rep_good nopl xtopology eagerfpu pni pclmulqdq ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm fsgsbase smep erms xsaveopt
bogomips : 5000.05
clflush size : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual
power management:


 ここでは、2コア/2.5GHz動作の「Xeonプロセッサー E5-2670 v2」が割り当てられていました。

 第3回「CentOS 7の標準環境だけですぐできる、WordPress“5.4倍高速化”テクニック 後編」でも解説しましたが、Amazon EC2のインスタンスで利用するCPUの種類は、仮想マシンを起動するタイミングで、都度割り当てられます。必ず同じCPUが割り当てられるのではなく、近い性能の別のCPUが割り当られることもあります。例えば今回使ったt2.mediumインスタンスでは、上記で割り当てられた2.5GHz動作のXeonプロセッサー E5-2670 v2以外に、2.4GHz動作の「Xeonプロセッサー E5-2676 v3」が割り当てられることもあります。Xeonプロセッサー E5-2676 v3は、周波数の値こそ若干下がりますが、1世代新しいCPUということで、全体のパフォーマンスは十数パーセントほど向上するようです。

●KUSANAGIのベンチマークを測定する

 では、KUSANAGIは本当に速いのか。KUSANAGIのベンチマーク結果と、以前実施したWordPressチューニング環境のパフォーマンスを比べてみましょう。

 まず、Webサーバの2種類「Nginx 1.11」と「Apache 2.4」、PHP処理系の2種類「HHVM 3.13」と「PHP 7.0」を組み合わせた、ページキャッシュを用いない4パターンのパフォーマンスを、1秒当たりの同時アクセス数を測定できるabコマンドで確認します。

(1)KUSANAGIベンチマーク:Apache+PHP 7環境

 KUSANAGI環境のミドルウェアの組み合わせを「Apache」+「PHP 7」に切り替えます。

kusanagi httpd
kusanagi php7


 abコマンドを実行します。次のコマンドを10秒間隔で5回実行します。間隔を空けて複数回実行するのは、ウォームアップを行い、測定の精度を高めるためです。

ab -n 300 -c 30 http://ec2-xxx.xxx.compute.amazonaws.com/
(“xxx”はユーザー固有の文字列、以下同)

 筆者の環境では、5回目の実行で次のような結果が返ってきました。
[root@ip ~]# ab -n 300 -c 30 http://ec2-xxx.xxx.compute.amazonaws.com/
This is ApacheBench, Version 2.3 <$Revision: 1706008 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking ec2- xxx.xxx.compute.amazonaws.com (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Finished 300 requests
Server Software: Apache
Server Hostname: ec2-xxx.xxx.compute.amazonaws.com
Server Port: 80
Document Path: /
Document Length: 11679 bytes
Concurrency Level: 30
Time taken for tests: 1.924 seconds
Complete requests: 300
Failed requests: 0
Total transferred: 3594300 bytes
HTML transferred: 3503700 bytes
Requests per second: 155.95 [#/sec] (mean)
Time per request: 192.366 [ms] (mean)
Time per request: 6.412 [ms] (mean, across all concurrent requests)
Transfer rate: 1824.68 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.1 0 1
Processing: 80 187 32.0 198 285
Waiting: 80 187 32.0 197 285
Total: 81 187 32.0 198 285
Percentage of the requests served within a certain time (ms)
50% 198
66% 201
75% 204
80% 206
90% 215
95% 219
98% 226
99% 260
100% 285 (longest request)


 1秒当たりの同時アクセス数は「155.95」となりました

(2)KUSANAGIベンチマーク:Nginx+PHP 7環境

 続いて、ミドルウェアの組み合わせを「Nginx」+「PHP 7」に変更します。

kusanagi nginx

ミドルウェアの組み合わせを「Nginx」+「PHP 7」に切り替えるKUSANAGIコマンド(kusanagi php7は、前述した(1)で設定済みのため省略)

 abコマンドを実行します。ここでは以下のコマンドを、10秒間隔で3回実行します。

ab -n 300 -c 30 http://ec2-xxx.xxx.compute.amazonaws.com/

 筆者の環境では、3回目の実行で1秒当たりの同時アクセス数が「163.09」となりました。

(3)KUSANAGIベンチマーク:Apache+HHVM環境

 続いて、ミドルウェアの組み合わせを「Apache」+「HHVM(HipHop Virtual Machine)」に変更します。

kusanagi httpd
kusanagi hhvm

 abコマンドを実行します。ここでは以下のコマンドを、10秒間隔で12回実行します。実行回数を増やした理由は、バイトコードを作成しながらJITコンパイルを行って効率化していくHHVMの特性から、ウォームアップに時間がかかるためです。2度目以降の実行で、だんだんページのロード時間が速くなっていきます。

ab -n 300 -c 30 http://ec2-xxx.xxx.compute.amazonaws.com/

 筆者の環境では、12回目の実行で1秒当たりの同時アクセス数が「193.12」となりました。

(4)KUSANAGIベンチマーク:Nginx+HHVM環境

 続いて、ミドルウェアの組み合わせを「Nginx」+「HHVM」に変更します。

kusanagi nginx

ミドルウェアの組み合わせを「Apache」+「HHVM」に切り替えるKUSANAGIコマンド(kusanagi hhvmは(3)で設定済みのため省略)

 abコマンドを実行します。ここでは以下のコマンドを、10秒間隔で3回実行します。

ab -n 300 -c 30 http://ec2-xxx.xxx.compute.amazonaws.com/


 筆者の環境では、3回目の実行で1秒当たりの同時アクセス数が「200.08」となりました。

(5)KUSANAGIベンチマーク:Nginx+HHVM+ページキャッシュを導入

 続いて、(4)の環境から「ページキャッシュを有効」にします。ここでは、KUSANAGI専用プラグインのページキャッシュである「bcache」を有効にします。

kusanagi bcache on

 abコマンドを実行します。このテストでは、測定値の揺らぎを抑えるために、リクエスト数を300から10000に、同時接続数を30から100に引き上げて、次のコマンドを10秒間隔で3回実行します。

ab -n 10000 -c 100 http://ec2-xxx.xxx.compute.amazonaws.com/

 筆者の環境では、3回目の実行で1秒当たりの同時アクセス数が「2048.26」まで向上しました。

(6)KUSANAGIベンチマーク:Nginxの「FastCGIキャッシュ」を有効にする

 最後に、Nginxの「FastCGIキャッシュ」を有効にしてベンチマークを測定します。次のコマンドでNginxのFastCGIキャッシュを有効にします。

kusanagi fcache on

 abコマンドを実行します。次のコマンドを10秒間隔で3回実行します。

ab -n 10000 -c 100 http://ec2-xxx.xxx.compute.amazonaws.com/

 筆者の環境では、3回目の実行で1秒当たりの同時アクセス数が「19160.72」となりました。

 以前行ったチューニングの結果と比べてみます。

 若干の差異はありますが、過去に実施した高速化テクニックのベンチマークと比べ、おおむね似た傾向の結果を示すことを確認できました。過去に実施した高速化テクニックは、1つ1つの行程こそ難しくはありません。しかし、全てを実践するのは若干の手間と時間がかかります。この作業をすっ飛ばして、“いきなり高速”かつ“最新状態”のWordPress環境を構築できるのがKUSANAGIの大きなメリットです。

 次回は、KUSANAGIをもっと活用していく「応用編」として、最近話題の「常時SSL」、高速な通信プロトコルの「HTTP/2」、無償で利用可能なSSL証明書の「Let’s Encrypt」などを導入する方法を解説する予定です。お楽しみに。

●筆者紹介 中村けん牛:1971年栃木県生まれ。中学1年生で電波新聞社の『マイコンBASICマガジン』にプログラムを寄稿して以来、プログラミング歴30年。早稲田大学法学部を卒業後、野村證券に入社。公認会計士第二次試験合格。2002年にプライム・ストラテジー株式会社を設立、代表取締役に就任する。2005年にPT. Prime Strategy Indonesiaを設立して以来、アジアでのITビジネスに携わる。執筆監訳書籍に『WordPressの教科書』シリーズ(SBクリエイティブ)、『詳解 WordPress』『WordPressによるWebアプリケーション開発』(ともにオライリー・ジャパン)などがある。

最終更新:8月26日(金)5時10分

@IT