Eビジネスを推進するORANGEシリーズ

EC-ORANGE
お役立ち資料ダウンロード ニュースレター登録

「ちゃんとやるだけ」大規模ECサイト(その3)

さて、前回に引き続き「大規模ECサイトで一番に気になること≒処理速度」という話。

以前より話に挙げさせていただいている大規模ECサイトですが。
実装当初、実際に動かしてみると、
色んなところで「重たい」「遅い」「動かない」との悲鳴が続々と…

しかも前回お話したアクセラレータやクエリキャッシュは有効。
更にサーバにつきましては前々回お話した―――


 この環境下なら十中八九、問題はアプリケーション側だ


と、断言できるほどのスペック。
「流石に『素のEC-CUBEのまま』では何かと無理があるのか…?」そんな状態から、
「実際にカスタマイズしたポイント」について幾つか書いていこうかと思います。


さて、流石に商品件数が商品件数ということで(150k)、
これだけ多くなりますと、それに対する更新もかなりの数に。

また連日、新商品,中古商品も入ってきます。
更に「特定の条件に該当する商品だけ値段改正」なんてことも含め、
運営スタッフによる日々の更新作業も、かなりの量に。
そんな中―――


 ・CSVによる商品情報の一括登録,更新が遅い。
 ・途中で画面が真っ白に。
 ・管理ページ側で作業するとサイト側が重い。


と言った悲鳴をいただきました。
そこで商品情報CSVのインポート部分を確認してみましたところ問題点が。
その中から少々、例を挙げますと―――

—————————————–

【1】よくある「ループの中のselectは可能な限り…」
従来の商品情報から更に「メーカー」「シリーズ」「ジャンル」など、多くの項目を追加。
同時におよびその項目のマスタとなるテーブルを追加。
よって登録の際に―――

 CSVから行を取得。
  ↓
 その中の特定の項目について、その値がマスタにあるか確認。
  ↓
 存在していなければ新たなレコードとして登録。

としている箇所が多数。
よってCSV1行毎に「select,insert,update」が煩雑な手順で何度も行なわれることに。
この辺りの処理周りについて「selectは可能な限りループ外へ」など、
「DBへのアクセス回数を減らす」という、基本的な方向で最適化しました。

—————————————–

【2】「CSV1行単位でbegin,comit」の是非

これは「一長一短」だと思います。

確かに1行単位でbegin,comitすると途中で止まった場合も、
CSVファイルの途中までは登録されている…それを利点と判断するケースもあります。

ただ大規模になり、一回での商品登録数が多くなってしまうと―――

 ・「失敗したら全部やり直し」でもいいから一気に大量に登録したい
 ・中途半端にやられると、それはそれで面倒に…

と言ったケースおよびクライアントの要望もあったりします。
今回につきましてはクライアントの希望を踏まえ、
「最初と最後でのみbegin,commit」としました。

まぁ、この辺りのやりとりこそ「カスタマイズ」足る所以だと思います。

—————————————–

このような対応を重ねたところ、
ひどい時は「1000件で15分」だったのが「2000件で1分」くらいになりました。
今なら一気に1万件やられても特に問題ありません。

ちなみに今回は「CSV商品登録」を例として挙げさせていただきましたが、
同様の対処をすべき箇所は実際には山程ありました。

他にも大きな要因はあったのですが、それはまた次回以降。



というわけで、こうやって振り返ってみると、
Webアプリレベルでは本当に「基本的なこと」しかやっていません。

ただ「EC-CUBE1万件の壁(仮名)」という俗説に屈せず、
「ちゃんと」原因を調べて基本的なことを「ちゃんと」やってやれば、
結構なんとかなるものです。(大事なことなので何度も言ってますw)

ただ「それ相応」に工数はかさみますので、
そこは…まぁ、御社側で調整してください。(笑)