バージョン選択

フォーラム

メニュー

オンライン状況

58 人のユーザが現在オンラインです。 (44 人のユーザが フォーラム を参照しています。)
登録ユーザ: 0
ゲスト: 58
もっと...

サイト内検索

機能要望 > その他 > もっとパフォーマンスのよい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 T1.product_id,
           product_code_min,
           product_code_max,
           price01_min,
           price01_max,
           price02_min,
           price02_max,
           stock_min,
           stock_max,
           stock_unlimited_min,
           stock_unlimited_max,
           del_flg,
           status,
           name,
           comment1,
           comment2,
           comment3,
           main_list_comment,
           main_image,
           main_list_image,
           product_flag,
           deliv_date_id,
           sale_limit,
           point_rate,
           sale_unlimited,
           create_date,
           deliv_fee,
           rank
           ,(SELECT rank AS category_rank
               FROM dtb_category AS T4
              WHERE T1.category_id = T4.category_id) as category_rank
           ,(SELECT category_id AS sub_category_id 
               FROM dtb_category T4 
              WHERE T1.category_id = T4.category_id) as category_id
      FROM (SELECT T0.product_id,
                   T0.del_flg,
                   T0.status,
                   T0.name,
                   T0.comment1,
                   T0.comment2,
                   T0.comment3,
                   T0.main_list_comment,
                   T0.main_image,
                   T0.main_list_image,
                   T0.product_flag,
                   T0.deliv_date_id,
                   T0.sale_limit,
                   T0.point_rate,
                   T0.sale_unlimited,
                   T0.create_date,
                   T0.deliv_fee,
                   T00.category_id,
                   T00.rank
              FROM dtb_products AS T0
         LEFT JOIN dtb_product_categories AS T00
             USING (product_id)) AS T1 
RIGHT JOIN (SELECT product_id as product_id_sub,
                   MIN(product_code) AS product_code_min,
                   MAX(product_code) AS product_code_max,
                   MIN(price01) AS price01_min,
                   MAX(price01) AS price01_max,
                   MIN(price02) AS price02_min,
                   MAX(price02) AS price02_max,
                   MIN(stock) AS stock_min,
                   MAX(stock) AS stock_max,
                   MIN(stock_unlimited) AS stock_unlimited_min,
                   MAX(stock_unlimited) AS stock_unlimited_max
              FROM dtb_products_class GROUP BY product_id) AS T2 
                ON T1.product_id = T2.product_id_sub

でしたが、これを

select
  p.product_id,
  p.del_flg,
  p.status,
  p.name,
  p.comment1,
  p.comment2,
  p.comment3,
  p.main_list_comment,
  p.main_image,
  p.main_list_image,
  p.product_flag,
  p.deliv_date_id,
  p.sale_limit,
  p.point_rate,
  p.sale_unlimited,
  p.create_date,
  p.deliv_fee,
  pca.category_id,
  pclg.product_code_min,
  pclg.product_code_max,
  pclg.price01_min,
  pclg.price01_max,
  pclg.price02_min,
  pclg.price02_max,
  pclg.stock_min,
  pclg.stock_max,
  pclg.stock_unlimited_min,
  pclg.stock_unlimited_max
from dtb_products as p
left outer join dtb_product_categories as pca on pca.product_id = p.product_id
left outer join dtb_category as c on c.category_id = pca.category_id
right outer join (
  select
    pcl.product_id,
    min(pcl.product_code) as product_code_min,
    max(pcl.product_code) as product_code_max,
    min(pcl.price01) as price01_min,
    max(pcl.price01) as price01_max,
    min(pcl.price02) as price02_min,
    max(pcl.price02) as price02_max,
    min(pcl.stock) as stock_min,
    max(pcl.stock) as stock_max,
    min(pcl.stock_unlimited) as stock_unlimited_min,
    max(pcl.stock_unlimited) as stock_unlimited_max
  from dtb_products_class as pcl
  group by pcl.product_id
) as pclg on pclg.product_id = p.product_id

としてみました。元のは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の形のまま持つようにしていれば、一度の処理で何度もアクセスしないで済みます。


これでパフォーマンスが良くなったかと言うと、計測などしていないし、大幅のカスタマイズしつつなので結果は分かりません。
ずっと気になっていたので、どなたか詳しい方の意見を伺いたくて書かせて頂きました。


----------------
<開発環境>
EC-CUBE:2.4.1
DBサーバ:PostgreSQL 8.3.5
PHP:5.1.6

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
こちらでの投稿は、アイディア程度に留めさせていただいております。
個別案件の作業は有償で承っております。お気軽にご相談ください。

seasoft
投稿日時: 2008/6/27 12:36
対応状況: −−−
登録日: 2008/6/4
居住地:
投稿: 7367
Re: もっとパフォーマンスのよいEC-CUBE
「表示用の都合のいいテーブル」の採用は、ユーザによって、DBを直接編集したいという要求もありそうなので、その辺をどのようにカバーするかも課題ですかね。

現状の、テスト商品生成スクリプト の手順のように、最後に1商品を管理画面から再登録するといった手順とかなら許容範囲かなと思います。

その前に、SQL文の最適化などで解決を図るのが先でしょうけど。


----------------
Seasoft
こちらでの投稿は、アイディア程度に留めさせていただいております。
個別案件の作業は有償で承っております。お気軽にご相談ください。

« 1 2 (3) 4 5 6 »
| 古いものから 前のトピック | 次のトピック | トップ


 



ログイン


EC-CUBE公式 Amazon Payプラグイン

統計情報

総メンバー数は89,298名です
総投稿数は110,077件です

投稿数ランキング

1
seasoft
7367
2
468
3217
3
AMUAMU
2712
4
nanasess
2314
5
umebius
2085
6
yuh
1819
7
h_tanaka
1652
8
red
1570
9
mcontact
1302
10
tsuji
958
11
fukap
907
12
shutta
835
13
tao_s
799
14 ramrun 789
15 karin 689
16 sumida 641
17
homan
633
18 DELIGHT 572
19
patapata
502
20
flealog
485


ネットショップの壺

EC-CUBEインテグレートパートナー

Copyright© EC-CUBE CO.,LTD. All Rights Reserved.