はじめに
みなさん、こんにちは。株式会社シオラボの小澤です。「KUSANAGIでいろいろ動かして速さを確認してみた！」も7回目となりました。
前回は、海外製のオープンソースCMS「October」を動かしてみました。この「KUSANAGIでいろいろ動かして速さを確認してみた！」で初めて、PHP7で動くプロダクトを検証してみましたが、PHPバージョンに関わらず、高いパフォーマンス結果を得られることが分かりました。
さて、今回もPHP7で動かしてみます。今回、検証するプロダクトは汎用CMSの「Geeklog（ギークログ）」です。
Geeklog
「Geeklog」は、PHPとMySQLで動作するオープンソースのCMSです。セキュリティギークなCMSとも言われています。コミュニティが活発でドキュメントも充実しているところも特徴的です。
– ブログ機能が充実してSEOの効果が高い。
– 細かな権限設定が可能でセキュリティ関連の機能が強力。
– 利用されるプラグイン等も展開・配置した状態で同梱されており導入後すぐに使える状態にできる。
現在の最新バージョンは、2017年6月22日にリリースされた「2.1.3」です。Geeklog本家と日本語版のリポジトリは、GitHubで公開されています。
Geeklogは、2.1.2からPHP７対応となりましたので、今回の検証でもPHP7を使います。KUSANAGIでは、Apacheのドキュメントルート以下でPHP7を使えるように、以下のコマンドを発行しておきましょう。
“`
kusanagi php7
“`
なお、Geeklogの動作要件は、こちらに記載があります。
# 事前準備
今回も使用する仮想マシンは、AWS用の「KUSANAGI for AWS」です。KUSANAGIの初期設定、KUSANAGIのプロビジョニングを参考に、初期設定とプロビジョニングが完了しているものとします。
KUSANAGIの初期設定では、Webサーバに「Apache」を選択します。
また、データベースにはMariaDBを使います。Geeklogで使用するデータベースと、データベースユーザは事前に作成しておきましょう。ここでは、以下のように作成しました。
“`
mysql -u root -p
MariaDB> CREATE DATABASE geeklog;
MariaDB> GRANT ALL ON geeklog.* to root@localhost;
MariaDB> FLUSH PRIVILEGES;
“`
# 設置とインストール
それでは、Geeklogをインストールしていきましょう。
1. インスタンスにsshログインし、rootになります。
2. Geeklog日本語開発版をGithubリポジトリからクローンします。
“`
git clone https://github.com/Geeklog-Japan/geeklog-japan.git
“`
3. Geeklogのファイルは、公開側と非公開側を分離して配置します。クローンしたgeeklogの中にある「public_html」の下を公開側に配置し、それ以外は非公開側のままとします。
“`
mkdir /var/www/geeklog
mv geeklog-japan/* /var/www/geeklog
mkdir /var/www/html/geeklog
mv /var/www/geeklog/public_html/* /var/www/html/geeklog
“`
4. 非公開側にあるデータベース設定ファイルを修正します。作成したデータベースに合わせて修正しておきましょう。
“`
vi /var/www/geeklog/db-config.php
“`
5. 一旦、Apacheを再起動します。
“`
systemctl restart httpd.service
“`
6. ブラウザで、 `http://(ホスト名)/geeklog/` にアクセスすると、以下のようなインストール画面となります。「install script」をクリックして続行します。
7. 4で修正したファイルの存在を確認されるので、正しいパスを入力して、「次へ」をクリックします。さらに次の画面では、ファイルのパーミッション設定を確認されるので、指示された通りに、ファイルのパーミッションを変更します。
8. 次は「コンフィグレーションモード入力」の画面になります。データベース情報を入力し、「インストール（すべてのプラグインも同時に）」をクリックすると、インストールが始まります。あっという間に終了し、以下の画面が表示されれば、インストールは完了です。この画面は、ほぼGeeklogの公開ページです。
パフォーマンス検証
Geeklogのデフォルトの公開ページを使って、早速パフォーマンスを検証してみましょう。
パフォーマンス検証には、おなじみのApache Benchを使います。
比較検証するのは、KUSANAGIと非KUSANAGIの仮想インスタンスで、AWSのインスタンスタイプは、いずれもt2.medium、PHPなどのソフトウェアのバージョンは揃えてあります。
検証に使用するのは次のようなのコマンドです。このコマンドは、100ユーザ同時に、1ユーザあたり30リクエストを発行する、というものです。
“`
ab -n 3000 -c 100 http://(ホスト名)/geeklog/
“`
検証結果
それでは検証結果です。
||KUSANAGI|非KUSANAGI|
|:–|:–|:–|
|Document Length|17593|17602|
|Complete requests|3000|3000|
|Failed requests|22|144|
|Requests per second [#/sec]|97.41|20.10|
|Time per request [ms]|10.266|49.742|
Requests per second は、秒間にさばけるリクエスト数です。数値が大きいほどよいです。KUSANAGIでは約97リクエストとなりました。対する非KUSANAGIは約20リクエストでした。
Time per request は、1リクエストあたりの処理時間です。こちらは逆に数値が小さいほどよいです。KUSANAGIの約10msに対して、非KUSANAGIは約50ms掛かります。
今回のGeeklogでも、KUSANAGIでは、およそ5倍のパフォーマンスが出せるという結果が得られました。前回のOctoberとほぼ同じ（およそ5.5倍）結果でしたね。
なお、Failed requests（処理に失敗したリクエスト）があったことは少し気になるところです。（未検証）
まとめ
実は、今回レスポンスの数値以外に大きな違いが現れた箇所は、「Percentage of the requests served within a certain time（全リクエストの割合に対する処理が完了した時間）」でした。
KUSANAGI
“`
50% 1021
66% 1041
75% 1052
80% 1059
90% 1078
95% 1100
98% 1181
99% 1384
100% 1986 (longest request)
“`
非KUSANAGI
“`
50% 4901
66% 5031
75% 5119
80% 5178
90% 5363
95% 6154
98% 7408
99% 8174
100% 11250 (longest request)
“`
非KUSANAGIでは、徐々に処理時間が延びています。一方のKUSANAGIでは、負荷が掛かってもそれほど処理時間に違いはありません。これはキャッシュが影響しているのではないかと考えられますが、KUSANAGIは、特別な設定をしなくてもパフォーマンスが出るところは素晴らしいですね。
次回も、KUSANAGIでいろいろ動かしてみます。それではまた！
