機能要望 > その他 > もっとパフォーマンスのよい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を若干変えた物。
商品を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 を分離した場合は、大きな(重い)処理は早くなり、小さな(特に何度も繰り返されるような)処理は遅くなる傾向にありますね。
|
nanasess |
投稿日時: 2008/6/11 23:10
対応状況: −−−
|
神 登録日: 2006/9/9 居住地: 投稿: 2314 |
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 を分散できるので, 性能が上がることが多いです. |
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 も、既に一部はそのような動作もあるようです。中間テーブルまで作らなくとも、計算結果を冗長情報として保管する列を用意するという手法もありますね。(これも嫌いですが…)
|
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 » |
| 古いものから | 前のトピック | 次のトピック | トップ |