> 勝手な提案ですが、インストール時に「速度検証用データを作成する」みたいなオプションを選ばせて、カテゴリ、商品、規格のそれぞれがN件入るような仕組みがあると便利ですよね。

プラグインとして提供したいという考えはあったりします。

別途として、インストール時のサンプルデータ導入の ON/OFF を選択できると便利かなとも思います。まぁ、全員に半強制的にデータ削除のテストにご協力いただくという、現状の状況も悪くないですが


> ちなみに、皆様方（今回の高速化に携わってる方以外も含め）はどのような件数で速度計測を行っているのでしょうか？

うちの場合は、20万件規模の実データがあるので、それをDBにインポートして使ったりしていました。データ構造の変更に対応できておらず、2.5用にはまだ使えませんが。

サイト固有のデータで試す必要がある場合、CSV でザクっと作る方法も有効です。


あとは、テスト用のデータ生成スクリプトというものも存在しています。たしか、このフォーラム発の。

私も2回ほど使ったことがあります。ただ、データのアサインが微妙に実際の使われ方と差異があったり、ちょっと手を入れないと駄目でした。

で、先日の AMUAMU 様のコミットをチラ見したときに、何かその辺りに手が入っていたような。(期待。期待。)

----------------
Seasoft
こちらでの投稿は、アイディア程度に留めさせていただいております。
個別案件の作業は有償で承っております。お気軽にご相談ください。

勝手な提案ですが、インストール時に「速度検証用データを作成する」みたいなオプションを選ばせて、カテゴリ、商品、規格のそれぞれがN件入るような仕組みがあると便利ですよね。

規格がツリー構造化したので、それぞれの組み合わせを動的に作成するプログラムを組むか、SQLを添付して件数を固定化してしまうか。

いずれにせよ、低スペック機等の事を考えると、AMUAMU さんだけでテストするのは大変なので、出来るだけ沢山の人がテストする必要もありそうですしね。

ちなみに、皆様方（今回の高速化に携わってる方以外も含め）はどのような件数で速度計測を行っているのでしょうか？

----------------
EC CUORE 株式会社クオーレ
カスタマイズ御相談下さい。

一応、修正前後の2.5αで比較した範囲では、MY/PG双方共に速度的には少なからず改善はしているので取りあえずは「よし」だとは思っています。(さらにSC_Queryの調整結果により低スペ環境での動作は相当改善しているはず。）

DB個別分岐によるチューニングは、大幅な改善の方策をする場合かなり大規模な分岐を要するため、今後の足かせになる＆開発労力が必要なのと、今回の要件でも分岐は各処理には書かずDBFactoryにまとめると、たしかあったと思いますので、それもネックになる感じです。
2.5で商品一覧生成がlfDispProductsListとSC_Productの組合せ動作が要求されている中で、さらにDBFactoryにも行ったり来たりだと、カスタマイズのボトルネックにもなりますね・・・。

分岐させるとした場合、クエリの全体構造をMySQL向けには全面変更する感じが最高速になるのは分かっていて、案として頭にはありますが、SC_Productの全面分岐や、MySQL専用テーブル作成なんて事態になりそうな案だったり（苦笑
やりきればPostgreSQL並に近づくでしょう。
※個人的に最近の仕事ではPostgreSQLが9割以上なんで、MySQL EC-CUBEにモチベーションが上がらないというのもあります

INSERT時処理についてですが、昨日のコミットでSC_QueryのINSERT/UPDATE/DELETE（DML)関連は少し高速化と軽量化を図ってみました。もう少し手のつけようがありますが、少しは性能改善したかなと。特に数回実行する処理があった場合は大幅に変わったはずです。
DB周りは得意ジャンルなんで一応トランザクション的処理周りについては後日ゆっくりみたいなとは思っています（たぶん年末ギリギリかな・・・）。

----------------
EC-CUBE公式エヴァンジェリスト
EC-CUBEインテグレートパートナー (株)スピリット・オブ
移転・拡張・高速化・問題解決
各種カスタマイズ・支援依頼承ります。
[url=h

従来 (正式版 2.4.4、コミュニティ版 r18755) と比較したときに、双方のDBで劣りが無く、どちらか片方でも改善されているのであれば、まずは「良し」なのかなと思います。


2.5系では、DB互換を重視した方向で進んでいる状況もあるので、この辺りはブレにならないようにしないといけないですね。

個人的には、PG・MY の個別(分岐)のチューニングは許容範囲だと思いますが、それが今後の足かせになるレベルだと怖いですね。

また、EC-CUBE が向かう道として、他の DB 対応を行なうのかといった部分の議論も必要なのかなと思います。

あと、DB分岐のチューニングで、どの程度のパフォーマンス改善が見込めるかが分かると判断材料の一つになりそうな気がします。


# 未検証ではありますが、シーケンスを使わなくなった事で、DB 互換が高まっている反面、インサート時のパフォーマンスが結構犠牲になっている印象もあります。

----------------
Seasoft
こちらでの投稿は、アイディア程度に留めさせていただいております。
個別案件の作業は有償で承っております。お気軽にご相談ください。

EC-CUBEの要件的な指針が、株式会社ロックオンさんから欲しいですね。

ノンカスタマイズ状態で、カテゴリN件、商品数N件までは耐えれるようにしたい。といった具合に。
その件数から方針が決まるのではないかと思います。

AMUAMUさんが言うように、Mysqlには限界がありますから、件数がMysqlの限界を超えるとコミッターが判断した場合は
「DBによって分岐させてクエリ自体または処理構造自体」を変更させるという方針になると思います。

コミッターが指針を決めて良いのであれば、各件数がどれ位を皆さんが考えているかを相談すれば良いかなと思います。

いかがでしょう？

----------------
EC CUORE 株式会社クオーレ
カスタマイズ御相談下さい。

2.5について、先日の開発合宿時以降、商品数や規格・カテゴリが多いときの商品一覧の高速化について検討を重ねてきましたが行き詰まっています。

商品一覧の生成処理見直しにて、EC-CUBEの悪しき処理として、いの一番に取り上げられるIN句に何百ものproduct_idが並ぶ処理、多いときにはSQLのクエリ長制限に引っかかるような問題も解決し、その他実行処理の最適化も進めたことにより、PostgreSQL環境においては個人的に満足出来る速度、メモリ使用量での動作を得ています。

しかしながら、全くの同一条件・同一環境・同一クエリにおいてMySQL環境では速度が出ません。
具体的にはテストデータ作成スクリプトデフォルト値で作った商品情報において、PostgreSQLにて 0.46秒 で得られるクエリが、 MySQL 5.1.52ですと 17分以上かかるという状態です。(PostgreSQL8.4.5、MySQL5.1.52、メモリ4GB、Core i7-640、Windows XAMPP 64bit環境比較）

※もちろん商品数が少ないときは必要十分な速度が出ます。例えば、MySQLで１カテゴリに１万商品をぶら下げた際の表示は高速化しています（上記環境で45秒、以前はクエリの文字制限に引っかかったりして実行すら不可かな？テストデータの状態自体、特殊なのであれですが・・）。

原因はMySQLが伝統的にORDER BY句に弱いという根本的問題にあり、解決の方法はいくらでもあるのですが、それをすると環境依存したり（バージョン依存やレンサバによって動作不可）、PostgreSQL側の速度が大幅に落ちるという、片方を取れば片方がダメという状態です。

個人的には環境依存をしない実装で、かつ同一SQLへの統一の限界点を感じました。

あとはDBによって分岐させてクエリ自体または処理構造自体を変えないと、中々大幅に高速化するのは現状のDB構造では難しいなと思っています。
またMySQLの将来バージョン開発作業をチラ見していると、色々と大幅見直しがされているようなので先々は徒労に終わりそうな感じもあります（リリースは迷走してるので、いつになるか分かりませんが）。

とりあえず、商品一覧の高速化に対しては当方としては現在のコミット内容で打ち止めです。
どなたか汎用性と高速化を両立するような美しいコードありませんか？

----------------
EC-CUBE公式エヴァンジェリスト
EC-CUBEインテグレートパートナー (株)スピリット・オブ
移転・拡張・高速化・問題解決
各種カスタマイズ・支援依頼承ります。
[url=h