「ちゃんとやるだけ」大規模ECサイト（その３）
さて、前回に引き続き「大規模ECサイトで一番に気になること≒処理速度」という話。
以前より話に挙げさせていただいている大規模ECサイトですが。
実装当初、実際に動かしてみると、
色んなところで「重たい」「遅い」「動かない」との悲鳴が続々と…
しかも前回お話したアクセラレータやクエリキャッシュは有効。
更にサーバにつきましては前々回お話した―――
この環境下なら十中八九、問題はアプリケーション側だ
と、断言できるほどのスペック。
「流石に『素のEC-CUBEのまま』では何かと無理があるのか…？」そんな状態から、
「実際にカスタマイズしたポイント」について幾つか書いていこうかと思います。
さて、流石に商品件数が商品件数ということで（150k）、
これだけ多くなりますと、それに対する更新もかなりの数に。
また連日、新商品，中古商品も入ってきます。
更に「特定の条件に該当する商品だけ値段改正」なんてことも含め、
運営スタッフによる日々の更新作業も、かなりの量に。
そんな中―――
・CSVによる商品情報の一括登録，更新が遅い。
・途中で画面が真っ白に。
・管理ページ側で作業するとサイト側が重い。
と言った悲鳴をいただきました。
そこで商品情報CSVのインポート部分を確認してみましたところ問題点が。
その中から少々、例を挙げますと―――
—————————————–
【１】よくある「ループの中のselectは可能な限り…」
従来の商品情報から更に「メーカー」「シリーズ」「ジャンル」など、多くの項目を追加。
同時におよびその項目のマスタとなるテーブルを追加。
よって登録の際に―――
CSVから行を取得。
↓
その中の特定の項目について、その値がマスタにあるか確認。
↓
存在していなければ新たなレコードとして登録。
としている箇所が多数。
よってCSV１行毎に「select,insert,update」が煩雑な手順で何度も行なわれることに。
この辺りの処理周りについて「selectは可能な限りループ外へ」など、
「DBへのアクセス回数を減らす」という、基本的な方向で最適化しました。
—————————————–
【２】「CSV１行単位でbegin,comit」の是非
これは「一長一短」だと思います。
確かに１行単位でbegin,comitすると途中で止まった場合も、
CSVファイルの途中までは登録されている…それを利点と判断するケースもあります。
ただ大規模になり、一回での商品登録数が多くなってしまうと―――
・「失敗したら全部やり直し」でもいいから一気に大量に登録したい
・中途半端にやられると、それはそれで面倒に…
と言ったケースおよびクライアントの要望もあったりします。
今回につきましてはクライアントの希望を踏まえ、
「最初と最後でのみbegin,commit」としました。
まぁ、この辺りのやりとりこそ「カスタマイズ」足る所以だと思います。
—————————————–
このような対応を重ねたところ、
ひどい時は「1000件で15分」だったのが「2000件で1分」くらいになりました。
今なら一気に１万件やられても特に問題ありません。
ちなみに今回は「CSV商品登録」を例として挙げさせていただきましたが、
同様の対処をすべき箇所は実際には山程ありました。
他にも大きな要因はあったのですが、それはまた次回以降。
というわけで、こうやって振り返ってみると、
Webアプリレベルでは本当に「基本的なこと」しかやっていません。
ただ「EC-CUBE１万件の壁（仮名）」という俗説に屈せず、
「ちゃんと」原因を調べて基本的なことを「ちゃんと」やってやれば、
結構なんとかなるものです。（大事なことなので何度も言ってますｗ）
ただ「それ相応」に工数はかさみますので、
そこは…まぁ、御社側で調整してください。（笑）
以前より話に挙げさせていただいている大規模ECサイトですが。
実装当初、実際に動かしてみると、
色んなところで「重たい」「遅い」「動かない」との悲鳴が続々と…
しかも前回お話したアクセラレータやクエリキャッシュは有効。
更にサーバにつきましては前々回お話した―――
この環境下なら十中八九、問題はアプリケーション側だ
と、断言できるほどのスペック。
「流石に『素のEC-CUBEのまま』では何かと無理があるのか…？」そんな状態から、
「実際にカスタマイズしたポイント」について幾つか書いていこうかと思います。
さて、流石に商品件数が商品件数ということで（150k）、
これだけ多くなりますと、それに対する更新もかなりの数に。
また連日、新商品，中古商品も入ってきます。
更に「特定の条件に該当する商品だけ値段改正」なんてことも含め、
運営スタッフによる日々の更新作業も、かなりの量に。
そんな中―――
・CSVによる商品情報の一括登録，更新が遅い。
・途中で画面が真っ白に。
・管理ページ側で作業するとサイト側が重い。
と言った悲鳴をいただきました。
そこで商品情報CSVのインポート部分を確認してみましたところ問題点が。
その中から少々、例を挙げますと―――
—————————————–
【１】よくある「ループの中のselectは可能な限り…」
従来の商品情報から更に「メーカー」「シリーズ」「ジャンル」など、多くの項目を追加。
同時におよびその項目のマスタとなるテーブルを追加。
よって登録の際に―――
CSVから行を取得。
↓
その中の特定の項目について、その値がマスタにあるか確認。
↓
存在していなければ新たなレコードとして登録。
としている箇所が多数。
よってCSV１行毎に「select,insert,update」が煩雑な手順で何度も行なわれることに。
この辺りの処理周りについて「selectは可能な限りループ外へ」など、
「DBへのアクセス回数を減らす」という、基本的な方向で最適化しました。
—————————————–
【２】「CSV１行単位でbegin,comit」の是非
これは「一長一短」だと思います。
確かに１行単位でbegin,comitすると途中で止まった場合も、
CSVファイルの途中までは登録されている…それを利点と判断するケースもあります。
ただ大規模になり、一回での商品登録数が多くなってしまうと―――
・「失敗したら全部やり直し」でもいいから一気に大量に登録したい
・中途半端にやられると、それはそれで面倒に…
と言ったケースおよびクライアントの要望もあったりします。
今回につきましてはクライアントの希望を踏まえ、
「最初と最後でのみbegin,commit」としました。
まぁ、この辺りのやりとりこそ「カスタマイズ」足る所以だと思います。
—————————————–
このような対応を重ねたところ、
ひどい時は「1000件で15分」だったのが「2000件で1分」くらいになりました。
今なら一気に１万件やられても特に問題ありません。
ちなみに今回は「CSV商品登録」を例として挙げさせていただきましたが、
同様の対処をすべき箇所は実際には山程ありました。
他にも大きな要因はあったのですが、それはまた次回以降。
というわけで、こうやって振り返ってみると、
Webアプリレベルでは本当に「基本的なこと」しかやっていません。
ただ「EC-CUBE１万件の壁（仮名）」という俗説に屈せず、
「ちゃんと」原因を調べて基本的なことを「ちゃんと」やってやれば、
結構なんとかなるものです。（大事なことなので何度も言ってますｗ）
ただ「それ相応」に工数はかさみますので、
そこは…まぁ、御社側で調整してください。（笑）
