EC-CUBE 開発コミュニティ

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

フロント機能

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

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/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 7:13 対応状況: −−−
神登録日: 2009/5/2 居住地: 東京都投稿: 2712	Re: 【 EC-CUBE 2.12 】商品一覧画面の速度改善(高速化)に関して意見を伺わせてください引用： > 2.4系の仕様も、それはそれでまた問題があると思います。ちなみに、2.4系の仕様で問題があると思われる中に、2.11系で解消されたと思われる部分はございますか? (木構造を外す場合には、留意を要する部分になると考えています。) dtb_product_classテーブルに持っている内容と、規格自体の面倒な情報が分離されたことによる見通しの良さはあると思います。引用： > また木構造が高速化に寄与する部分が残念ながら現時点では見当たらないです。（2.11.0β時にはあったような気がしますが・・・）「2.11.0β時」の件、興味深いですね。規格データ展開自体に速度向上と省力化が明らかにあったと感じたのですが、その後の改修で処理がほうぼうに散ってイマイチ分からなくなった感じです ---------------- EC-CUBE公式エヴァンジェリスト EC-CUBEインテグレートパートナー (株)スピリット・オブ移転・拡張・高速化・問題解決各種カスタマイズ・支援依頼承ります。 [url=h

seasoft	投稿日時: 2012/1/16 16:28 対応状況: −−−
神登録日: 2008/6/4 居住地: 投稿: 7367	Re: 【 EC-CUBE 2.12 】商品一覧画面の速度改善(高速化)に関して意見を伺わせてください AMUAMU 様 > 2.4系の仕様も、それはそれでまた問題があると思います。ちなみに、2.4系の仕様で問題があると思われる中に、2.11系で解消されたと思われる部分はございますか? (木構造を外す場合には、留意を要する部分になると考えています。) > まず、木構造は不必要のはずです。 > （そのために相当苦労している）私も同意見です。 > また木構造が高速化に寄与する部分が残念ながら現時点では見当たらないです。（2.11.0β時にはあったような気がしますが・・・）「2.11.0β時」の件、興味深いですね。個人的に日常案件が忙しく、EC-CUBE 本体開発に注力できなかった次期でして、見逃していた感が・・・ ---------------- Seasoft こちらでの投稿は、アイディア程度に留めさせていただいております。個別案件の作業は有償で承っております。お気軽にご相談ください。

nanasess	投稿日時: 2012/1/16 16:23 対応状況: −−−
神登録日: 2006/9/9 居住地: 投稿: 2313	Re: 【 EC-CUBE 2.12 】商品一覧画面の速度改善(高速化)に関して意見を伺わせてください引用： seasoftさんは書きました：しかし、管理画面を含めて実際のカスタマイズを考えると容易いカスタマイズでは無いのではないでしょうか? 極少数の必要とするケースのために、大多数の利用者が速度低下というデメリットを受けているとしたら、望ましくない状況なのではないかと思います。そこで、本当に「極少数」なのかを確認する意味で、冒頭のような質問を振ってみた次第です。おっしゃる通りですね. 本当に大多数の利用者が速度低下しているかどうかを明らかにできたら良いと思います. 引用： > * SQLで connect by が使えれば速い(はず) この辺り詳しくないのですが、使えないのでしょうか? PostgreSQL では使用できますが MySQL では使用できません. 引用： > 環境によって更に遅くなるという現象も出てきそうです. どういった環境で遅くなりそうか、分かりますか? 実際に, どんな実装になるか見せていただければ, ある程度は想定できるかもしれません. 現在は, 中小規模の利用が多い EC-CUBE ですが, 商用RDBMS の使用も考慮した大規模利用を想定した上で木構造の方が有利なのでは? と思った次第です (connect by 句が使えたり, チューニングの余地が増えやすいからという理由ですが...)

ECCUORE	投稿日時: 2012/1/16 13:28 対応状況: −−−
長老登録日: 2009/10/22 居住地: 東京投稿: 248	Re: 【 EC-CUBE 2.12 】商品一覧画面の速度改善(高速化)に関して意見を伺わせてください引用： seasoftさんは書きました：・「高速化をして木構造を放棄する」のと「木構造を維持する」のと、どちらを望みますか? 　(木構造を放棄する場合、EC-CUBE 2.4 の商品規格情報の持ち方に近くなります。) 「高速化をして木構造を放棄する」に一票です。また規格の仕様について再検討して頂けると嬉しいです。その場合、木構造というよりも規格の仕様を議論する必要があるのかと思いますがいかがでしょうか。議論して頂きたいこと。・規格毎に価格を設定できる必要があるのか。・規格は複数階層設定できる必要があるのか。引用： nanasessさんは書きました：木構造とした場合のメリットは, * 規格を2つ以上にしたい場合, 追加しやすくなる * SQLで connect by が使えれば速い(はず) 規格が2つ以上にできるという事だけがメリットだとすると規格が2つ以上設定したいというニーズがどれだけあるのかを考えて、標準仕様に採用するかを検討するべきだったのかと思います。引用： seasoftさんは書きました：しかし、管理画面を含めて実際のカスタマイズを考えると容易いカスタマイズでは無いのではないでしょうか? 極少数の必要とするケースのために、大多数の利用者が速度低下というデメリットを受けているとしたら、望ましくない状況なのではないかと思います。そこで、本当に「極少数」なのかを確認する意味で、冒頭のような質問を振ってみた次第です。同じ事をseasoftさんが書いてますね。感覚的には「極少数」な気がします。というのも私たちの案件では、2.4時代も含めて規格を利用した事は数回しかないです。極端な話ですが、「規格を廃止してもいいから、高速化したい」というカスタマイズ依頼もあります。 ---------------- EC CUORE 株式会社クオーレカスタマイズ御相談下さい。

seasoft	投稿日時: 2012/1/16 11:26 対応状況: −−−
神登録日: 2008/6/4 居住地: 投稿: 7367	Re: 【 EC-CUBE 2.12 】商品一覧画面の速度改善(高速化)に関して意見を伺わせてください nanasess 様 > 木構造とした場合のメリットは, > > * 規格を2つ以上にしたい場合, 追加しやすくなる技術的には理解できます。しかし、管理画面を含めて実際のカスタマイズを考えると容易いカスタマイズでは無いのではないでしょうか? 極少数の必要とするケースのために、大多数の利用者が速度低下というデメリットを受けているとしたら、望ましくない状況なのではないかと思います。そこで、本当に「極少数」なのかを確認する意味で、冒頭のような質問を振ってみた次第です。 > * SQLで connect by が使えれば速い(はず) この辺り詳しくないのですが、使えないのでしょうか? > なので, 現時点の標準状態の EC-CUBE では, メリットを出せていません. やはり、そうですよね。一方で、冒頭に記載のようにデメリットは明確に出ているようです。 > 環境によって更に遅くなるという現象も出てきそうです. どういった環境で遅くなりそうか、分かりますか? ---------------- Seasoft こちらでの投稿は、アイディア程度に留めさせていただいております。個別案件の作業は有償で承っております。お気軽にご相談ください。

seasoft	投稿日時: 2012/1/16 10:45 対応状況: −−−
神登録日: 2008/6/4 居住地: 投稿: 7367	Re: 【 EC-CUBE 2.12 】商品一覧画面の速度改善(高速化)に関して意見を伺わせてください Masashige 様ご回答ありがとうございます。 > 規格で微妙に実現できない案件の場合に、規格をカスタマイズするよりも > 規格っぽい機能を追加することが多いので参考になるかはわかりませんが。私も、通常その方法で対応しています。規格で実現しようと(規格3など)すると、複雑になりすぎてしまうので。 > 仕様を深く理解しているわけではありませんが、 > 「早くなるなら」＆「好み的に」木構造は放棄でいいと思います。 > 「放棄"が"いい」ではない程度。木構造だと、「仕様を深く理解」するのを難しくする側面もありそうですね。 > 6件中0件です。やはり、そうですよね。私も同じような傾向です(笑) ---------------- Seasoft こちらでの投稿は、アイディア程度に留めさせていただいております。個別案件の作業は有償で承っております。お気軽にご相談ください。

nanasess	投稿日時: 2012/1/16 10:33 対応状況: −−−
神登録日: 2006/9/9 居住地: 投稿: 2313	Re: 【 EC-CUBE 2.12 】商品一覧画面の速度改善(高速化)に関して意見を伺わせてください引用： AMUAMUさんは書きました：木構造が問題というより、現在の規格機能に関するＤＢ仕様全体に問題があると思っています。 2.4系の仕様も、それはそれでまた問題があると思います。同意見です. 木構造とした場合のメリットは, * 規格を2つ以上にしたい場合, 追加しやすくなる * SQLで connect by が使えれば速い(はず) なので, 現時点の標準状態の EC-CUBE では, メリットを出せていません. 抜本的な改善には賛成ですが, 中途半端な仕様変更は良くないと思っています. 環境によって更に遅くなるという現象も出てきそうです. 1.x からの画面仕様や, 古いプログラムを引きずったままきているので, それも問題かなと思っています. 規格の話題からは離れてしまいますが, 複数カテゴリでのソートも課題かなと思っています. (1カテゴリに数千点の商品を割り当てると極端に重くなる)

« 1 2 3 4 (5) 6 »