バージョン選択

フォーラム

メニュー

オンライン状況

27 人のユーザが現在オンラインです。 (13 人のユーザが フォーラム を参照しています。)
登録ユーザ: 0
ゲスト: 27
もっと...

サイト内検索

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

フロント機能

新規スレッドを追加する

| 新しいものから 前のトピック | 次のトピック | 下へ
投稿者 スレッド
seasoft
投稿日時: 2012/1/17 13:33
対応状況: −−−
登録日: 2008/6/4
居住地:
投稿: 7333
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
居住地:
投稿: 7333
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
居住地: 大阪
投稿: 2202
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 を意識しなくても良い実装になってくれば, データ構造や実装の複雑さは解消されてくるのかなと思っています.


----------------
大河内健太郎(Kentaro Ohkouchi)
EC-CUBE公式エバンジェリスト
スキルニル株式会社

EC-CUBE1系2系長期サポートホスティングサービス CUBE Lab
https://cubelab.info/

seasoft
投稿日時: 2012/1/20 10:51
対応状況: −−−
登録日: 2008/6/4
居住地:
投稿: 7333
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
居住地:
投稿: 7333
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
居住地:
投稿: 7333
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
居住地:
投稿: 7333
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
居住地: 大阪
投稿: 2202
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 の普及と発展のためには, そういった大規模運用に耐えられるような方向にする必要があるのではないかなぁと.

確かに, 数百点までの店舗が圧倒的多数だと思いますが, 大規模を妥協して, 中小のニーズに応えるような対応は, ちょっと微妙なのかなと...


----------------
大河内健太郎(Kentaro Ohkouchi)
EC-CUBE公式エバンジェリスト
スキルニル株式会社

EC-CUBE1系2系長期サポートホスティングサービス CUBE Lab
https://cubelab.info/

seasoft
投稿日時: 2012/1/20 15:16
対応状況: −−−
登録日: 2008/6/4
居住地:
投稿: 7333
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 »
| 新しいものから 前のトピック | 次のトピック | トップ


 



ログイン



統計情報

総メンバー数は75,050名です
総投稿数は104,352件です

投稿数ランキング

1
seasoft
7333
2
468
3217
3
AMUAMU
2712
4
nanasess
2202
5
umebius
2085
6
yuh
1664
7
red
1535
8
h_tanaka
1189
9
tsuji
942
10
fukap
907
11
shutta
835
12
tao_s
794
13 ramrun 789
14 karin 689
15 sumida 641
16
homan
633
17 DELIGHT 572
18
patapata
502
19
flealog
485
20 tonton 437
Copyright© EC-CUBE CO.,LTD. All Rights Reserved.