EC-CUBE 開発コミュニティ

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

その他

投稿者	スレッド
seasoft	投稿日時: 2008/6/8 22:51 対応状況: −−−
神登録日: 2008/6/4 居住地: 投稿: 7367	Re: もっとパフォーマンスのよいEC-CUBE なかなか、面白そうな課題ですね。しかし、古いバージョンへの対応はなかなか難しそうですね。(個人的には、ガンガン上げちゃえな思想なので。) ちなみに、こういったテストをするのに適当な規模のサンプルデータとかって、公開されていたりしますかね。ありましたら、教えてください。もしくは、データ生成するアイディアなど。 ---------------- Seasoft こちらでの投稿は、アイディア程度に留めさせていただいております。個別案件の作業は有償で承っております。お気軽にご相談ください。

ゲスト	投稿日時: 2008/6/8 23:16 対応状況: −−−
	Re: もっとパフォーマンスのよいEC-CUBE 下記リンクにテスト商品を登録出来るスクリプトが掲載されています。テスト商品生成スクリプト

seasoft	投稿日時: 2008/6/8 23:37 対応状況: −−−
神登録日: 2008/6/4 居住地: 投稿: 7367	Re: もっとパフォーマンスのよいEC-CUBE ありがとうございます！あるものですね。パフォーマンス以外の面でも、色々と試したかったので助かります。 ---------------- Seasoft こちらでの投稿は、アイディア程度に留めさせていただいております。個別案件の作業は有償で承っております。お気軽にご相談ください。

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$ / で生成したデータでの出力結果は同一なことは確認しました。引用： [xxx@localhost www]$ time psql -U postgres -o out0 eccube_dev < sql0 real 0m1.637s user 0m0.009s sys 0m0.017s [xxx@localhost www]$ time psql -U postgres -o out0 eccube_dev < sql0 real 0m1.625s user 0m0.007s sys 0m0.020s [xxx@localhost www]$ time psql -U postgres -o out0 eccube_dev < sql0 real 0m1.621s user 0m0.008s sys 0m0.020s [xxx@localhost www]$ time psql -U postgres -o out1 eccube_dev < sql1.txt real 0m0.085s user 0m0.010s sys 0m0.017s [xxx@localhost www]$ time psql -U postgres -o out1 eccube_dev < sql1.txt real 0m0.084s user 0m0.011s sys 0m0.016s [xxx@localhost www]$ time psql -U postgres -o out1 eccube_dev < sql1.txt real 0m0.089s user 0m0.007s sys 0m0.019s [xxx@localhost www]$ ll out -rw-rw-r-- 1 xxx xxx 48730 2008-06-10 00:52 out0 -rw-rw-r-- 1 xxx xxx 48730 2008-06-10 00:53 out1 [xxx@localhost www]$ diff -s out0 out1 ファイルout0とout1は同一あとは効果的なインデックスが貼れたら良いのですが。どうも、pgsqlのインデックスは苦手で。むしろ、さらにSQL文を最適化した方が効果的かも。 ---------------- Seasoft こちらでの投稿は、アイディア程度に留めさせていただいております。個別案件の作業は有償で承っております。お気軽にご相談ください。

seasoft	投稿日時: 2008/6/11 2:53 対応状況: −−−
神登録日: 2008/6/4 居住地: 投稿: 7367	Re: もっとパフォーマンスのよいEC-CUBE 株式会社ロックオンさんに権利問題の確認も取れましたので、とりあえず現状のSQL文を張っておきます。 sql1.txt 引用： 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, T4.product_rank, T4.category_rank 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 v1 LEFT JOIN dtb_products USING (product_id) ) AS T1 INNER JOIN ( SELECT max(T3.rank) AS category_rank, max(T2.rank) AS product_rank, T2.product_id FROM dtb_product_categories T2 INNER JOIN dtb_category T3 USING (category_id) GROUP BY product_id ) AS T4 USING (product_id) ORDER BY T4.category_rank DESC, T4.product_rank DESC ここ24時間は忙しく、進展なしです。 ---------------- Seasoft こちらでの投稿は、アイディア程度に留めさせていただいております。個別案件の作業は有償で承っております。お気軽にご相談ください。

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 も、既に一部はそのような動作もあるようです。中間テーブルまで作らなくとも、計算結果を冗長情報として保管する列を用意するという手法もありますね。(これも嫌いですが…) ---------------- Seasoft こちらでの投稿は、アイディア程度に留めさせていただいております。個別案件の作業は有償で承っております。お気軽にご相談ください。

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 »