どうか教えて下さい！
| > フロント機能 > 【 EC-CUBE 2.12 】商品一覧画面の速度改善(高速化)に関して意見を伺わせてください |
フロント機能
 |
| | 新しいものから | 前のトピック | 次のトピック | 下へ |
| 投稿者 | スレッド |
|---|---|
| seasoft |
投稿日時: 2012/1/14 13:58
対応状況: −−−
|
神   登録日: 2008/6/4 居住地: 投稿: 7367 |
【 EC-CUBE 2.12 】商品一覧画面の速度改善(高速化)に関して意見を伺わせてください EC-CUBE 2.11 は、EC-CUBE 2.4 と比較して、速度の低下が顕著なケースが見受けられます。
そこで、私どもでは先日開発が開始された EC-CUBE 2.12 の開発に当たりまして、商品一覧画面の速度改善を試みています。 その中で、データの内部構造に手を加えないと改善が難しい部分があり、皆様の意見を伺わせてください。 まず、前提としまして、#781で木構造に変更された規格が (チケットの説明文とは相違するのですが) 速度面でのネックとなっていると考えています。 木構造が悪いということではなく、実装が未成熟な段階とも考えられますが、既に5回目の正式リリースである EC-CUBE 2.11.4 でも改善が見られないことから、木構造を維持して改善していくのは(無理ではないにしても)難しいのではないかと思います。 そこで実際に、EC-CUBE 2.12 デベロッパー版 (r21394) を基にして、dtb_class_combination を使わずに dtb_products_class のみで処理するようにカスタマイズをしてみました。すると、商品一覧画面は PostgreSQL で約1.8倍、MySQL では約12.5倍の処理速度を観測しました。 PostgreSQL 9.0.1: 2.15秒 → 1.17秒 MySQL 5.5.16: 16.40秒 → 1.31秒 ※ 全体を改修したのではなく、商品一覧画面の主要な処理のみを改修した段階での暫定値です。 ※ EC-CUBE データ生成スクリプトを使用して、100商品を登録した状態です。 さて、前置きが長くなりました m(_ _)m ここからが、本題の質問です。 ・「高速化をして木構造を放棄する」のと「木構造を維持する」のと、どちらを望みますか? (木構造を放棄する場合、EC-CUBE 2.4 の商品規格情報の持ち方に近くなります。) ・規格の木構造を生かしたサイト構築の経験はありますか? (EC-CUBE 2.11 に関してです。複数のサイトを開発された方は、「○件中△件」といった回答をいただけると幸いです。)
|
| Masashige |
投稿日時: 2012/1/14 16:24
対応状況: −−−
|
長老   登録日: 2009/4/1 居住地: 投稿: 200 |
Re: 【 EC-CUBE 2.12 】商品一覧画面の速度改善(高速化)に関して意見を伺わせてください 規格で微妙に実現できない案件の場合に、規格をカスタマイズするよりも
規格っぽい機能を追加することが多いので参考になるかはわかりませんが。 引用： ・「高速化をして木構造を放棄する」のと「木構造を維持する」のと、どちらを望みますか? 仕様を深く理解しているわけではありませんが、 「早くなるなら」＆「好み的に」木構造は放棄でいいと思います。 「放棄"が"いい」ではない程度。 引用： ・規格の木構造を生かしたサイト構築の経験はありますか? 6件中0件です。 |
| AMUAMU |
投稿日時: 2012/1/16 2:03
対応状況: −−−
|
神  登録日: 2009/5/2 居住地: 東京都 投稿: 2712 |
Re: 【 EC-CUBE 2.12 】商品一覧画面の速度改善(高速化)に関して意見を伺わせてください 木構造が問題というより、現在の規格機能に関するＤＢ仕様全体に問題があると思っています。
2.4系の仕様も、それはそれでまた問題があると思います。 規格機能を実現するための仕様と実装を、ゼロから考え直す方が良いのでは常々思っており、規格機能周りの見直しは事ある毎に提案はしているのですが・・・ まず、木構造は不必要のはずです。 （そのために相当苦労している） また木構造が高速化に寄与する部分が残念ながら現時点では見当たらないです。（2.11.0β時にはあったような気がしますが・・・） 一方、ゼロから見直さないのであれば、右や左に中途半端な内部仕様変更をするのは良くないとは思っています。 （良い実装案を示せれば良いのです・・・）
|
| nanasess |
投稿日時: 2012/1/16 10:33
対応状況: −−−
|
神  登録日: 2006/9/9 居住地: 投稿: 2313 |
Re: 【 EC-CUBE 2.12 】商品一覧画面の速度改善(高速化)に関して意見を伺わせてください 引用：
同意見です. 木構造とした場合のメリットは, * 規格を2つ以上にしたい場合, 追加しやすくなる * SQLで connect by が使えれば速い(はず) なので, 現時点の標準状態の EC-CUBE では, メリットを出せていません. 抜本的な改善には賛成ですが, 中途半端な仕様変更は良くないと思っています. 環境によって更に遅くなるという現象も出てきそうです. 1.x からの画面仕様や, 古いプログラムを引きずったままきているので, それも問題かなと思っています. 規格の話題からは離れてしまいますが, 複数カテゴリでのソートも課題かなと思っています. (1カテゴリに数千点の商品を割り当てると極端に重くなる) |
| seasoft |
投稿日時: 2012/1/16 10:45
対応状況: −−−
|
神 登録日: 2008/6/4 居住地: 投稿: 7367 |
Re: 【 EC-CUBE 2.12 】商品一覧画面の速度改善(高速化)に関して意見を伺わせてください Masashige 様
ご回答ありがとうございます。 > 規格で微妙に実現できない案件の場合に、規格をカスタマイズするよりも > 規格っぽい機能を追加することが多いので参考になるかはわかりませんが。 私も、通常その方法で対応しています。規格で実現しようと(規格3など)すると、複雑になりすぎてしまうので。 > 仕様を深く理解しているわけではありませんが、 > 「早くなるなら」＆「好み的に」木構造は放棄でいいと思います。 > 「放棄"が"いい」ではない程度。 木構造だと、「仕様を深く理解」するのを難しくする側面もありそうですね。 > 6件中0件です。 やはり、そうですよね。 私も同じような傾向です(笑)
|
| seasoft |
投稿日時: 2012/1/16 11:26
対応状況: −−−
|
神 登録日: 2008/6/4 居住地: 投稿: 7367 |
Re: 【 EC-CUBE 2.12 】商品一覧画面の速度改善(高速化)に関して意見を伺わせてください nanasess 様
> 木構造とした場合のメリットは, > > * 規格を2つ以上にしたい場合, 追加しやすくなる 技術的には理解できます。 しかし、管理画面を含めて実際のカスタマイズを考えると容易いカスタマイズでは無いのではないでしょうか? 極少数の必要とするケースのために、大多数の利用者が速度低下というデメリットを受けているとしたら、望ましくない状況なのではないかと思います。 そこで、本当に「極少数」なのかを確認する意味で、冒頭のような質問を振ってみた次第です。 > * SQLで connect by が使えれば速い(はず) この辺り詳しくないのですが、使えないのでしょうか? > なので, 現時点の標準状態の EC-CUBE では, メリットを出せていません. やはり、そうですよね。一方で、冒頭に記載のようにデメリットは明確に出ているようです。 > 環境によって更に遅くなるという現象も出てきそうです. どういった環境で遅くなりそうか、分かりますか?
|
| ECCUORE |
投稿日時: 2012/1/16 13:28
対応状況: −−−
|
長老  登録日: 2009/10/22 居住地: 東京 投稿: 248 |
Re: 【 EC-CUBE 2.12 】商品一覧画面の速度改善(高速化)に関して意見を伺わせてください 引用：
「高速化をして木構造を放棄する」に一票です。 また規格の仕様について再検討して頂けると嬉しいです。 その場合、木構造というよりも規格の仕様を議論する必要があるのかと思いますがいかがでしょうか。 議論して頂きたいこと。 ・規格毎に価格を設定できる必要があるのか。 ・規格は複数階層設定できる必要があるのか。 引用：
規格が2つ以上にできるという事だけがメリットだとすると 規格が2つ以上設定したいというニーズがどれだけあるのかを考えて、標準仕様に採用するかを検討するべきだったのかと思います。 引用：
同じ事をseasoftさんが書いてますね。 感覚的には「極少数」な気がします。というのも私たちの案件では、2.4時代も含めて規格を利用した事は数回しかないです。 極端な話ですが、「規格を廃止してもいいから、高速化したい」というカスタマイズ依頼もあります。
|
| nanasess |
投稿日時: 2012/1/16 16:23
対応状況: −−−
|
神 登録日: 2006/9/9 居住地: 投稿: 2313 |
Re: 【 EC-CUBE 2.12 】商品一覧画面の速度改善(高速化)に関して意見を伺わせてください 引用：
おっしゃる通りですね. 本当に大多数の利用者が速度低下しているかどうかを明らかにできたら良いと思います. 引用：
PostgreSQL では使用できますが MySQL では使用できません. 引用：
実際に, どんな実装になるか見せていただければ, ある程度は想定できるかもしれません. 現在は, 中小規模の利用が多い EC-CUBE ですが, 商用RDBMS の使用も考慮した大規模利用を想定した上で木構造の方が有利なのでは? と思った次第です (connect by 句が使えたり, チューニングの余地が増えやすいからという理由ですが...) |
| 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 本体開発に注力できなかった次期でして、見逃していた感が・・・
|
| AMUAMU |
投稿日時: 2012/1/17 7:13
対応状況: −−−
|
神 登録日: 2009/5/2 居住地: 東京都 投稿: 2712 |
Re: 【 EC-CUBE 2.12 】商品一覧画面の速度改善(高速化)に関して意見を伺わせてください 引用：
dtb_product_classテーブルに持っている内容と、規格自体の面倒な情報が分離されたことによる見通しの良さはあると思います。 引用：
規格データ展開自体に速度向上と省力化が明らかにあったと感じたのですが、その後の改修で処理がほうぼうに散ってイマイチ分からなくなった感じです
|
| (1) 2 3 4 ... 6 » | |
| | 新しいものから | 前のトピック | 次のトピック | トップ |
