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

> あとは正常な動作には影響をあたえるものではないと考えている部分で、いくつか木構造の名残による無駄なコードが残っています。この辺りは、将来に混乱や作業を残すことがないように、対応したいと思っています。

SC_Product.php にいくつか該当するものがありましたので、削除いたしました。

r21496 へのパッチとして、再アップしました。
http://svn.ec-cube.net/open_trac/changeset/21499


あとは、insert_data.sql が若干強引ですが、これは現状で改訂して他のコミットの影響を受けると、パッチの保守が大変になるためです。

この部分は、本体ソースへコミットするタイミングで改修させてください。

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

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

状況に変化がありましたので、改めましてご報告させていただきます。


> パッチをざっと見た限りではProduct系の処理以外ではあまり影響がないように見えます
> （決済モジュールもあまり影響しないですね、おそらく）が、あれで全てですか？

先日未対応だったメソッドを含め、パッチを更新しました。
http://svn.ec-cube.net/open_trac/changeset/21434

2012-1-30 15:54 の記事の内容は、木構造に影響の影響を受けず動作するものですので、別チケットで処理しました。よって、前述のパッチが全てとなります。
http://svn.ec-cube.net/open_trac/ticket/1626

あとは正常な動作には影響をあたえるものではないと考えている部分で、いくつか木構造の名残による無駄なコードが残っています。この辺りは、将来に混乱や作業を残すことがないように、対応したいと思っています。

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

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

> もし、可能な方がいらっしゃれば、やはりMySQLでの性能が知りたいです。

下記記事の方法(1万商品)で、ベンチとってみました。
http://gihyo.jp/design/serial/01/ec_cube2011/0003

[2.12.0-dev r21428 + r21418 のパッチを適用]
商品一覧（あるカテゴリーの1ページ目を15件表示）: 1.78秒

(サーバは前述のノートPCですが、クライアントはリモートに変更しました。)


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

はい。上記ベンチは、そのパッチのみです。

dtb_products_class のキー情報の張替えでは無かったので、結果として改修規模は小さく済みましたね。(個人的には、その構造にも疑問を持っている部分ではありますが・・・。でも今回は楽させてもらいました。)

2012-1-30 15:54 の記事の内容は、さらに手を加えたものとなっていますが、これは木構造以外の部分のチューニングであり、別途のコミットを考えています。

ちなみに、同様のベンチで MySQL 1.6秒を切りそうです。


> 他、影響が出て修正すべき部分がないかご確認いただければありがたいです。

たしか、ベンチマークには影響が無いので実装を省略していたメソッドが1つありますが、小手先で対応できる類だったと思います。


> ですが、今回2.12にてプラグイン機能を搭載しますと、以降は少なくともEC-CUBE2系の中では、DB構造
> 変更は今以上にむずかしくなると思いますので、今回、大きな変更になりますが、入れるべきかどうか
> しっかり検討したいと思います。

プラグインが今後の EC-CUBE 本体の開発の妨げになりそうというのは、残念ですね・・・

私の実装は、小手先でできる範囲で粘ったものですが、他のコミッターさんはではもっと根本的な部分からといった案もあったようなので。

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

Seasoftさん

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

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

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


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

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

連投でスイマセン。

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

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

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

先日書きました、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
こちらでの投稿は、アイディア程度に留めさせていただいております。
個別案件の作業は有償で承っております。お気軽にご相談ください。

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

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

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

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

引用：

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

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

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

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


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

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

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

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

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

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


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

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