バージョン選択

フォーラム

メニュー

オンライン状況

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

サイト内検索

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

フロント機能

新規スレッドを追加する

| 古いものから 前のトピック | 次のトピック | 下へ
投稿者 スレッド
nanasess
投稿日時: 2012/1/26 17:09
対応状況: −−−
登録日: 2006/9/9
居住地:
投稿: 2303
Re: 【 EC-CUBE 2.12 】商品一覧画面の速度改善(高速化)に関して意見を伺わせてください
Seasoft 様
部分的で恐縮ですが, とり急ぎ,

引用:

一応、データ生成スクリプトで生成した環境で、処理毎のコストを計測し、一番のボトルネックは規格であるという分析結果に基づき、改善を試みています。そして、冒頭に記載の通り、一定の改善が見込める事を確認しています。


データ生成スクリプトの PRODUCTS_VOLUME(商品の生成数) のデフォルト値は 100 ですが, 5000 くらいにした場合はいかがでしょうか?
100 くらいでは, 規格がボトルネックになると思いますが, *_CATEGORIES_VOLUME を増やしたり, PRODUCTS_VOLUME が 1000 以上になると, 変わってくるのかなと思います.
KAJI
投稿日時: 2012/1/26 12:29
対応状況: −−−
一人前
登録日: 2008/1/24
居住地:
投稿: 121
Re: 【 EC-CUBE 2.12 】商品一覧画面の速度改善(高速化)に関して意見を伺わせてください
株式会社ロックオンの梶原でございます。

議論に入るのが遅くなり申し訳ございません。
そろそろ収束もさせていきたく、積極介入していきたいと思います。

まず、今回2.12の方針を簡単にですが提示させていただきます。

○木構造の変更がありか無しかで言いますと、「あり」です。

 ただし、条件付きです。

 ・1万点を超えるような商品点数であっても正常に表示されること
  ⇒大規模店舗対応はECの宿命のようなところもあり、またそこが弱いとそもそも使用アプリケーション
   として選択されないので大規模店舗対応は必須条件です。
   仮に、木構造を破棄して、速度劣化したとしても大幅でなければ問題はありません。

 ・2.11のモジュール(特に決済モジュール)の大幅な改訂が不必要なこと
  ⇒2.11で大幅にソースとDB構造を修正したばかりで、現時点では外部連携モジュールに大幅な修正が
   必要なソース改変は2.12で入れない予定でいます。
   ここは、程度によりけりです。


EC-CUBEはオープンソースですので、より良くなるのであればそれを否定するということはないです。
シンプルで見通しのよい作りというのも望むところですので、是非ともそうなればと思います。
ただ、各種モジュールと歩調を合わせて展開をしていく必要もあり、どうしてもバージョンごとでの
制限が入ってしまう可能性があること、ご了承いただければと思います。

また、質問等随時受け付けますので、より良い落とし所を皆さんと探っていければと思います。

引き続き、よろしくお願いします!
seasoft
投稿日時: 2012/1/25 16:34
対応状況: −−−
登録日: 2008/6/4
居住地:
投稿: 7365
Re: 【 EC-CUBE 2.12 】商品一覧画面の速度改善(高速化)に関して意見を伺わせてください
> ただ, 2.11 デフォルトでも, 極端にパフォーマンスが悪いわけではないので, 中小規模の店舗なら, あまり気にならないかなと思ったりします.

規模というよりも、規格を使用するか否かで、大きく分かれる状況のように感じています。(実際には、商品規格のボリュームも強く関与しそうです。)


> また, パッチ版の方は, DB にそれなりの実行コストがかかっているので, I/O の遅い共有サーバーなどでは不利なのかもしれません.

ここで言う「I/O」とは、DB サーバのディスクの I/O のうち Read 側だと思いますが、パッチを当てた方が DB のディスクの読み込み量は少ないような・・・

[パッチ無し] 316ブロック
[パッチ有り] 288ブロック

※ PostgreSQL 9.0.3 再起動後1発目の実行を計測。


> 2.11 デフォルトの方は, 規格を3階層以上にするというカスタマイズの余地を残したデータ構造ですので, 2階層までの固定であれば, もうちょっと良いパフォーマンスを出せると思います.

そうですね。私も、今回関連する実装を査読していて、そう感じる部分がありました。

ただ、2階層で木構造というのは、無駄が大きい印象を持ちます・・・


本題からは脱線しますが「商品管理>商品登録CSV」辺りのパフォーマンスも、差があるように感じました。

非常に大雑把なものですが、1万件(商品規格なし)の商品登録で、下記のような感じでした。

[パッチ有り] 風呂に入っている間に処理が完了していた (注: 私は長風呂です)
[パッチ無し] 風呂を上がってからひと仕事している間では完了せず。寝て起きたら完了していた。

また、データ生成スクリプトの実行時間にしても、2.5倍以上の違いがありました。


> また, Webサーバーをスケールできるような環境であれば, 2.11 デフォルトの方が有利かもしれません.

スケールアウトするのが妥当な程度にアクセスがある場合、その確率は否定できないと思います。

しかし、パッチ有りの場合、逆の発想で DB サーバをスケールアウトする事で、高速化できると思います。

実際に、インテグレートパートナー企業でも事例があるようですし。

ちなみに、先日の EC-CUBE パートナー新年会で得た情報ですが、某大手ホスティング企業が EC-CUBE の利用を見据えて、DB スケールアウトのソリューションの提供に向けて動き出したらしいです。


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

一応、データ生成スクリプトで生成した環境で、処理毎のコストを計測し、一番のボトルネックは規格であるという分析結果に基づき、改善を試みています。そして、冒頭に記載の通り、一定の改善が見込める事を確認しています。

ただ、「規格」を使用していない環境では (商品一覧画面のパフォーマンスに限定して言えば) 大差がなさそうだという事も分かっているので、EC-CUBE の利用者が規格をどの程度利用しているかというのはありますね。


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

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 株式会社クオーレ
カスタマイズ御相談下さい。

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

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

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

引用:

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


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


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

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

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

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


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

賛成です。

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

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


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

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

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

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

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

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

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

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


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

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

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


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

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

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

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

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

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

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


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

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

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


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

« 1 2 (3) 4 5 6 »
| 古いものから 前のトピック | 次のトピック | トップ


 



ログイン


EC-CUBE公式 Amazon Payプラグイン

統計情報

総メンバー数は88,308名です
総投稿数は109,692件です

投稿数ランキング

1
seasoft
7365
2
468
3217
3
AMUAMU
2712
4
nanasess
2303
5
umebius
2085
6
yuh
1818
7
h_tanaka
1610
8
red
1568
9
mcontact
1240
10
tsuji
958
11
fukap
907
12
shutta
835
13
tao_s
796
14 ramrun 789
15 karin 689
16 sumida 641
17
homan
633
18 DELIGHT 572
19
patapata
502
20
flealog
485


ネットショップの壺

EC-CUBEインテグレートパートナー

Copyright© EC-CUBE CO.,LTD. All Rights Reserved.