EC-CUBE 開発コミュニティ

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

フロント機能

投稿者	スレッド
seasoft	投稿日時: 2012/1/17 13:33 対応状況: −−−
神登録日: 2008/6/4 居住地: 投稿: 7367	Re: 【 EC-CUBE 2.12 】商品一覧画面の速度改善(高速化)に関して意見を伺わせてください ECCUORE様ご回答・ご意見ありがとうございます。 > また規格の仕様について再検討して頂けると嬉しいです。 > その場合、木構造というよりも規格の仕様を議論する必要があるのかと思いますがいかがでしょうか。たしかに、そのとおりですね。具体的な問題の観点を挙げていただき、改めて考えますと、AMUAMU 様の「ゼロから」や nanasess 様の「抜本的な」といった方向に繋がっていきそうですね。本題から脱線してしまいますが、参考程度に書きますと、個人的には下記のような感じです。 > ・規格毎に価格を設定できる必要があるのか。過去に扱った案件で直ぐに思いつく範囲ですと、「1商品に複数の販売価格を持たせる必要はあった。ただし規格である必要はない。所謂『オプション』で用は足りた。」といった状況でした。よって、回答しては「ない」。ただし、実際に外すにあたっては、単階層(複数階層やマトリクスの必要がない)で且つ価格の±を反映できるオプションのようなものを複数追加できる機能が欲しい。 > ・規格は複数階層設定できる必要があるのか。価格に関しては「ない」。在庫については「ある」。アパレルで必要なケースを多々経験しました。n階層の必要はなく、2階層(マトリクス)で十分でした。 > > nanasessさんは書きました： > > 木構造とした場合のメリットは, > > * 規格を2つ以上にしたい場合, 追加しやすくなる > > * SQLで connect by が使えれば速い(はず) > > 規格が2つ以上にできるという事だけがメリットだとすると > 規格が2つ以上設定したいというニーズがどれだけあるのかを考えて、標準仕様に採用するかを検討するべきだったのかと思います。同意見です。(厳密には「3つ以上」ですかね。) > 極端な話ですが、「規格を廃止してもいいから、高速化したい」というカスタマイズ依頼もあります。それは、ありますね！規格が不要なサイトだと、規格が無用の長物でしかないのですよね・・・ 2.12 の目玉機能であろう「プラグイン」で、「規格」を実現とか、難しいですかね。＞プラグインに詳しい方 ---------------- Seasoft こちらでの投稿は、アイディア程度に留めさせていただいております。個別案件の作業は有償で承っております。お気軽にご相談ください。

AMUAMU	投稿日時: 2012/1/17 13:55 対応状況: −−−
神登録日: 2009/5/2 居住地: 東京都投稿: 2712	Re: 【 EC-CUBE 2.12 】商品一覧画面の速度改善(高速化)に関して意見を伺わせてください引用：具体的な問題の観点を挙げていただき、改めて考えますと、AMUAMU 様の「ゼロから」や nanasess 様の「抜本的な」といった方向に繋がっていきそうですね。やはり抜本的な方向で考えるほうが良いんですかね−・・・素案はあるのですが抜本的に変えようとすると実装修正量も膨大で中々難しい。引用： > 極端な話ですが、「規格を廃止してもいいから、高速化したい」というカスタマイズ依頼もあります。それは、ありますね！規格が不要なサイトだと、規格が無用の長物でしかないのですよね・・・個人的にはパラメーターのようなもので、規格の利用有無を一括で切り替える事が出来たら良いなとは思っています。現状の2.12-devでも、SC_Product.php系だけの修正で結構行けそうな気がします引用： 2.12 の目玉機能であろう「プラグイン」で、「規格」を実現とか、難しいですかね。＞プラグインに詳しい方不可能ではないかもしれませんが、現実的には難しいかと ---------------- EC-CUBE公式エヴァンジェリスト EC-CUBEインテグレートパートナー (株)スピリット・オブ移転・拡張・高速化・問題解決各種カスタマイズ・支援依頼承ります。 [url=h

seasoft	投稿日時: 2012/1/18 1:36 対応状況: −−−
神登録日: 2008/6/4 居住地: 投稿: 7367	Re: 【 EC-CUBE 2.12 】商品一覧画面の速度改善(高速化)に関して意見を伺わせてください nanasess 様 > 本当に大多数の利用者が速度低下しているかどうかを明らかにできたら良いと思います. そうですね。今のところ、「データ生成スクリプト」で発生させた1パターン × 2DB × 1画面での、ボトルネックを特定したという段階ですので、実際には他のデータパターン・動作環境・画面でのデータ収集もできると良いと思います。 > PostgreSQL では使用できますが MySQL では使用できません. 例えば、PostgreSQL のみ使用するような最適化は難しいでしょうか? EC-CUBE の標準実装として非現実的で、効果の実証もされていないのであれば、やはり疑問を抱いてしまいます。 > 実際に, どんな実装になるか見せていただければ, ある程度は想定できるかもしれません. そうですね。原状の手元の実装は、あまりにも雑然としている状態ですので、もう少し整理して、パッチの形に落とすなどしようと思います。ただ、「抜本的」にという方向が現実的ならば、現状の規格をベースに議論するよりも、その方向に注力した方が良いかもという気持ちも出てきています。 > 現在は, 中小規模の利用が多い EC-CUBE ですが, 商用RDBMS の使用も考慮した大規模利用を想定した上で木構造の方が有利なのでは? と思った次第です有利なのかを検証してから、組み入れても良かったのではないかと思います。 # と、思ったら直ぐに実装・コミットする私が言うのは変な話しですがまぁ、実装があって、実際に稼働させて、初めて分かる事も多いですしね。ただ結果として、今の自分に見通せる範囲の中では、本件画面のパフォーマンスに限らず、データ構造や実装の複雑さとして、2.11 でコスト増になった部分だと感じています。 ---------------- 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 を意識しなくても良い実装になってくれば, データ構造や実装の複雑さは解消されてくるのかなと思っています.

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

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

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

« 1 (2) 3 4 5 6 »