機能要望 > その他 > もっとパフォーマンスのよいEC-CUBE |
その他
| 新しいものから | 前のトピック | 次のトピック | 下へ |
投稿者 | スレッド |
---|---|
seasoft |
投稿日時: 2008/6/8 22:51
対応状況: −−−
|
神 登録日: 2008/6/4 居住地: 投稿: 7367 |
Re: もっとパフォーマンスのよいEC-CUBE なかなか、面白そうな課題ですね。
しかし、古いバージョンへの対応はなかなか難しそうですね。(個人的には、ガンガン上げちゃえな思想なので。) ちなみに、こういったテストをするのに適当な規模のサンプルデータとかって、公開されていたりしますかね。ありましたら、教えてください。もしくは、データ生成するアイディアなど。
|
ゲスト |
投稿日時: 2008/6/8 23:16
対応状況: −−−
|
Re: もっとパフォーマンスのよいEC-CUBE 下記リンクにテスト商品を登録出来るスクリプトが掲載されています。
テスト商品生成スクリプト |
|
seasoft |
投稿日時: 2008/6/8 23:37
対応状況: −−−
|
神 登録日: 2008/6/4 居住地: 投稿: 7367 |
Re: もっとパフォーマンスのよいEC-CUBE ありがとうございます!
あるものですね。 パフォーマンス以外の面でも、色々と試したかったので助かります。
|
seasoft |
投稿日時: 2008/6/10 2:41
対応状況: −−−
|
神 登録日: 2008/6/4 居住地: 投稿: 7367 |
Re: もっとパフォーマンスのよいEC-CUBE 何をするSQLかが分から無かったので、SQLを解析してみたのですが、その過程でSQLの最適化で、そこそこ速度が上がりました。
とりあえず、3回の平均値で 1.627sec → 0.086sec と、18.92倍程度にはなっています。 (いや… SQL文の目的を理解せずに分析したので、何か壊しちゃったかも。だったら、もの凄くゴメンなさい…) 少なくとも、 /* * EC-CUBE データ生成スクリプト * * Copyright(c) 2000-2008 LOCKON CO.,LTD. All Rights Reserved. * * http://www.lockon.co.jp/ * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License * as published by the Free Software Foundation; either version 2 * of the License, or (at your option) any later version. * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. * * @auther Kentaro Ohkouchi * @version $Id$ */ で生成したデータでの出力結果は同一なことは確認しました。 引用:
あとは効果的なインデックスが貼れたら良いのですが。どうも、pgsqlのインデックスは苦手で。 むしろ、さらにSQL文を最適化した方が効果的かも。
|
seasoft |
投稿日時: 2008/6/11 2:53
対応状況: −−−
|
神 登録日: 2008/6/4 居住地: 投稿: 7367 |
Re: もっとパフォーマンスのよいEC-CUBE 株式会社ロックオンさんに権利問題の確認も取れましたので、とりあえず現状のSQL文を張っておきます。
sql1.txt 引用:
ここ24時間は忙しく、進展なしです。
|
nanasess |
投稿日時: 2008/6/11 9:46
対応状況: −−−
|
神 登録日: 2006/9/9 居住地: 投稿: 2313 |
Re: もっとパフォーマンスのよいEC-CUBE 大河内です.
seasoft 様, ありがとうございます! 説明不足で恐縮でした... 先の書き込みで出した SQL は, 2.x 系で商品一覧表示時に生成される SQL です. PostgreSQL では, 先の SQL が発行される際, 実際は, vm_products_allclass という VIEW が使用されますので, PostgreSQL と MySQL の場合とでは異なります. 先の書き込みのものは, VIEW をサブクエリに置換した MySQL で使用されるものです. こちらで, すぐに検証可能な環境が無いので恐縮なのですが, 商品一覧表示時に, VIEW を使用せず, 上記 SQL を使うようにカスタマイズしてやれば良さそうですね. あとは, ソート条件でしょうか. 実際は, この他に価格順と新着順でソートする必要があります. PostgreSQL と, MySQL の両方をサポートするのには非常に苦労しました... |
tao |
投稿日時: 2008/6/11 9:57
対応状況: −−−
|
一人前 登録日: 2007/12/28 居住地: 東京 投稿: 82 |
Re: もっとパフォーマンスのよいEC-CUBE ありがとうございます。
非常に勉強になりました。早速色々試してみます。 これ以上のチューニングとなるとインデックスの見直しや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 21:21
対応状況: −−−
|
一人前 登録日: 2007/12/28 居住地: 東京 投稿: 82 |
Re: もっとパフォーマンスのよいEC-CUBE 引用:
商用DBに乗せかえるとか… 商用DBですか・・・ 実際弊社でも「DB2に」という案件が稼動中です。(まだ実装していませんが) 商用の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系ともに試しましたが、変化なしでした。 このスレには非常に興味があります。いろいろ試したいとおもいますので、ご教授お願い致します。 |
« 1 (2) 3 4 5 6 » |
| 新しいものから | 前のトピック | 次のトピック | トップ |