EC-CUBE 開発コミュニティ

> フロント機能 > 【 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 居住地: 投稿: 2311	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 デフォルトの方が有利かもしれません. 個人的には, どちらも甲乙つけがたく, できれば複数カテゴリのソート時のパフォーマンスなど, もっとボトルネックの大きいところにパワーを注いだ方がいいんじゃないかなと思いますが, いかがでしょうか?

nanasess	投稿日時: 2012/1/24 15:15 対応状況: −−−
神登録日: 2006/9/9 居住地: 投稿: 2311	Re: 【 EC-CUBE 2.12 】商品一覧画面の速度改善(高速化)に関して意見を伺わせてください引用： ECCUOREさんは書きました：しかも、現在の規格仕様だと大規模の方が運用に耐えられないのではないかという報告も上がっているわけで。 EC-CUBEの限界商品数を話題に挙げると規格がついてまといますが、それを商品数だけで表現できるようになったら良いのではないかと。「大規模を妥協」するのではなく、数十点〜数万点と全てのレンジの店舗、開発会社が納得できる設計を目指す為に現状の規格という仕様に固執する必要があるのかという議論が出来たら良いなと思ってます。規格の仕様を見なおした方が良いのではないかという意見には賛成です. ただ, 2.11 では, 規格よりも複数カテゴリのソートの方が, 性能のボトルネックになっていると感じます. 1カテゴリに1000点以上の商品をつっこむと, 性能劣化が顕著ですし.

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 居住地: 投稿: 7367	Re: 【 EC-CUBE 2.12 】商品一覧画面の速度改善(高速化)に関して意見を伺わせてください > ただ, 2.11 では, 規格よりも複数カテゴリのソートの方が, 性能のボトルネックになっていると感じます. 冒頭のケースでは、規格の方が明らかなボトルネックでした。そもそも、内部の処理時間を分析して、消費時間が大きいトップが規格周りだったので。ただ、現在の木構造を持っていても、規格を使わない場合は、パフォーマンスの差は少ないようです。1万商品で5%程度の差だったので、これは誤差の範囲だと思います。しかし、規格を使うとパフォーマンスが低下するというのは、明らかに意図とは異なる方向に働いてしまっているのでは感じるところです。カテゴリ周りに関して言えば、以前にざっと試した範囲では、ソートというよりも抽出の時点で結構コストを消費していた印象です。DB や商品件数にも強く依存があると思うので、一概には言えないと思いますが。改めてソートのコストに主眼を置いた条件で測定すると、確かにソートに消費しているコストは大きいですね。この部分も、何とか改善したいですね。 ---------------- Seasoft こちらでの投稿は、アイディア程度に留めさせていただいております。個別案件の作業は有償で承っております。お気軽にご相談ください。

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 の商品マスタを見慣れすぎて、頭が凝り固まってるかも。 ---------------- Seasoft こちらでの投稿は、アイディア程度に留めさせていただいております。個別案件の作業は有償で承っております。お気軽にご相談ください。

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系のカスタマイズでは、データ構造やロジックの理解で苦戦する事が多々ありまして。コンピュータのパフォーマンスを引き出すのも重要ですが、ホモサピエンスのパフォーマンスを引き出すのも重要ですね。 ---------------- 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 »