> ただ, 2.11 デフォルトでも, 極端にパフォーマンスが悪いわけではないので, 中小規模の店舗なら, あまり気にならないかなと思ったりします.

規模というよりも、規格を使用するか否かで、大きく分かれる状況のように感じています。(実際には、商品規格のボリュームも強く関与しそうです。)


> また, パッチ版の方は, DB にそれなりの実行コストがかかっているので, I/O の遅い共有サーバーなどでは不利なのかもしれません.

ここで言う「I/O」とは、DB サーバのディスクの I/O のうち Read 側だと思いますが、パッチを当てた方が DB のディスクの読み込み量は少ないような・・・

[パッチ無し] 316ブロック
[パッチ有り] 288ブロック

※ PostgreSQL 9.0.3 再起動後1発目の実行を計測。


> 2.11 デフォルトの方は, 規格を3階層以上にするというカスタマイズの余地を残したデータ構造ですので, 2階層までの固定であれば, もうちょっと良いパフォーマンスを出せると思います.

そうですね。私も、今回関連する実装を査読していて、そう感じる部分がありました。

ただ、2階層で木構造というのは、無駄が大きい印象を持ちます・・・


本題からは脱線しますが「商品管理＞商品登録CSV」辺りのパフォーマンスも、差があるように感じました。

非常に大雑把なものですが、1万件(商品規格なし)の商品登録で、下記のような感じでした。

[パッチ有り] 風呂に入っている間に処理が完了していた (注: 私は長風呂です)
[パッチ無し] 風呂を上がってからひと仕事している間では完了せず。寝て起きたら完了していた。

また、データ生成スクリプトの実行時間にしても、2.5倍以上の違いがありました。


> また, Webサーバーをスケールできるような環境であれば, 2.11 デフォルトの方が有利かもしれません.

スケールアウトするのが妥当な程度にアクセスがある場合、その確率は否定できないと思います。

しかし、パッチ有りの場合、逆の発想で DB サーバをスケールアウトする事で、高速化できると思います。

実際に、インテグレートパートナー企業でも事例があるようですし。

ちなみに、先日の EC-CUBE パートナー新年会で得た情報ですが、某大手ホスティング企業が EC-CUBE の利用を見据えて、DB スケールアウトのソリューションの提供に向けて動き出したらしいです。


> 個人的には, どちらも甲乙つけがたく, できれば複数カテゴリのソート時のパフォーマンスなど, もっとボトルネックの大きいところにパワーを注いだ方がいいんじゃないかなと思いますが, いかがでしょうか?

一応、データ生成スクリプトで生成した環境で、処理毎のコストを計測し、一番のボトルネックは規格であるという分析結果に基づき、改善を試みています。そして、冒頭に記載の通り、一定の改善が見込める事を確認しています。

ただ、「規格」を使用していない環境では (商品一覧画面のパフォーマンスに限定して言えば) 大差がなさそうだという事も分かっているので、EC-CUBE の利用者が規格をどの程度利用しているかというのはありますね。

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

株式会社ロックオンの梶原でございます。

議論に入るのが遅くなり申し訳ございません。
そろそろ収束もさせていきたく、積極介入していきたいと思います。

まず、今回2.12の方針を簡単にですが提示させていただきます。

○木構造の変更がありか無しかで言いますと、「あり」です。

　ただし、条件付きです。

　・1万点を超えるような商品点数であっても正常に表示されること
　　⇒大規模店舗対応はECの宿命のようなところもあり、またそこが弱いとそもそも使用アプリケーション
　　　として選択されないので大規模店舗対応は必須条件です。
　　　仮に、木構造を破棄して、速度劣化したとしても大幅でなければ問題はありません。

　・2.11のモジュール（特に決済モジュール）の大幅な改訂が不必要なこと
　　⇒2.11で大幅にソースとDB構造を修正したばかりで、現時点では外部連携モジュールに大幅な修正が
　　　必要なソース改変は2.12で入れない予定でいます。
　　　ここは、程度によりけりです。


EC-CUBEはオープンソースですので、より良くなるのであればそれを否定するということはないです。
シンプルで見通しのよい作りというのも望むところですので、是非ともそうなればと思います。
ただ、各種モジュールと歩調を合わせて展開をしていく必要もあり、どうしてもバージョンごとでの
制限が入ってしまう可能性があること、ご了承いただければと思います。

また、質問等随時受け付けますので、より良い落とし所を皆さんと探っていければと思います。

引き続き、よろしくお願いします！

Seasoft 様
部分的で恐縮ですが, とり急ぎ,

引用：

データ生成スクリプトの PRODUCTS_VOLUME(商品の生成数) のデフォルト値は 100 ですが, 5000 くらいにした場合はいかがでしょうか?
100 くらいでは, 規格がボトルネックになると思いますが, *_CATEGORIES_VOLUME を増やしたり, PRODUCTS_VOLUME が 1000 以上になると, 変わってくるのかなと思います.

> 100 くらいでは, 規格がボトルネックになると思いますが, *_CATEGORIES_VOLUME を増やしたり, PRODUCTS_VOLUME が 1000 以上になると, 変わってくるのかなと思います.

パッチの内容がボトルネックになるという推測でしょうか?

もしも、無関係な(パッチの有無によらず存在する)部分がボトルネックになるという推測でしたら、その観点で議論する意味は薄いような・・・


# SSD 環境で開発しているので、正直無意味に負荷を掛けたくないです。

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

>　・1万点を超えるような商品点数であっても正常に表示されること
>　　⇒大規模店舗対応はECの宿命のようなところもあり、またそこが弱いとそもそも使用アプリケーション
>　　　として選択されないので大規模店舗対応は必須条件です。
>　　　仮に、木構造を破棄して、速度劣化したとしても大幅でなければ問題はありません。

1万商品(規格なし)では誤差程度(約5%の改善)でした。

個人的に18万件台で実用的な速度を得たいネタがあるので、どこかしらのタイミングで検証したいとは思っています。


>　・2.11のモジュール（特に決済モジュール）の大幅な改訂が不必要なこと
>　　⇒2.11で大幅にソースとDB構造を修正したばかりで、現時点では外部連携モジュールに大幅な修正が
>　　　必要なソース改変は2.12で入れない予定でいます。
>　　　ここは、程度によりけりです。

とりあえず r21418 の内容で評価をいただけると幸いです。

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

引用：

バッチではなく, 具体的には商品データを抽出している部分です.
1カテゴリ分の product_id を IN 句につっこんで検索している部分です.
おそらく, 1000件以上になると, 特に MySQL で顕著にパフォーマンスが低下してくると思います.

引用：
この部分は複数カテゴリ商品のカテゴリ毎の商品の並び順を活かすための処理ですよね？

カテゴリ毎に商品の並び替えが出来るっていう仕様をとるのか
大規模店舗対応向けに検索パフォーマンスアップを選択するのか。

個人的には「大規模店舗対応向けに検索パフォーマンスアップ」を希望します。

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

株式会社ロックオン 梶原様

先日書きました、18万商品の件を実際に試してみました。

デフォルト順: 14.76秒
価格順: 7.93秒
新着順: 10.78秒
(いずれも安定状態で3回計測した平均値)

主要なデータ状態:
dtb_products: 18.9万行
dtb_product_categories: 94.4万行
dtb_products_class: 26.0万行

環境:
EC-CUBE 2.12.0-dev
サーバーOS Windows NT SEVEN 6.1 build 7600
DBサーバー PostgreSQL 9.0.3 (チューニング無し)
WEBサーバー Apache/2.2.16 (Win32) mod_ssl/2.2.16 OpenSSL/0.9.8l PHP/5.2.17
PHP 5.2.17 (bcmath, calendar, com_dotnet, ctype, date, filter, ftp, hash, iconv, json, odbc, pcre, Reflection, session, libxml, standard, tokenizer, zlib, SimpleXML, dom, SPL, wddx, xml, xmlreader, xmlwriter, apache2handler, curl, gd, mbstring, mysql, mysqli, openssl, pgsql, zip, xdebug)
GD 有効 (GD Version => bundled (2.0.34 compatible), FreeType Support => 1, FreeType Linkage => with freetype, T1Lib Support => 1, GIF Read Support => 1, GIF Create Support => 1, JPG Support => 1, PNG Support => 1, WBMP Support => 1, XPM Support => , XBM Support => 1, JIS-mapped Japanese Font Support => )

筐体:
Panasonic Let's note CF-J9LY1AHR (10.1型液晶 B5サイズノートPC)
・Windows 7 64bit に変更
・メモリー 2GB増設
・アプリケーションサーバ・DBサーバ・クライアント兼用

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

株式会社ロックオン 梶原様

連投でスイマセン。

さらにロジックを調整したところ、デフォルト順で10秒を切りました。
ついでに実験した、product_id 降順に至っては3.1秒程度でした。

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

Seasoftさん

性能調査ありがとうございます！

もし、可能な方がいらっしゃれば、やはりMySQLでの性能が知りたいです。
Postgresでは速いことは分かっており、最近EC-CUBEの指標をはかるうえではMySQLの性能をみて
判断していますので。

あと、パッチを確認してみました。
パッチをざっと見た限りではProduct系の処理以外ではあまり影響がないように見えます
（決済モジュールもあまり影響しないですね、おそらく）が、あれで全てですか？
他、影響が出て修正すべき部分がないかご確認いただければありがたいです。


ちなみに、正直なところ、2.11から2.12へのバージョンアップにおいてDBの変更はしない予定でいました。
ですが、今回2.12にてプラグイン機能を搭載しますと、以降は少なくともEC-CUBE2系の中では、DB構造
変更は今以上にむずかしくなると思いますので、今回、大きな変更になりますが、入れるべきかどうか
しっかり検討したいと思います。