> フロント機能 > 【 EC-CUBE 2.12 】商品一覧画面の速度改善(高速化)に関して意見を伺わせてください |
フロント機能
| 新しいものから | 前のトピック | 次のトピック | 下へ |
投稿者 | スレッド |
---|---|
ECCUORE |
投稿日時: 2012/1/20 17:51
対応状況: −−−
|
長老 登録日: 2009/10/22 居住地: 東京 投稿: 248 |
Re: 【 EC-CUBE 2.12 】商品一覧画面の速度改善(高速化)に関して意見を伺わせてください 引用:
「大規模を妥協をしよう」とは誰も思っていないのではないかと思います。 ただ、現状の「大規模(仮定シェア1%)を考慮したがために、中小規模(仮定シェア99%)の人が影響を受ける」設計は嫌だな〜って思ってる人が私を含めて最低でも数人?いるという事なんじゃないでしょうか。 しかも、現在の規格仕様だと大規模の方が運用に耐えられないのではないかという報告も上がっているわけで。 EC-CUBEの限界商品数を話題に挙げると規格がついてまといますが、それを商品数だけで表現できるようになったら良いのではないかと。 「大規模を妥協」するのではなく、数十点〜数万点と全てのレンジの店舗、開発会社が納得できる設計を目指す為に 現状の規格という仕様に固執する必要があるのかという議論が出来たら良いなと思ってます。
|
nanasess |
投稿日時: 2012/1/24 15:07
対応状況: −−−
|
神 登録日: 2006/9/9 居住地: 投稿: 2311 |
Re: 【 EC-CUBE 2.12 】商品一覧画面の速度改善(高速化)に関して意見を伺わせてください Seasoft 様
引用:
時間の隙を見て試してみました. (ベンチマークしたデータをまとめきれてないので, 以下は感覚値での所感です. また, あくまでも個人的な意見ですので, あらかじめご了承ください) 2.11 デフォルトでは, 規格のデータを生成するのに PHP で木構造を作っていたのですが, その部分が SQL で削減された感じですね! 結果としては, パッチを当てた方が高いパフォーマンスを出していました. 以下のような環境です.
PHP で頑張るか, DB で頑張るかの違いだと思うので, VPS や共有サーバーを使用した, 中小規模のサイトでしたら, パッチ版の方が優れていると思います. ただ, 2.11 デフォルトでも, 極端にパフォーマンスが悪いわけではないので, 中小規模の店舗なら, あまり気にならないかなと思ったりします. また, パッチ版の方は, DB にそれなりの実行コストがかかっているので, I/O の遅い共有サーバーなどでは不利なのかもしれません. 2.11 デフォルトの方は, 規格を3階層以上にするというカスタマイズの余地を残したデータ構造ですので, 2階層までの固定であれば, もうちょっと良いパフォーマンスを出せると思います. また, Webサーバーをスケールできるような環境であれば, 2.11 デフォルトの方が有利かもしれません. 個人的には, どちらも甲乙つけがたく, できれば複数カテゴリのソート時のパフォーマンスなど, もっとボトルネックの大きいところにパワーを注いだ方がいいんじゃないかなと思いますが, いかがでしょうか? |
nanasess |
投稿日時: 2012/1/24 15:15
対応状況: −−−
|
神 登録日: 2006/9/9 居住地: 投稿: 2311 |
Re: 【 EC-CUBE 2.12 】商品一覧画面の速度改善(高速化)に関して意見を伺わせてください 引用:
規格の仕様を見なおした方が良いのではないかという意見には賛成です. ただ, 2.11 では, 規格よりも複数カテゴリのソートの方が, 性能のボトルネックになっていると感じます. 1カテゴリに1000点以上の商品をつっこむと, 性能劣化が顕著ですし. |
ECCUORE |
投稿日時: 2012/1/25 9:22
対応状況: −−−
|
長老 登録日: 2009/10/22 居住地: 東京 投稿: 248 |
Re: 【 EC-CUBE 2.12 】商品一覧画面の速度改善(高速化)に関して意見を伺わせてください カテゴリも規格と同じ思想で見直すのはダメでしょうかね。
商品ありきで、規格やカテゴリはオプション的なイメージです。 検索やソートだけを考えると商品の情報を管理するのは1テーブルが良いと思うのですよね。 商品とカテゴリは、直リレーションする必要が無いのではないかなぁと思ってるのですが、いかがでしょうか。 (件数によって差が出そうですが) パフォーマンス検証していないので、思いつきで話してます。
|
seasoft |
投稿日時: 2012/1/25 10:14
対応状況: −−−
|
神 登録日: 2008/6/4 居住地: 投稿: 7367 |
Re: 【 EC-CUBE 2.12 】商品一覧画面の速度改善(高速化)に関して意見を伺わせてください > ただ, 2.11 では, 規格よりも複数カテゴリのソートの方が, 性能のボトルネックになっていると感じます.
冒頭のケースでは、規格の方が明らかなボトルネックでした。 そもそも、内部の処理時間を分析して、消費時間が大きいトップが規格周りだったので。 ただ、現在の木構造を持っていても、規格を使わない場合は、パフォーマンスの差は少ないようです。1万商品で5%程度の差だったので、これは誤差の範囲だと思います。 しかし、規格を使うとパフォーマンスが低下するというのは、明らかに意図とは異なる方向に働いてしまっているのでは感じるところです。 改めてソートのコストに主眼を置いた条件で測定すると、確かにソートに消費しているコストは大きいですね。この部分も、何とか改善したいですね。
|
seasoft |
投稿日時: 2012/1/25 10:25
対応状況: −−−
|
神 登録日: 2008/6/4 居住地: 投稿: 7367 |
Re: 【 EC-CUBE 2.12 】商品一覧画面の速度改善(高速化)に関して意見を伺わせてください > 商品ありきで、規格やカテゴリはオプション的なイメージです。
とりあえず概念としては、賛成です。ただ、規格・価格・在庫の絡みは根深いので、悩ましく感じる部分も。 そもそも、2.11 の実装では、カテゴリに割り当てがないと、商品名での検索でも抽出されない、意味不明な実装になっていた気が・・・ そこまで、密な関係であってはいけないと思います。 たしか、どこかのタイミングで修正をコミットしたので、2.12.0-dev では改善しているとは思いますが。(直っていなかったら、ゴメンなさい。) > 検索やソートだけを考えると商品の情報を管理するのは1テーブルが良いと思うのですよね。 > 商品とカテゴリは、直リレーションする必要が無いのではないかなぁと思ってるのですが、いかがでしょうか。 パフォーマンス上は1テーブルで処理できてしまえば、手っ取り早いですよね。 ただ、現実装を要求仕様と考えると、ちょっと厳しい印象も。 # う〜ん、EC-CUBE の商品マスタを見慣れすぎて、頭が凝り固まってるかも。
|
red |
投稿日時: 2012/1/25 14:59
対応状況: −−−
|
神 登録日: 2010/2/15 居住地: 東京都 投稿: 1569 |
Re: 【 EC-CUBE 2.12 】商品一覧画面の速度改善(高速化)に関して意見を伺わせてください > 検索やソートだけを考えると商品の情報を管理するのは1テーブルが良いと思うのですよね。
> 商品とカテゴリは、直リレーションする必要が無いのではないかなぁと思ってるのですが、いかがでしょうか。 これはそれ用のテーブルを作ってあげれば解決する問題かと思います。 トリガーっぽいプログラムを作って常にデータを入れれば十分かと思います 高速化は確かに大事な課題なのですが、安定化とシンプルな実装化を目指したほうが結果的に全体がよくなるのではないでしょうか? |
seasoft |
投稿日時: 2012/1/25 15:29
対応状況: −−−
|
神 登録日: 2008/6/4 居住地: 投稿: 7367 |
Re: 【 EC-CUBE 2.12 】商品一覧画面の速度改善(高速化)に関して意見を伺わせてください red 様
> これはそれ用のテーブルを作ってあげれば解決する問題かと思います。 > トリガーっぽいプログラムを作って常にデータを入れれば十分かと思います 検索用に冗長情報で構成するテーブルを追加するイメージでしょうか? > 高速化は確かに大事な課題なのですが、安定化とシンプルな実装化を目指したほうが結果的に全体がよくなるのではないでしょうか? 賛成です。 2.11系のカスタマイズでは、データ構造やロジックの理解で苦戦する事が多々ありまして。 コンピュータのパフォーマンスを引き出すのも重要ですが、ホモサピエンスのパフォーマンスを引き出すのも重要ですね。
|
ECCUORE |
投稿日時: 2012/1/25 15:55
対応状況: −−−
|
長老 登録日: 2009/10/22 居住地: 東京 投稿: 248 |
Re: 【 EC-CUBE 2.12 】商品一覧画面の速度改善(高速化)に関して意見を伺わせてください 引用:
同じような意見の方がいらして良かったです。 データ変更をトリガーとして、検索用データを更新するという思想はどうかなと思ってました。 大規模店舗の高速化案件では実際に使っております。 ただ、seasoftさんが仰るとおり冗長化しますので、標準設計では嫌がられるかな〜と考えてました。 引用:
redさん案なら、実装も今よりはシンプルになるかと思うのですがいかがでしょう。 ツリー構造の複雑なリレーションを理解するより、検索用テーブルの仕様を理解する方が容易かと思います。
|
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は単純にソースの可読性が悪いですし) なので、「人にシンプル、コンピュータに対しては高性能」を目標に可読性と性能のバランスの良い所を目指してく感じになるのでしょうかね。 もっと色々な人の意見も聞きたいです
|
« 1 2 (3) 4 5 6 » |
| 新しいものから | 前のトピック | 次のトピック | トップ |