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をインストールしましょう。

 

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

 

  1. 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

“`

 

  1. Apacheを再起動します。

 

“`

systemctl restart httpd.service

“`

 

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

 

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

 

 

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

 

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

 

 

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

 

なお、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では何度か検証を行ってみましたが、高負荷状態ではデータベース接続エラーになってしまうなど、稼働は不安定なものでした。

 

# まとめ

今回のEC-CUBEでの検証では、KUSANAGIといえども、Time per request(1リクエストあたりの処理時間)の値はそれほど高い数値ではありませんでした。これは、ECサイトの特性上、画像を多く使用していることも一因かと思います。

 

しかし、KUSANAGIでは高負荷状態でもエラーになることなく処理できたのに対し、非KUSANAGIでは失敗するケースが多く、サーバーが不安定な状態となりました。安定して稼働することはパフォーマンスと共に重要です。KUSANAGIの安定性についても確認できたかと思います。

 

次回も、KUSANAGIでいろいろ動かしてみたいと思います。それではまた。


Post Author: 小澤 昌樹

小澤 昌樹