2009/9/29

大規模じゃないけど負荷対策


さて、EC-CUBEに限った話でもないのですが。
EC-CUBEでよく使われる画像縮小表示用「resize_image.php」と言えば、
ec-cube扱ったことのある方なら思い当たるかと思います。(実際にはgdthumb)

 
まぁ、正直コレ自体には一切非は無いのですが、
EC-CUBEにおけるresize_image.phpの使い方で先日、少々問題がありまして…
VPSサーバに設置したEC-CUBEのサイトなのですが、
モバイルサイトを公開を機にWebサーバへの負荷が跳ね上がってしまいました。

 

そこでapacheのアクセスログを確認したところresize_image.phpへのアクセスが多数。
なお、このresize_image.phpですが、
画像ファイル名を付与したurlによりhttp経由で自身(Webサーバ)を呼び出し、
そちらで受け取ったファイル名のファイルを、
gdライブラリで修正した画像を出力というシロモノ。
ただし、1回使用する毎にWebサーバのhttpdプロセスが1つ発生してしまいまして、
要は画像1枚だと「1度のページアクセスで2つのhttpdプロセス」となり、
リサイズ表示する画像の数だけhttpdプロセスが多く生じてしまうワケで…
まぁ、「自サーバに置いたAPIを常時使用され続けている」ようなものでしょうか。

 

普通EC-CUBEのモバイル版はPC版で登録した商品画像をresize_image.phpで縮小表示。
とはいえデフォルトのままだと商品詳細画面のメイン画像のみで済むのですが、
一方、そのサイトは画像表示の数が他サイトよりかなり多かったので、
生じるhttpdプロセスの数や結構なものに。

 

というわけで受信データサイズやレイアウトとの兼ね合いを測りながら、
resize_image.phpの使用を抑えてみましたところ、ひとまず負荷は下がったんですが。
時折跳ね上がるという現象がチラホラ。
モバイルサイトだけでなくPCサイトの方も確認して削ってみたのですが、それでも時折跳ね上がる。

そこで再度apacheのアクセスログを確認してみたところ―――

 
 「管理ページ>商品管理>商品マスタ検索結果」

 

しかも「商品マスタ検索結果」に至っては最悪100枚一気に表示。
その時の瞬間LoadAverageや如何に。(;´д`)
仕方ないので全tplファイルを「resize_image」でgrep。

 

 「管理ページ>商品管理>商品並び替え」
 「管理ページ>商品管理>商品情報編集,入力内容確認」

 

など管理ページでも何箇所かで使用され、
そちらからもWebサーバを圧迫していたようで。。。

 

そもそも管理ページ側だと画質も受信データ量も気にする必要は無いので、
ことごとく使用しないようにして、なんとか落ち着きました。


運営者

  • 株式会社エスキュービズム
  • 〒105-0011 東京都港区芝公園2-4-1芝パークビル A館 4階
  • TEL : 03-6430-6730(代表)
  • HP:https://s-cubism.jp/