> フロント機能 > 【 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 の利用者が規格をどの程度利用しているかというのはありますね。
|
ECCUORE |
投稿日時: 2012/1/25 16:15
対応状況: −−−
|
長老 登録日: 2009/10/22 居住地: 東京 投稿: 248 |
Re: 【 EC-CUBE 2.12 】商品一覧画面の速度改善(高速化)に関して意見を伺わせてください 引用:
「ホモサピエンスのパフォーマンス」も重要ですよね。 EC-CUBEがシェアNo.1をとった理由には、デザインや管理画面もそうですが他OSSに比べて、ロジックが簡単だったというのも重要なファクターではないかと想像しています。 開発会社の裾野が広がるというか。 実際にMagentoとかLiveCommerceは、Zend技術者じゃないとソースすら追えないと思います。 それに比べるとEC-CUBEはデザイナー兼PGでもソースは読めますしね。(ZenCartは単純にソースの可読性が悪いですし) なので、「人にシンプル、コンピュータに対しては高性能」を目標に可読性と性能のバランスの良い所を目指してく感じになるのでしょうかね。 もっと色々な人の意見も聞きたいです
|
ECCUORE |
投稿日時: 2012/1/25 15:55
対応状況: −−−
|
長老 登録日: 2009/10/22 居住地: 東京 投稿: 248 |
Re: 【 EC-CUBE 2.12 】商品一覧画面の速度改善(高速化)に関して意見を伺わせてください 引用:
同じような意見の方がいらして良かったです。 データ変更をトリガーとして、検索用データを更新するという思想はどうかなと思ってました。 大規模店舗の高速化案件では実際に使っております。 ただ、seasoftさんが仰るとおり冗長化しますので、標準設計では嫌がられるかな〜と考えてました。 引用:
redさん案なら、実装も今よりはシンプルになるかと思うのですがいかがでしょう。 ツリー構造の複雑なリレーションを理解するより、検索用テーブルの仕様を理解する方が容易かと思います。
|
seasoft |
投稿日時: 2012/1/25 15:29
対応状況: −−−
|
神 登録日: 2008/6/4 居住地: 投稿: 7365 |
Re: 【 EC-CUBE 2.12 】商品一覧画面の速度改善(高速化)に関して意見を伺わせてください red 様
> これはそれ用のテーブルを作ってあげれば解決する問題かと思います。 > トリガーっぽいプログラムを作って常にデータを入れれば十分かと思います 検索用に冗長情報で構成するテーブルを追加するイメージでしょうか? > 高速化は確かに大事な課題なのですが、安定化とシンプルな実装化を目指したほうが結果的に全体がよくなるのではないでしょうか? 賛成です。 2.11系のカスタマイズでは、データ構造やロジックの理解で苦戦する事が多々ありまして。 コンピュータのパフォーマンスを引き出すのも重要ですが、ホモサピエンスのパフォーマンスを引き出すのも重要ですね。
|
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 |
投稿日時: 2012/1/25 10:14
対応状況: −−−
|
神 登録日: 2008/6/4 居住地: 投稿: 7365 |
Re: 【 EC-CUBE 2.12 】商品一覧画面の速度改善(高速化)に関して意見を伺わせてください > ただ, 2.11 では, 規格よりも複数カテゴリのソートの方が, 性能のボトルネックになっていると感じます.
冒頭のケースでは、規格の方が明らかなボトルネックでした。 そもそも、内部の処理時間を分析して、消費時間が大きいトップが規格周りだったので。 ただ、現在の木構造を持っていても、規格を使わない場合は、パフォーマンスの差は少ないようです。1万商品で5%程度の差だったので、これは誤差の範囲だと思います。 しかし、規格を使うとパフォーマンスが低下するというのは、明らかに意図とは異なる方向に働いてしまっているのでは感じるところです。 改めてソートのコストに主眼を置いた条件で測定すると、確かにソートに消費しているコストは大きいですね。この部分も、何とか改善したいですね。
|
ECCUORE |
投稿日時: 2012/1/25 9:22
対応状況: −−−
|
長老 登録日: 2009/10/22 居住地: 東京 投稿: 248 |
Re: 【 EC-CUBE 2.12 】商品一覧画面の速度改善(高速化)に関して意見を伺わせてください カテゴリも規格と同じ思想で見直すのはダメでしょうかね。
商品ありきで、規格やカテゴリはオプション的なイメージです。 検索やソートだけを考えると商品の情報を管理するのは1テーブルが良いと思うのですよね。 商品とカテゴリは、直リレーションする必要が無いのではないかなぁと思ってるのですが、いかがでしょうか。 (件数によって差が出そうですが) パフォーマンス検証していないので、思いつきで話してます。
|
« 1 2 (3) 4 5 6 » |
| 古いものから | 前のトピック | 次のトピック | トップ |