バージョン選択

フォーラム

メニュー

オンライン状況

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

サイト内検索

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

フロント機能

新規スレッドを追加する

| 新しいものから 前のトピック | 次のトピック | 下へ
投稿者 スレッド
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 株式会社クオーレ
カスタマイズ御相談下さい。

nanasess
投稿日時: 2012/1/24 15:07
対応状況: −−−
登録日: 2006/9/9
居住地: 大阪
投稿: 2202
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 デフォルトの方が有利かもしれません.

個人的には, どちらも甲乙つけがたく, できれば複数カテゴリのソート時のパフォーマンスなど, もっとボトルネックの大きいところにパワーを注いだ方がいいんじゃないかなと思いますが, いかがでしょうか?


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

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

nanasess
投稿日時: 2012/1/24 15:15
対応状況: −−−
登録日: 2006/9/9
居住地: 大阪
投稿: 2202
Re: 【 EC-CUBE 2.12 】商品一覧画面の速度改善(高速化)に関して意見を伺わせてください
引用:

ECCUOREさんは書きました:

しかも、現在の規格仕様だと大規模の方が運用に耐えられないのではないかという報告も上がっているわけで。

EC-CUBEの限界商品数を話題に挙げると規格がついてまといますが、それを商品数だけで表現できるようになったら良いのではないかと。
「大規模を妥協」するのではなく、数十点〜数万点と全てのレンジの店舗、開発会社が納得できる設計を目指す為に
現状の規格という仕様に固執する必要があるのかという議論が出来たら良いなと思ってます。



規格の仕様を見なおした方が良いのではないかという意見には賛成です.

ただ, 2.11 では, 規格よりも複数カテゴリのソートの方が, 性能のボトルネックになっていると感じます.
1カテゴリに1000点以上の商品をつっこむと, 性能劣化が顕著ですし.


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

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

ECCUORE
投稿日時: 2012/1/25 9:22
対応状況: −−−
長老
登録日: 2009/10/22
居住地: 東京
投稿: 248
Re: 【 EC-CUBE 2.12 】商品一覧画面の速度改善(高速化)に関して意見を伺わせてください
カテゴリも規格と同じ思想で見直すのはダメでしょうかね。

商品ありきで、規格やカテゴリはオプション的なイメージです。
検索やソートだけを考えると商品の情報を管理するのは1テーブルが良いと思うのですよね。
商品とカテゴリは、直リレーションする必要が無いのではないかなぁと思ってるのですが、いかがでしょうか。
(件数によって差が出そうですが)
パフォーマンス検証していないので、思いつきで話してます。


----------------
EC CUORE 株式会社クオーレ
カスタマイズ御相談下さい。

seasoft
投稿日時: 2012/1/25 10:14
対応状況: −−−
登録日: 2008/6/4
居住地:
投稿: 7333
Re: 【 EC-CUBE 2.12 】商品一覧画面の速度改善(高速化)に関して意見を伺わせてください
> ただ, 2.11 では, 規格よりも複数カテゴリのソートの方が, 性能のボトルネックになっていると感じます.

冒頭のケースでは、規格の方が明らかなボトルネックでした。

そもそも、内部の処理時間を分析して、消費時間が大きいトップが規格周りだったので。

ただ、現在の木構造を持っていても、規格を使わない場合は、パフォーマンスの差は少ないようです。1万商品で5%程度の差だったので、これは誤差の範囲だと思います。

しかし、規格を使うとパフォーマンスが低下するというのは、明らかに意図とは異なる方向に働いてしまっているのでは感じるところです。

カテゴリ周りに関して言えば、以前にざっと試した範囲では、ソートというよりも抽出の時点で結構コストを消費していた印象です。DB や商品件数にも強く依存があると思うので、一概には言えないと思いますが。
改めてソートのコストに主眼を置いた条件で測定すると、確かにソートに消費しているコストは大きいですね。この部分も、何とか改善したいですね。


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

seasoft
投稿日時: 2012/1/25 10:25
対応状況: −−−
登録日: 2008/6/4
居住地:
投稿: 7333
Re: 【 EC-CUBE 2.12 】商品一覧画面の速度改善(高速化)に関して意見を伺わせてください
> 商品ありきで、規格やカテゴリはオプション的なイメージです。

とりあえず概念としては、賛成です。ただ、規格・価格・在庫の絡みは根深いので、悩ましく感じる部分も。

そもそも、2.11 の実装では、カテゴリに割り当てがないと、商品名での検索でも抽出されない、意味不明な実装になっていた気が・・・ そこまで、密な関係であってはいけないと思います。

たしか、どこかのタイミングで修正をコミットしたので、2.12.0-dev では改善しているとは思いますが。(直っていなかったら、ゴメンなさい。)


> 検索やソートだけを考えると商品の情報を管理するのは1テーブルが良いと思うのですよね。
> 商品とカテゴリは、直リレーションする必要が無いのではないかなぁと思ってるのですが、いかがでしょうか。

パフォーマンス上は1テーブルで処理できてしまえば、手っ取り早いですよね。
ただ、現実装を要求仕様と考えると、ちょっと厳しい印象も。

# う〜ん、EC-CUBE の商品マスタを見慣れすぎて、頭が凝り固まってるかも。


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

red
投稿日時: 2012/1/25 14:59
対応状況: −−−
登録日: 2010/2/15
居住地: 東京都
投稿: 1535
Re: 【 EC-CUBE 2.12 】商品一覧画面の速度改善(高速化)に関して意見を伺わせてください
> 検索やソートだけを考えると商品の情報を管理するのは1テーブルが良いと思うのですよね。
> 商品とカテゴリは、直リレーションする必要が無いのではないかなぁと思ってるのですが、いかがでしょうか。

これはそれ用のテーブルを作ってあげれば解決する問題かと思います。
トリガーっぽいプログラムを作って常にデータを入れれば十分かと思います

高速化は確かに大事な課題なのですが、安定化とシンプルな実装化を目指したほうが結果的に全体がよくなるのではないでしょうか?

seasoft
投稿日時: 2012/1/25 15:29
対応状況: −−−
登録日: 2008/6/4
居住地:
投稿: 7333
Re: 【 EC-CUBE 2.12 】商品一覧画面の速度改善(高速化)に関して意見を伺わせてください
red 様

> これはそれ用のテーブルを作ってあげれば解決する問題かと思います。
> トリガーっぽいプログラムを作って常にデータを入れれば十分かと思います

検索用に冗長情報で構成するテーブルを追加するイメージでしょうか?


> 高速化は確かに大事な課題なのですが、安定化とシンプルな実装化を目指したほうが結果的に全体がよくなるのではないでしょうか?

賛成です。

2.11系のカスタマイズでは、データ構造やロジックの理解で苦戦する事が多々ありまして。

コンピュータのパフォーマンスを引き出すのも重要ですが、ホモサピエンスのパフォーマンスを引き出すのも重要ですね。


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

ECCUORE
投稿日時: 2012/1/25 15:55
対応状況: −−−
長老
登録日: 2009/10/22
居住地: 東京
投稿: 248
Re: 【 EC-CUBE 2.12 】商品一覧画面の速度改善(高速化)に関して意見を伺わせてください
引用:

> 検索やソートだけを考えると商品の情報を管理するのは1テーブルが良いと思うのですよね。
> 商品とカテゴリは、直リレーションする必要が無いのではないかなぁと思ってるのですが、いかがでしょうか。
これはそれ用のテーブルを作ってあげれば解決する問題かと思います。
トリガーっぽいプログラムを作って常にデータを入れれば十分かと思います

同じような意見の方がいらして良かったです。
データ変更をトリガーとして、検索用データを更新するという思想はどうかなと思ってました。
大規模店舗の高速化案件では実際に使っております。
ただ、seasoftさんが仰るとおり冗長化しますので、標準設計では嫌がられるかな〜と考えてました。

引用:

高速化は確かに大事な課題なのですが、安定化とシンプルな実装化を目指したほうが結果的に全体がよくなるのではないでしょうか?


redさん案なら、実装も今よりはシンプルになるかと思うのですがいかがでしょう。
ツリー構造の複雑なリレーションを理解するより、検索用テーブルの仕様を理解する方が容易かと思います。


----------------
EC CUORE 株式会社クオーレ
カスタマイズ御相談下さい。

ECCUORE
投稿日時: 2012/1/25 16:15
対応状況: −−−
長老
登録日: 2009/10/22
居住地: 東京
投稿: 248
Re: 【 EC-CUBE 2.12 】商品一覧画面の速度改善(高速化)に関して意見を伺わせてください
引用:

> 高速化は確かに大事な課題なのですが、安定化とシンプルな実装化を目指したほうが結果的に全体がよくなるのではないでしょうか?
賛成です。

2.11系のカスタマイズでは、データ構造やロジックの理解で苦戦する事が多々ありまして。

コンピュータのパフォーマンスを引き出すのも重要ですが、ホモサピエンスのパフォーマンスを引き出すのも重要ですね。


「ホモサピエンスのパフォーマンス」も重要ですよね。

EC-CUBEがシェアNo.1をとった理由には、デザインや管理画面もそうですが他OSSに比べて、ロジックが簡単だったというのも重要なファクターではないかと想像しています。
開発会社の裾野が広がるというか。

実際にMagentoとかLiveCommerceは、Zend技術者じゃないとソースすら追えないと思います。
それに比べるとEC-CUBEはデザイナー兼PGでもソースは読めますしね。(ZenCartは単純にソースの可読性が悪いですし)

なので、「人にシンプル、コンピュータに対しては高性能」を目標に可読性と性能のバランスの良い所を目指してく感じになるのでしょうかね。
もっと色々な人の意見も聞きたいです


----------------
EC CUORE 株式会社クオーレ
カスタマイズ御相談下さい。

« 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.