機能要望 > その他 > もっとパフォーマンスのよいEC-CUBE |
その他
フラット表示 | 前のトピック | 次のトピック |
投稿者 | スレッド |
---|---|
tao |
投稿日時: 2008/6/11 22:51
対応状況: −−−
|
一人前 登録日: 2007/12/28 居住地: 東京 投稿: 82 |
Re: もっとパフォーマンスのよいEC-CUBE 横から失礼します。
以前同様にWEBとDBのサーバーを分けた時に遅くなった経験があります。 その時はDBサーバーがDNSを引けない設定になっており、DBサーバーへの接続の際にDBユーザーの情報を取得するのに時間がかかっていました。 同様にデータベースが遅くなる現象は、DBサーバーへのコネクションに問題がある事が多かったのですが、そこら辺いかがですか? |
nanasess |
投稿日時: 2008/6/11 23:10
対応状況: −−−
|
神 登録日: 2006/9/9 居住地: 投稿: 2313 |
Re: もっとパフォーマンスのよいEC-CUBE 大河内です.
まとめてレス失礼致します. seasoft 様 引用:
EC-CUBE の動作要件として, MySQL 4.1 があるのです. このため, MySQL 用の SQL は VIEW をサブクエリに置換するようにしています. PostgreSQL の場合は, メンテしやすいので VIEW を使用しているようです. tao 様 以前, Oracle 10g Express で EC-CUBE を動かそうとしたことがあります. トップページを表示させるところまでいきましたが, かなり大変でした.. x41 様 経験則ですが, DB の種類や, OS の違い, CPU の差よりも, ディスクIOの性能で大きくパフォーマンスが変ります. 簡単に性能を上げるには, 最新の SASディスクなど, 速いディスクを使用すると良いと思います. もちろん, それを活かすチューニングは必要ですが... また, 個人的には, PostgreSQL 8.3 の性能が非常に良くて気に入ってます. tao 様 ボトルネックがネットワークなのか, その他なのかをしっかり切り分ける必要がありそうですね. 通常, Webサーバーと DB を別のサーバーにした場合, CPU 負荷と IO を分散できるので, 性能が上がることが多いです. |
seasoft |
投稿日時: 2008/6/12 21:13
対応状況: −−−
|
神 登録日: 2008/6/4 居住地: 投稿: 7367 |
Re: もっとパフォーマンスのよいEC-CUBE ざっと該当箇所のソースを読んで、何をやっているかある程度は想像できるようになりました。
ちなみに、pgsql の方の現実装は、先日のSQL文よりは幾分良い状態にあるように思います。逆を言えば、mysql 用のSQL文に固有の問題がある気がしますが、ビュー&インラインビューの概念で共通化を図る上で、避けがたい問題なのかもしれません。 高速化に成功しても、保守性が極端に悪くなるのは嫌ですし、バランスが難しいところですね。 Webサーバーと DB を分離した場合は、大きな(重い)処理は早くなり、小さな(特に何度も繰り返されるような)処理は遅くなる傾向にありますね。
|
mica |
投稿日時: 2008/6/26 13:47
対応状況: −−−
|
新米 登録日: 2008/6/23 居住地: 投稿: 3 |
Re: もっとパフォーマンスのよいEC-CUBE 私も現在DBにMySQLを利用していますが、商品が1000件を超えたあたりからのレスポンスが酷いことに気づいたため、調整出来るところを探して変更してみました。
/data/class/db/dbfactory/SC_DB_DBFactory_MYSQL.php クラス:SC_DB_DBFactory_MYSQL メソッド:viewToSubQuery() 上記メソッドで返している配列のうち、キー'vw_products_allclass'に割り当てられた要素を以下のように変更。 ※中身は前にseasoftさんの提示したSQLを若干変えた物。
商品を4000件ほど登録してフロントTOPページを表示するとき、元のSQLで160秒ほど掛かっていた問い合わせが上記の変更で8秒ほど結果が返ってくる程度まで改善しました。 まだ十分に満足できるレスポンスではありませんが、最も楽にかなり広範囲のページに対応できるためこのような方法を採っています。 各部分で専用のSQLを用意すればパフォーマンス的には最適ですが、そうなると書き換える箇所が多すぎて。 元のSQLと結果セットの行列に差はないはずですが、見落としもあるかもしれないので意見あれば助かります。 |
career |
投稿日時: 2008/6/26 14:43
対応状況: −−−
|
新米 登録日: 2008/6/26 居住地: 投稿: 3 |
Re: もっとパフォーマンスのよいEC-CUBE 表示用の都合のいいテーブルを作成し、商品登録時に更新しておくのが一番だと思いますが。
商品登録は多少遅くても管理者機能なので我慢できる範囲でしょう。 正規化という意味ではあまりよくないかもしれませんがね。 レスポンスを要求するなら一番です。 |
seasoft |
投稿日時: 2008/6/27 12:36
対応状況: −−−
|
神 登録日: 2008/6/4 居住地: 投稿: 7367 |
Re: もっとパフォーマンスのよいEC-CUBE 「表示用の都合のいいテーブル」の採用は、ユーザによって、DBを直接編集したいという要求もありそうなので、その辺をどのようにカバーするかも課題ですかね。
現状の、テスト商品生成スクリプト の手順のように、最後に1商品を管理画面から再登録するといった手順とかなら許容範囲かなと思います。 その前に、SQL文の最適化などで解決を図るのが先でしょうけど。
|
seasoft |
投稿日時: 2008/8/21 0:08
対応状況: −−−
|
神 登録日: 2008/6/4 居住地: 投稿: 7367 |
Re: もっとパフォーマンスのよいEC-CUBE SQL文の最適化を試みる改訂をコミュニティ版にコミットしました。(r17549)
興味のある方は、テストや改良をお願いします。 かなり積極的な改訂を含むので、新たな不具合を含んでいると思います。
|
akira |
投稿日時: 2008/12/14 3:28
対応状況: −−−
|
半人前 登録日: 2008/10/24 居住地: 投稿: 24 |
Re: もっとパフォーマンスのよいEC-CUBE この投稿にとても興味があり投稿させて頂きました。
現在、私はZencertをメインにサイト構築しています。 商品数は600件ぐらいまで登録していますが、 レスポンスの低下は、今のところ感じていません。 同時進行で、EC-CUBEでのオンラインショップの構築も進めているのですが、 そこで、この投稿をみて、レスポンスに不安を感じ、投稿させて頂きました。 SQL文の最適化は、V2.3.3には反映されているのでしょうか? または、次のリリースに反映される予定はあるのでしょうか? ご回答よろしくお願いします。 |
topo |
投稿日時: 2008/12/14 11:04
対応状況: −−−
|
常連 登録日: 2008/6/11 居住地: 岡山 投稿: 64 |
Re: もっとパフォーマンスのよいEC-CUBE 私もパフォーマンスで悩んでいます。 以下のSQLに変更することで1000件程度であればある程度動くようになりました。 http://xoops.ec-cube.net/modules/newbb/viewtopic.php?viewmode=thread&topic_id=2262&forum=3&post_id=8779#forumpost8779 ただデータ量は9000件程度に増やしてやっていますが・・・かなり遅いです^^; 個人的な感想としては『このままサービスインは難しい』という感想です。 構造が悪いというと厳しい表現になるかもしれませんがデータ件数が増える たびに以下の3テーブルにレコードが増えるのでデータ件数が増えると 加速度的にSQLが重くなっていきます^^; ・dtb_products ・dtb_products_class ・dtb_product_categories 改善にはやはり単一のテーブルを見るような形にするしかないのかと 思うのですが、両方対応するにはかなり修正範囲が大きいので怖い限りです・・・ 【1】 『dtb_products』に『dtb_products_class』から派生するデータを冗長カラムとして持つ。 →データ更新の度に冗長カラムを更新する処理が必要 【2】 『dtb_products』に『dtb_product_categories』の複数カテゴリを1カラムに『'1','2','3','4','5'』の ような形でデータを持ち、likeで当てたほうがJoinが発生しなくなっていい様な気がします。 →データ更新の度に冗長カラムを更新する処理が必要 単一のテーブルを見る擬似実験として以下の処理で試してみました。 ※以下のSQLは正常動作するものではないので気をつけてください^^; /data/class/db/dbfactory/SC_DB_DBFactory_MYSQL.php 上のファイルの中を以下の形にして速度実験してみました。 "vw_products_allclass" => ' ( SELECT T1.product_id, 0 AS product_code_min, 0 AS product_code_max, 0 AS price01_min, 0 AS price01_max, 0 AS price02_min, 0 AS price02_max, 0 AS stock_min, 0 AS stock_max, 0 AS stock_unlimited_min, 0 AS stock_unlimited_max, T1.del_flg, T1.status, T1.name, T1.comment1, T1.comment2, T1.comment3, T1.main_list_comment, T1.main_image, T1.main_list_image, T1.product_flag, T1.deliv_date_id, T1.sale_limit, T1.point_rate, T1.sale_unlimited, T1.create_date, T1.deliv_fee, T1.rank, 0 AS category_rank, 0 AS category_id FROM dtb_products AS T1 )', SQL単品で流すと非常に早いレスポンスになったので期待したのですが そんなに早くないのでSQLレベル以外で問題があるような気もします・・・ 表示中の列 0 - 29 (9,308 合計, クエリの実行時間 0.0008 秒) 600件ぐらいまでであれば使って見ても良い気がしますが、データが増えてきた時に 自分でSQLをカスタマイズできないと危ないような気もします・・・ ご参考までにどうぞm(_ _)m |
four |
投稿日時: 2008/12/15 10:41
対応状況: −−−
|
半人前 登録日: 2008/8/4 居住地: 投稿: 15 |
Re: もっとパフォーマンスのよいEC-CUBE お世話になっております。
私も商品登録関係のカスタマイズをしていて、気になった点が幾つかありました。 今までSQL文についての投稿は多かったのですが、見当たらないようなので挙げてみます。 ただ、当方は今までDBではOracleやDB2、言語はC++やCなどを使用した開発に携わっていて、PHPなどを使ったWeb系の開発は初心者です。 見当違いなアプローチかも知れませんが、熟練されている方のアドバイスを頂けたら嬉しいです。 ・クラスオブジェクトを生成し過ぎているのでは? SC_Queryクラスなど、必要な時点で生成しています。 1商品へのアプローチで、カテゴリなど細かい処理が複数走りますが、最も細かい処理でも新規にオブジェクトを持つので、オブジェクトの生成数はかなりの量になります。 特にDB接続関係のオブジェクトは呼び出しの際の接続処理が走ると思いますので、大量発生させるのはいかがなものかと思いました。 オブジェクトを共通で使用しないことで、バグも発生すると思います。 商品のCSV登録処理では、トランザクションを使ってエラーがあるとRollbackしている仕様ですが、オブジェクトを各自別で使用しているので、全ての処理にRollbackが適用されないのではないでしょうか? これは検証しておりませんが、当方のカスタマイズではオブジェクトを1つにしました。 C++で開発していた際には、パフォーマンスの向上のために、オブジェクトはなるべく引数で渡して使用していました。 ・DB参照しすぎでは? とりあえず、DBの参照が多すぎるように感じます。 以前の開発では考えられないくらい乱発していて驚いているのですが、Web系の処理だと気にしなくても良いレベルなのでしょうか? 以前の習慣が抜けないもので、私は一度アクセスした情報はArrayに持つようにしました。 大抵は二次元配列で必要な分だけDBの形のまま持つようにしていれば、一度の処理で何度もアクセスしないで済みます。 これでパフォーマンスが良くなったかと言うと、計測などしていないし、大幅のカスタマイズしつつなので結果は分かりません。 ずっと気になっていたので、どなたか詳しい方の意見を伺いたくて書かせて頂きました。
|
フラット表示 | 前のトピック | 次のトピック |
題名 | 投稿者 |
---|