「ちゃんとやるだけ」大規模ECサイト（その２）

さて、Webアプリ本体の話に入るワケですが、
EC-CUBEをベースとして大規模ECを構築する以上、
やはり誰しも気になるのは「処理速度」だと思います。
（まぁ、コレはどのWebアプリにも言えるコトなんですけども）

実際にこの問題を解決する上での対策と言いますと、よくあるケースとしては―――

　・Webアプリ内での処理の最適化
　・DBアクセス時のクエリ最適化
　・DB,Webサーバチューニング
　・実務オペレーションとの調整による処理の削減
　・PHPアクセラレータ投入


といったトコでしょうか。

その中で、まず「PHPアクセラレータ」
まぁ、効果の大小がcase-by-caseな面もあるかとは思いますが、その効果を検証した際―――


　「とりあえず普通にインストールしてみた」
　「設定は、ほぼデフォルト」
　「素のEC-CUBEに幾つか商品を登録したもので比較検証」


としてみただけでも、そこそこ効果を発揮してくれます。
それこそ真面目に使えば、結構な効果を発揮してくれるハズです。

あと「DB,Webサーバチューニング」なんですが、
当然これも適切に設定するか否かで怖ろしく変わってきます。
またmysqlだとクエリキャッシュ（PostgreSQLだと共有バッファ？）で、
DBアクセスそのものを省略できたりとかします。


というワケで何かと便利なんですけど、これらを使用する際において、
非常に基本的なんですが注意すべきことが１点ありまして。
それが―――


　開発，動作検証時は、なるべくoffにしておく


ということ。
まぁ、言わずとも解ってらっしゃる方もいらっしゃるとは思いますが。

先に（前々回）ご紹介した大規模ECサイトの開発において、
かなり早い段階からそれらを有効にしていた為、
本来アプリ作成において最も注力せねばならないポイントである―――


　「Webアプリ内での処理の最適化」
　「DBアクセス時のクエリ最適化」


に依る「処理速度の問題」が浮上するのが非常に遅くなってしまいました。
まぁ、実際にどのような問題が浮上したのかにつきましては次回以降に触れるとして。

Webアプリ本体以外の要因で処理速度の向上が見込めるとしても、それを使用するのは、
「当のWebアプリ本体に対して、やれることをやってから」とすることをオススメします。

喩えるなら―――


　カードを切る順番は、ちゃんと考えよう。


といったところでしょうか。
でも、これらも結局は「技術者として本来やるべきこと」を「ちゃんと」やっているだけだったりします。

というワケで、どちらかかというとWebアプリ云々より、
「開発の進め方」云々の話になってしまいましたが、その辺りは気にしない方向で。