KUSANAGIでEC-CUBEを動かしてみた！

# はじめに

みなさん、こんにちは。株式会社シオラボの小澤です。「KUSANAGIでいろいろ動かして速さを確認してみた！」の3回目です。

1回目はオープンソースCMSの「MODX」、2回目はオープンソースCMSの「Joomla!」を動かしてみました。圧倒的なKUSANAGIのパフォーマンスが印象に残っていますね。

さて、3回目の今回も、またまたオープンソースのCMSです。ECサイト向けCMSとして非常に有名な「EC−CUBE」を取り上げます。

# EC−CUBE

「EC−CUBE（イーシーキューブ）」は、株式会社ロックオンによって開発されたECサイト構築パッケージ「ECKit」を、誰でも無料で利用できるようにと、オープンソースとして公開されたものです。本格的なネットショップを構築できるCMSとして非常に人気があります。日本語で提供されている情報が多いところも人気の一因でしょう。

EC−CUBEもPHPで動作します。データベースはMySQLかPostgreSQL。Webサーバーは基本的にはApacheです（WindowsではIISも使えます）。ソフトウェア要件は、EC−CUBEサイトの開発情報に記載がありますので確認してみてください。

EC−CUBEの2017年6月時点の最新バージョンは、3.0.14。リポジトリは、GitHubで公開されています。

# 事前準備

今回も使用する仮想マシンは、AWS用の「KUSANAGI for AWS」です。KUSANAGIの初期設定、KUSANAGIのプロビジョニングを参考に、初期設定とプロビジョニングが完了しているものとします。

なお、KUSANAGIの初期設定では、Webサーバに「Apache」、アプリケーションサーバに「PHP5」を選択しています。

また、データベースにはMySQLを使い、EC-CUBEで使用するデータベースとユーザも事前に作成しておきます。

# インストール

それでは、早速EC-CUBEをインストールしましょう。

インスタンスにsshログインし、rootになります。

EC-CUBEのダウンロードページから最新版をダウンロードし解凍します。解凍したディレクトリごとドキュメントルートの下に移動します。

“`

wget http://downloads.ec-cube.net/src/eccube-3.0.14.zip

unzip eccube-3.0.14.zip

mv eccube-3.0.14 /var/www/html/eccube

“`

Apacheを再起動します。

“`

systemctl restart httpd.service

“`

ブラウザで、 `https://(ホスト名)/eccube/html/` にアクセスすると、以下のようなインストーラー画面が表示されます。

この段階で、必要なPHPモジュールが足りていない場合は警告が出ます。適切にインストールしましょう。

あとはインストーラの指示に従って、インストールを進めましょう。

「インストールが完了しました！」が表示されれば完了です。

「管理画面」ボタンを押すと管理画面へのログイン画面となります。

なお、mod_rewriteが正しく設置されていない場合は、画面が表示されません。その場合は、`https://(ホスト名)/eccube/html/index.php/admin` のようにURLを変更すると表示されます。

# パフォーマンス検証

EC-CUBEではデフォルトでインストールされる公開サイトがあります。今回はその公開サイトを使ってパフォーマンス検証してみましょう。

パフォーマンス検証には、今回もおなじみApache Benchを使います。

比較検証するのは、KUSANAGIと非KUSANAGIの仮想インスタンスで、AWSのインスタンスタイプは、いずれもt2.mediumとし、PHPなどのソフトウェアのバージョンは当然揃えてあります。

検証は以下のコマンドです。このコマンドは、100ユーザ同時に、1ユーザあたり30リクエストを発行する、というものです。

“`

ab -n 3000 -c 100 http://(ホスト名)/eccube/html/

“`

# 検証結果

早速、検証結果です。

||KUSANAGI|非KUSANAGI|

|:–|:–|:–|

|Document Length|18809|18805|

|Complete requests|3000|3000|

|Failed requests|0|2871|

|Requests per second [#/sec]|16.83|15.92|

|Time per request [ms]|59.428|62.799|

まず、KUSANAGIの結果を見てみましょう。

Requests per second は、秒間にさばけるリクエスト数です。KUSANAGIでは約16リクエストとなりました。

Time per request は、1リクエストあたりの処理時間です。KUSANAGIでは約59ms掛かっています。

一方の非KUSANAGIですが、Failed requestsが2871となりました。すべてLengthエラーで失敗しています。これは、レスポンスの Document Length が一致していない場合にカウントされるもので、サーバーが処理をしきれず接続を切った可能性があります。よって、ここに表示された Requests per second などは参考にならないです。

非KUSANAGIでは何度か検証を行ってみましたが、高負荷状態ではデータベース接続エラーになってしまうなど、稼働は不安定なものでした。