EC-CUBE 開発コミュニティ

> フロント機能 > 【 EC-CUBE 2.12 】商品一覧画面の速度改善(高速化)に関して意見を伺わせてください

フロント機能

投稿者	スレッド
nanasess	投稿日時: 2012/1/24 15:15 対応状況: −−−
神登録日: 2006/9/9 居住地: 投稿: 2313	Re: 【 EC-CUBE 2.12 】商品一覧画面の速度改善(高速化)に関して意見を伺わせてください引用： ECCUOREさんは書きました：しかも、現在の規格仕様だと大規模の方が運用に耐えられないのではないかという報告も上がっているわけで。 EC-CUBEの限界商品数を話題に挙げると規格がついてまといますが、それを商品数だけで表現できるようになったら良いのではないかと。「大規模を妥協」するのではなく、数十点〜数万点と全てのレンジの店舗、開発会社が納得できる設計を目指す為に現状の規格という仕様に固執する必要があるのかという議論が出来たら良いなと思ってます。規格の仕様を見なおした方が良いのではないかという意見には賛成です. ただ, 2.11 では, 規格よりも複数カテゴリのソートの方が, 性能のボトルネックになっていると感じます. 1カテゴリに1000点以上の商品をつっこむと, 性能劣化が顕著ですし.

nanasess	投稿日時: 2012/1/24 15:07 対応状況: −−−
神登録日: 2006/9/9 居住地: 投稿: 2313	Re: 【 EC-CUBE 2.12 】商品一覧画面の速度改善(高速化)に関して意見を伺わせてください Seasoft 様引用： seasoftさんは書きました：とりあえず、冒頭のテストで使用した実装です。(r21417 に対するパッチです。) 一応、データ生成スクリプトも(r21394時点ですが)保守してありますので、冒頭のデータ状態は直ぐに再現できると思います。 http://svn.ec-cube.net/open_trac/browser/branches/version-2_12-dev/patches/no_tree.patch?rev=21418 時間の隙を見て試してみました. (ベンチマークしたデータをまとめきれてないので, 以下は感覚値での所感です. また, あくまでも個人的な意見ですので, あらかじめご了承ください) 2.11 デフォルトでは, 規格のデータを生成するのに PHP で木構造を作っていたのですが, その部分が SQL で削減された感じですね! 結果としては, パッチを当てた方が高いパフォーマンスを出していました. 以下のような環境です. `EC-CUBEバージョン 2.11.5-dev PHPバージョン PHP 5.3.8 DBバージョン MySQL 5.1.57-log CPU Core2Duo 2.66GHz メモリ 4G OS Mac OS X 10.7.2` PHP で頑張るか, DB で頑張るかの違いだと思うので, VPS や共有サーバーを使用した, 中小規模のサイトでしたら, パッチ版の方が優れていると思います. ただ, 2.11 デフォルトでも, 極端にパフォーマンスが悪いわけではないので, 中小規模の店舗なら, あまり気にならないかなと思ったりします. また, パッチ版の方は, DB にそれなりの実行コストがかかっているので, I/O の遅い共有サーバーなどでは不利なのかもしれません. 2.11 デフォルトの方は, 規格を3階層以上にするというカスタマイズの余地を残したデータ構造ですので, 2階層までの固定であれば, もうちょっと良いパフォーマンスを出せると思います. また, Webサーバーをスケールできるような環境であれば, 2.11 デフォルトの方が有利かもしれません. 個人的には, どちらも甲乙つけがたく, できれば複数カテゴリのソート時のパフォーマンスなど, もっとボトルネックの大きいところにパワーを注いだ方がいいんじゃないかなと思いますが, いかがでしょうか?

ECCUORE	投稿日時: 2012/1/20 17:51 対応状況: −−−
長老登録日: 2009/10/22 居住地: 東京投稿: 248	Re: 【 EC-CUBE 2.12 】商品一覧画面の速度改善(高速化)に関して意見を伺わせてください引用： nanasessさんは書きました：あくまでも感覚値ですが, トラフィックの多い店舗の多くは, 数千点の商品はめずらしくなく, そういった店舗では dtb_products_class も数万〜数十万レコードに及ぶと思います. EC-CUBE の普及と発展のためには, そういった大規模運用に耐えられるような方向にする必要があるのではないかなぁと. 確かに, 数百点までの店舗が圧倒的多数だと思いますが, 大規模を妥協して, 中小のニーズに応えるような対応は, ちょっと微妙なのかなと... 「大規模を妥協をしよう」とは誰も思っていないのではないかと思います。ただ、現状の「大規模（仮定シェア1%）を考慮したがために、中小規模（仮定シェア99%）の人が影響を受ける」設計は嫌だな〜って思ってる人が私を含めて最低でも数人？いるという事なんじゃないでしょうか。しかも、現在の規格仕様だと大規模の方が運用に耐えられないのではないかという報告も上がっているわけで。 EC-CUBEの限界商品数を話題に挙げると規格がついてまといますが、それを商品数だけで表現できるようになったら良いのではないかと。「大規模を妥協」するのではなく、数十点〜数万点と全てのレンジの店舗、開発会社が納得できる設計を目指す為に現状の規格という仕様に固執する必要があるのかという議論が出来たら良いなと思ってます。 ---------------- EC CUORE 株式会社クオーレカスタマイズ御相談下さい。

seasoft	投稿日時: 2012/1/20 15:16 対応状況: −−−
神登録日: 2008/6/4 居住地: 投稿: 7367	Re: 【 EC-CUBE 2.12 】商品一覧画面の速度改善(高速化)に関して意見を伺わせてください > あくまでも感覚値ですが, トラフィックの多い店舗の多くは, 数千点の商品はめずらしくなく, そういった店舗では dtb_products_class も数万〜数十万レコードに及ぶと思います. 私どもでこれまで扱った EC-CUBE サイトは200店舗以上あり、中には数千商品規模の商品規模もありましたが、その商品規模で規格を使っているサイトは1店舗だけだったような気がします。(ちなみに、EC-CUBE 2.4 系) 数値的には0.5%未満かなと。あくまでも私の経験の中なので、参考まで。そして、そういった要求に対応させるのであれば、やはり現状の「規格」の枠ではなく、別の方法で対応するのが良いように感じます。 ---------------- Seasoft こちらでの投稿は、アイディア程度に留めさせていただいております。個別案件の作業は有償で承っております。お気軽にご相談ください。

nanasess	投稿日時: 2012/1/20 14:04 対応状況: −−−
神登録日: 2006/9/9 居住地: 投稿: 2313	Re: 【 EC-CUBE 2.12 】商品一覧画面の速度改善(高速化)に関して意見を伺わせてください引用： seasoftさんは書きました：とりあえず、冒頭のテストで使用した実装です。(r21417 に対するパッチです。) 一応、データ生成スクリプトも(r21394時点ですが)保守してありますので、冒頭のデータ状態は直ぐに再現できると思います。 http://svn.ec-cube.net/open_trac/browser/branches/version-2_12-dev/patches/no_tree.patch?rev=21418 ありがとうございます! 週末にでも時間を見つけて見てみます. 引用： > 商品規格数(dtb_products_class)が数十万レコードになった場合など興味深いですね! そっち方向ですか!? なるほど。それが「大多数」の向きかは、ともかくとして・・・(笑) あくまでも感覚値ですが, トラフィックの多い店舗の多くは, 数千点の商品はめずらしくなく, そういった店舗では dtb_products_class も数万〜数十万レコードに及ぶと思います. EC-CUBE の普及と発展のためには, そういった大規模運用に耐えられるような方向にする必要があるのではないかなぁと. 確かに, 数百点までの店舗が圧倒的多数だと思いますが, 大規模を妥協して, 中小のニーズに応えるような対応は, ちょっと微妙なのかなと...

seasoft	投稿日時: 2012/1/20 12:05 対応状況: −−−
神登録日: 2008/6/4 居住地: 投稿: 7367	Re: 【 EC-CUBE 2.12 】商品一覧画面の速度改善(高速化)に関して意見を伺わせてください nanasess 様 > 実際に, どんな実装になるか見せていただければ, ある程度は想定できるかもしれません. とりあえず、冒頭のテストで使用した実装です。(r21417 に対するパッチです。) 一応、データ生成スクリプトも(r21394時点ですが)保守してありますので、冒頭のデータ状態は直ぐに再現できると思います。 http://svn.ec-cube.net/open_trac/browser/branches/version-2_12-dev/patches/no_tree.patch?rev=21418 ---------------- Seasoft こちらでの投稿は、アイディア程度に留めさせていただいております。個別案件の作業は有償で承っております。お気軽にご相談ください。

seasoft	投稿日時: 2012/1/20 11:34 対応状況: −−−
神登録日: 2008/6/4 居住地: 投稿: 7367	Re: 【 EC-CUBE 2.12 】商品一覧画面の速度改善(高速化)に関して意見を伺わせてください nanasess 様 > 商品規格数(dtb_products_class)が数十万レコードになった場合など興味深いですね! そっち方向ですか!? なるほど。それが「大多数」の向きかは、ともかくとして・・・(笑) その方向の場合にパフォーマンスが良くなるとしたら、たしかに興味深いです。 > 標準実装としては, できるだけ DB 依存の処理は避けたいですね... > 以下のような記事もありますので, 全く効果の実証がされてないわけではないと思います. > > http://gihyo.jp/design/serial/01/ec_cube2011/0003 この記事は私も読んでいますが、あくまでも 2.4.4 正式版との比較なので、本件の参考になるのかは懐疑的です。(2.4 コミュニティ版との比較ならば、ある程度の意味を持つかも。) また、冒頭のテスト結果なども加味すると、木構造以外の部分でもパフォーマンス改善が図られているのではとも推測しています。 > 個人的には, もっとオブジェクト指向を取り入れて, できるだけ SQL を意識しなくても良い実装になってくれば, データ構造や実装の複雑さは解消されてくるのかなと思っています. 構造的に整うのは理解できるのですが、DB 処理の効率の良さを、PHP でカバーするのは結構厳しいような。スケールアウトとか可能な規模のサイト構築案件なら、それも良いのすが、EC-CUBE の利用者層を考えると、不利益にならないか心配です。 ---------------- Seasoft こちらでの投稿は、アイディア程度に留めさせていただいております。個別案件の作業は有償で承っております。お気軽にご相談ください。

seasoft	投稿日時: 2012/1/20 11:02 対応状況: −−−
神登録日: 2008/6/4 居住地: 投稿: 7367	Re: 【 EC-CUBE 2.12 】商品一覧画面の速度改善(高速化)に関して意見を伺わせてください AMUAMU 様 > 個人的にはパラメーターのようなもので、規格の利用有無を一括で切り替える事が出来たら良いなとは思っています。そうですね。表面上は本当に容易くできそうですが、パフォーマンスを考慮する意味だと、「規格無しの場合 dtb_products_class を使わない」という方向ですよね。 # そういえば、昔の DB 構造は、若干それに近かったような。 (ロジックは伴ってい無かったので、歴史的な残骸だっただけかも。) > 現状の2.12-devでも、SC_Product.php系だけの修正で結構行けそうな気がしますたしかに。ただ、開発プロジェクト的には、テストのコストとか結構大きくなりそうな予感も。コアな部分なので、ある程度の手間を掛けるのも妥当かもしれませんが・・・予算がある、パッケージ開発とかだったら、積極的に手を入れるところですが、OSS 開発となると正直ナカナカ・・・ ---------------- Seasoft こちらでの投稿は、アイディア程度に留めさせていただいております。個別案件の作業は有償で承っております。お気軽にご相談ください。

seasoft	投稿日時: 2012/1/20 10:51 対応状況: −−−
神登録日: 2008/6/4 居住地: 投稿: 7367	Re: 【 EC-CUBE 2.12 】商品一覧画面の速度改善(高速化)に関して意見を伺わせてください AMUAMU 様 > dtb_product_classテーブルに持っている内容と、規格自体の面倒な情報が分離されたことによる見通しの良さはあると思います。多分・・・ dtb_products_class.classcategory_id1 dtb_products_class.classcategory_id2 ↓ dtb_products_class.class_combination_id ・・・という事ですよね。数にしたら1つの変化ですが、結合周りがシンプルになるのは大きいかもしれませんね。ただ・・・ dtb_class_combination.class_combination_id dtb_class_combination.parent_class_combination_id dtb_class_combination.classcategory_id (dtb_class_combination.level) ・・・の追加で、効果が相殺されてしまう気もしています。 (個人的には、むしろ 2.4 までの、構造の方がディメンジョンとしては、見通せた気も。今のところ。慣れかもしれませんが、なかなか慣れられない・・・orz) > 規格データ展開自体に速度向上と省力化が明らかにあったと感じたのですが、その後の改修で処理がほうぼうに散ってイマイチ分からなくなった感じですなるほど。情報ありがとうございます。 ---------------- Seasoft こちらでの投稿は、アイディア程度に留めさせていただいております。個別案件の作業は有償で承っております。お気軽にご相談ください。

nanasess	投稿日時: 2012/1/20 9:50 対応状況: −−−
神登録日: 2006/9/9 居住地: 投稿: 2313	Re: 【 EC-CUBE 2.12 】商品一覧画面の速度改善(高速化)に関して意見を伺わせてください引用： seasoftさんは書きました： > 本当に大多数の利用者が速度低下しているかどうかを明らかにできたら良いと思います. そうですね。今のところ、「データ生成スクリプト」で発生させた1パターン × 2DB × 1画面での、ボトルネックを特定したという段階ですので、実際には他のデータパターン・動作環境・画面でのデータ収集もできると良いと思います。商品規格数(dtb_products_class)が数十万レコードになった場合など興味深いですね! 引用： > PostgreSQL では使用できますが MySQL では使用できません. 例えば、PostgreSQL のみ使用するような最適化は難しいでしょうか? EC-CUBE の標準実装として非現実的で、効果の実証もされていないのであれば、やはり疑問を抱いてしまいます。標準実装としては, できるだけ DB 依存の処理は避けたいですね... 以下のような記事もありますので, 全く効果の実証がされてないわけではないと思います. http://gihyo.jp/design/serial/01/ec_cube2011/0003 引用：ただ、「抜本的」にという方向が現実的ならば、現状の規格をベースに議論するよりも、その方向に注力した方が良いかもという気持ちも出てきています。 2.11 にする際に, いろいろ詰め込みすぎて, 中途半端な状態になっているのも正直な話です. 引用：有利なのかを検証してから、組み入れても良かったのではないかと思います。しっかり検証したいのも山々なのですが, スケジュールや政治的なお話の兼ね合いもあり, なかなか難しいのが現実です... 引用：ただ結果として、今の自分に見通せる範囲の中では、本件画面のパフォーマンスに限らず、データ構造や実装の複雑さとして、2.11 でコスト増になった部分だと感じています。個人的には, もっとオブジェクト指向を取り入れて, できるだけ SQL を意識しなくても良い実装になってくれば, データ構造や実装の複雑さは解消されてくるのかなと思っています.

« 1 2 3 (4) 5 6 »