バージョン選択

フォーラム

メニュー

オンライン状況

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

PR

デザインテンプレート EC-CUBE3.0版が登場!
広告掲載について

サイト内検索

機能要望 > その他 > もっとパフォーマンスのよい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
居住地: 宝塚
投稿: 1662
Re: もっとパフォーマンスのよいEC-CUBE
大河内です.
まとめてレス失礼致します.

seasoft 様
引用:

なるほど、PostgreSQL と MySQL で呼び出し方が違うのですね。異種DB間での苦労を感じますね。ちなみに、VIEW を使う・使わないという違いは、昔の MySQL でビューが使えなかったというような、歴史的な理由ですかね?


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
居住地:
投稿: 7331
Re: もっとパフォーマンスのよいEC-CUBE
ざっと該当箇所のソースを読んで、何をやっているかある程度は想像できるようになりました。

ちなみに、pgsql の方の現実装は、先日のSQL文よりは幾分良い状態にあるように思います。逆を言えば、mysql 用のSQL文に固有の問題がある気がしますが、ビュー&インラインビューの概念で共通化を図る上で、避けがたい問題なのかもしれません。

高速化に成功しても、保守性が極端に悪くなるのは嫌ですし、バランスが難しいところですね。


Webサーバーと DB を分離した場合は、大きな(重い)処理は早くなり、小さな(特に何度も繰り返されるような)処理は遅くなる傾向にありますね。


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

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を若干変えた物。
            "vw_products_allclass" => '
(    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,
        T1.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,
        T1.create_date,
        deliv_fee,
        T1.rank,
        T4.category_rank,
        T4.category_id
    FROM
    (
        SELECT *
        FROM 
        (
           SELECT
                product_id,
                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 T0
        LEFT JOIN dtb_products USING (product_id)
    ) AS T1
    INNER JOIN
    (
        SELECT 
            T2.product_id,
            MAX(T2.category_id) AS category_id,
            MAX(T3.rank) AS category_rank
        FROM dtb_product_categories T2
        INNER JOIN dtb_category T3 USING (category_id)
        GROUP BY product_id
    ) AS T4 
    USING (product_id)
)',

商品を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
居住地:
投稿: 7331
Re: もっとパフォーマンスのよいEC-CUBE
「表示用の都合のいいテーブル」の採用は、ユーザによって、DBを直接編集したいという要求もありそうなので、その辺をどのようにカバーするかも課題ですかね。

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

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


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

seasoft
投稿日時: 2008/8/21 0:08
対応状況: −−−
登録日: 2008/6/4
居住地:
投稿: 7331
Re: もっとパフォーマンスのよいEC-CUBE
SQL文の最適化を試みる改訂をコミュニティ版にコミットしました。(r17549)

興味のある方は、テストや改良をお願いします。

かなり積極的な改訂を含むので、新たな不具合を含んでいると思います。


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

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


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


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

フラット表示 前のトピック | 次のトピック


題名 投稿者

 



ログイン


EC-CUBEペイメント

クレジットカード情報の非保持化対応

統計情報

総メンバー数は20,548名です
総投稿数は83,580件です

投稿数ランキング

1
seasoft
7331
2
AMUAMU
2712
3
nanasess
1662
4
yuh
1430
5
red
1076
6
fukap
907
7
shutta
827
8
468
800
9 ramrun 789
10
tsuji
784
11
umebius
723
12
tao_s
651
13 karin 641
14 sumida 638
15
homan
633
16 DELIGHT 571
17
patapata
502
18
flealog
483
19 tonton 436
20
ecbg
387


ネットショップの壺

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

Copyright© LOCKON CO.,LTD. All Rights Reserved.