機能要望 > その他 > もっとパフォーマンスのよいEC-CUBE |
その他
| 古いものから | 前のトピック | 次のトピック | 下へ |
投稿者 | スレッド |
---|---|
xunfeng |
投稿日時: 2009/1/30 16:06
対応状況: −−−
|
新米 登録日: 2008/12/4 居住地: Fukui 投稿: 5 |
Re: もっとパフォーマンスのよいEC-CUBE 初めて投稿いたします。
ちょっとエラーの出る条件までは調べていないのですが、 kurushimaqさんが書きこんでいただいたコードですと、 一部のデータを編集する際にシステムエラー。 複製でシステムエラー。 確認で別のカテゴリーが表示されてしまうようです。 表示速度は速くなっているのですが。。。 書き逃げみたいで申し訳ありませんが、ご報告まで。 結局、PostgreSQL使うというのが最終手段なんですかね? |
topo |
投稿日時: 2008/12/20 18:26
対応状況: −−−
|
常連 登録日: 2008/6/11 居住地: 岡山 投稿: 64 |
Re: もっとパフォーマンスのよいEC-CUBE >four様
元Oracle使いとしてはSQLレベルのチューニングで なんとかできると信じています^^; 構造的な部分は・・・わかる方お願いしますw >mojaxp様 横槍といわずいっぱいご意見聞かせてくださいませm(_ _)m PHPの開発案件をがっつりやった経験が薄いのでクラスオブジェクトの方は 判断が付きませんがDBの構造とかはちょっと・・・って気がします^^; |
kurushimaq |
投稿日時: 2008/12/18 18:23
対応状況: −−−
|
新米 登録日: 2008/12/18 居住地: 投稿: 1 |
Re: もっとパフォーマンスのよいEC-CUBE 僕もhttp://xoops.ec-cube.net/modules/newbb/viewtopic.php?viewmode=thread&topic_id=2262&forum=3&post_id=8779#forumpost8779を試してみましたが、カテゴリ表記で不具合がありました。
元のSQLは、
でしたが、これを
としてみました。元のはselect中でサブクエリを使っているので、 行ごとに検索されるのと、left joinにしました。 |
sakurai07 |
投稿日時: 2008/12/18 14:45
対応状況: −−−
|
長老 登録日: 2008/2/29 居住地: 投稿: 179 |
Re: もっとパフォーマンスのよいEC-CUBE http://xoops.ec-cube.net/modules/newbb/viewtopic.php?viewmode=thread&topic_id=2262&forum=3&post_id=8779#forumpost8779
をやってみたのですが、 商品登録時にカテゴリ登録を下記2つに登録した場合に起きているるようです。レスポンスは良くなりました。 ・新作 ・トップス ↓カテゴリの階層です。 トップス > ワンピース・チュニック > 七分袖 トップス > ワンピース・チュニック > チュニック 一覧ページで新作カテゴリにのみ表示されていてトップスのカテゴリには表示されていません。 カテゴリーブロックには「商品名(商品数)」は表示されています。 |
mojaxp |
投稿日時: 2008/12/16 3:59
対応状況: −−−
|
常連 登録日: 2007/11/28 居住地: 岩手県盛岡市 投稿: 57 |
Re: もっとパフォーマンスのよいEC-CUBE 横槍失礼。
>・クラスオブジェクトを生成し過ぎているのでは? >・DB参照しすぎでは? 多分、fourさん同様、私(C/400)含め、他の開発言語でアプリを開発してきた皆さんはわかってることだと思うよ。 だから自分で少しずつ手直しして使っているのが現状だと思う。 DBもしかりだ。 私事でなんだが、遙か昔、AS/400で始めてアプリ作った時こういうDB設計してしこたま怒られたことがあった(笑 |
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の形のまま持つようにしていれば、一度の処理で何度もアクセスしないで済みます。 これでパフォーマンスが良くなったかと言うと、計測などしていないし、大幅のカスタマイズしつつなので結果は分かりません。 ずっと気になっていたので、どなたか詳しい方の意見を伺いたくて書かせて頂きました。
|
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 |
akira |
投稿日時: 2008/12/14 3:28
対応状況: −−−
|
半人前 登録日: 2008/10/24 居住地: 投稿: 24 |
Re: もっとパフォーマンスのよいEC-CUBE この投稿にとても興味があり投稿させて頂きました。
現在、私はZencertをメインにサイト構築しています。 商品数は600件ぐらいまで登録していますが、 レスポンスの低下は、今のところ感じていません。 同時進行で、EC-CUBEでのオンラインショップの構築も進めているのですが、 そこで、この投稿をみて、レスポンスに不安を感じ、投稿させて頂きました。 SQL文の最適化は、V2.3.3には反映されているのでしょうか? または、次のリリースに反映される予定はあるのでしょうか? ご回答よろしくお願いします。 |
seasoft |
投稿日時: 2008/8/21 0:08
対応状況: −−−
|
神 登録日: 2008/6/4 居住地: 投稿: 7367 |
Re: もっとパフォーマンスのよいEC-CUBE SQL文の最適化を試みる改訂をコミュニティ版にコミットしました。(r17549)
興味のある方は、テストや改良をお願いします。 かなり積極的な改訂を含むので、新たな不具合を含んでいると思います。
|
seasoft |
投稿日時: 2008/6/27 12:36
対応状況: −−−
|
神 登録日: 2008/6/4 居住地: 投稿: 7367 |
Re: もっとパフォーマンスのよいEC-CUBE 「表示用の都合のいいテーブル」の採用は、ユーザによって、DBを直接編集したいという要求もありそうなので、その辺をどのようにカバーするかも課題ですかね。
現状の、テスト商品生成スクリプト の手順のように、最後に1商品を管理画面から再登録するといった手順とかなら許容範囲かなと思います。 その前に、SQL文の最適化などで解決を図るのが先でしょうけど。
|
« 1 2 (3) 4 5 6 » |
| 古いものから | 前のトピック | 次のトピック | トップ |