バージョン選択

フォーラム

メニュー

オンライン状況

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

サイト内検索

機能要望 > その他 > もっとパフォーマンスのよいEC-CUBE

その他

新規スレッドを追加する

| 古いものから 前のトピック | 次のトピック | 下へ
投稿者 スレッド
career
投稿日時: 2008/6/26 14:43
対応状況: −−−
新米
登録日: 2008/6/26
居住地:
投稿: 3
Re: もっとパフォーマンスのよいEC-CUBE
表示用の都合のいいテーブルを作成し、商品登録時に更新しておくのが一番だと思いますが。

商品登録は多少遅くても管理者機能なので我慢できる範囲でしょう。

正規化という意味ではあまりよくないかもしれませんがね。

レスポンスを要求するなら一番です。
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と結果セットの行列に差はないはずですが、見落としもあるかもしれないので意見あれば助かります。
seasoft
投稿日時: 2008/6/12 21:13
対応状況: −−−
登録日: 2008/6/4
居住地:
投稿: 7367
Re: もっとパフォーマンスのよいEC-CUBE
ざっと該当箇所のソースを読んで、何をやっているかある程度は想像できるようになりました。

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

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


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


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

nanasess
投稿日時: 2008/6/11 23:10
対応状況: −−−
登録日: 2006/9/9
居住地:
投稿: 2314
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 を分散できるので, 性能が上がることが多いです.
tao
投稿日時: 2008/6/11 22:51
対応状況: −−−
一人前
登録日: 2007/12/28
居住地: 東京
投稿: 82
Re: もっとパフォーマンスのよいEC-CUBE
横から失礼します。

以前同様にWEBとDBのサーバーを分けた時に遅くなった経験があります。

その時はDBサーバーがDNSを引けない設定になっており、DBサーバーへの接続の際にDBユーザーの情報を取得するのに時間がかかっていました。
同様にデータベースが遅くなる現象は、DBサーバーへのコネクションに問題がある事が多かったのですが、そこら辺いかがですか?
x41
投稿日時: 2008/6/11 22:46
対応状況: −−−
仙人
登録日: 2007/11/23
居住地:
投稿: 308
Re: もっとパフォーマンスのよいEC-CUBE
seasoft様

当方の場合はEC-CUBE(ver2系)とDB(ローカル接続)を別々のサーバーで稼動させています(テスト環境)。商品数3000、カテゴリ約400ぐらいです。当初、mysqlでしたが、速度がおそい(ページ切り替えに約10分)のでmysqlをチューニングをしました。それでもページ切り替えに約40秒ほどかかりました。その後、postgresqlに変更しチューニングしました。変化はありましたがそれでも切り替えに約5秒〜10秒かかります。負荷がかかっていない状態でこのパフォーマンスなので負荷がかかった場合はまだ遅いでしょう。メモリも増やしましたがあまり変化はありませんでした。postgresqlの7系と8系ともに試しましたが、変化なしでした。

このスレには非常に興味があります。いろいろ試したいとおもいますので、ご教授お願い致します。
tao
投稿日時: 2008/6/11 21:21
対応状況: −−−
一人前
登録日: 2007/12/28
居住地: 東京
投稿: 82
Re: もっとパフォーマンスのよいEC-CUBE
引用:
商用DBに乗せかえるとか…


商用DBですか・・・
実際弊社でも「DB2に」という案件が稼動中です。(まだ実装していませんが)
商用のDBに乗せかえると、逃げた様な負けた様な気分がするのは私だけでしょうか?
seasoft
投稿日時: 2008/6/11 21:04
対応状況: −−−
登録日: 2008/6/4
居住地:
投稿: 7367
Re: もっとパフォーマンスのよいEC-CUBE
とりあえず、テスト商品生成スクリプトに少し手を加えて、ランダムさを持たせたデータでも、同一の出力を得られたので、大丈夫かなとは思うのですが。


大河内様

いえいえ、お聞きしようかなとも思ったのですが、SQL分析に没頭しちゃいまして。

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

まだ、SQLの入れ替えをするほどに EC-CUBE を理解できていませんが、少しその辺りのソースを覗いてみようかなと思います。


tao 様

商用DBに乗せかえるとか…

実際まだまだ、有名どころのオプティマイザー(実行最適化)の能力は凄いですね。金融分析で、PostgreSQL を使おうと頑張ったことがありましたが、結局 MS-SQL に移行しちゃいました。

どなたかが、Oracle 対応を望む投稿をされていましたが、実際それで動かせれば、別の利用者層も取り込めそうですね。まぁ、2つのDBに対応しているというだけで、凄いと思います。

さて、現実的な解としてですが、まずはボトルネックの特定ですね。先に投稿した、sql1.txt ならば、T4 を生成する過程が、ネックのようです。Oracle のように、結合結果をインデックスに持てれば早いのですが… 無理かなぁ。

テーブルの更新頻度が低いなら、更新時に中間テーブルを用意するというのも手ですね。(個人的には嫌いですが。) EC-CUBE も、既に一部はそのような動作もあるようです。中間テーブルまで作らなくとも、計算結果を冗長情報として保管する列を用意するという手法もありますね。(これも嫌いですが…)


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

tao
投稿日時: 2008/6/11 9:57
対応状況: −−−
一人前
登録日: 2007/12/28
居住地: 東京
投稿: 82
Re: もっとパフォーマンスのよいEC-CUBE
ありがとうございます。
非常に勉強になりました。早速色々試してみます。

これ以上のチューニングとなるとインデックスの見直しやDB自体の設定(キャッシュとか?)になるのでしょうか?
nanasess
投稿日時: 2008/6/11 9:46
対応状況: −−−
登録日: 2006/9/9
居住地:
投稿: 2314
Re: もっとパフォーマンスのよいEC-CUBE
大河内です.

seasoft 様, ありがとうございます!
説明不足で恐縮でした...

先の書き込みで出した SQL は, 2.x 系で商品一覧表示時に生成される SQL です.

PostgreSQL では, 先の SQL が発行される際, 実際は, vm_products_allclass という VIEW が使用されますので, PostgreSQL と MySQL の場合とでは異なります.
先の書き込みのものは, VIEW をサブクエリに置換した MySQL で使用されるものです.

こちらで, すぐに検証可能な環境が無いので恐縮なのですが,
商品一覧表示時に, VIEW を使用せず, 上記 SQL を使うようにカスタマイズしてやれば良さそうですね.

あとは, ソート条件でしょうか.
実際は, この他に価格順と新着順でソートする必要があります.
PostgreSQL と, MySQL の両方をサポートするのには非常に苦労しました...
« 1 2 3 (4) 5 6 »
| 古いものから 前のトピック | 次のトピック | トップ


 



ログイン


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

統計情報

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

投稿数ランキング

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.