機能要望 > その他 > もっとパフォーマンスのよいEC-CUBE |
その他
フラット表示 | 前のトピック | 次のトピック |
投稿者 | スレッド |
---|---|
ゲスト |
投稿日時: 2008/6/2 18:14
対応状況: −−−
|
もっとパフォーマンスのよいEC-CUBE 現在、以下の環境でテストを行っております。
・eccube-2.2.0-beta ・Windows2003Server ・Apache2.2 ・PHP 5.2.4 ・PostgreSQL8.3 ちなみに、マシンは ・IntelPentium 4 ・メモリ1G のものを使用しております。 テストデータとして、 ・カテゴリ3,000件 ・カテゴリに均等に割り付けた商品10,000件 ・全商品に対して規格を5件 入れた後に動作確認をしてみたのですが、すこぶるパフォーマンスが悪いです。 管理画面の一部ではスクリプトのタイムアウトが発生します。 プログラムやデータベースが多少触れる程度の私でも、同様の環境でデータ数が2,000,000件ほどあるシステムを構築した事がありますが、キャッシュ等を利用せずにレスポンスまでの時間が1秒弱くらいでしたので、環境の問題では決してないような気がします...。 現在作成しようとしているショップではカテゴリ数5,000件、商品数100,000件までは動作保障できる、かつ、レンタルサーバで動作可能なショップにしたいと思っております。 それには及ばないにせよ、もう少しそれに近づけるような、高品質のEC-CUBEを構築していただきたいと思います。 機能が沢山あるのはとても嬉しいのですが、それ以前に Webサイトとしてパフォーマンスが大事だと思います。 現状のパフォーマンスでは正直、話になりませんので。 ※多少、毒づいてしまって申し訳ございませんが EC-CUBE が更なる発展を遂げる事を心より楽しみに思っております。。。 |
|
ゲスト |
投稿日時: 2008/6/2 21:34
対応状況: −−−
|
Re: もっとパフォーマンスのよいEC-CUBE つ[analyze]
|
|
nanasess |
投稿日時: 2008/6/2 23:31
対応状況: −−−
|
神 登録日: 2006/9/9 居住地: 投稿: 2314 |
Re: もっとパフォーマンスのよいEC-CUBE 引用:
全データが 2,000,000件 あっても, 検索条件と INDEX 次第で1秒未満のレスポンスを実現することは可能でしょう. しかし, 現在の EC-CUBE では, テーブルを複雑に結合しています. さらに. 2.x 系では複数カテゴリ対応なので, さらに酷な検索条件となっています. 引用:
上記の条件で表示に使用される SQL を explain してみましたか? Pentium4, メモリ1GB という環境でしたら, 普通に考えて酷だと思います. しかし, product_id をキーにした, dtb_products のみの検索でしたら, たとえ数百万件登録しても, 一瞬で検索できるでしょう. 引用:
他力本願ではなく, 開発コミッターとして, 一緒に開発しませんか? 僕自身も, 現在のスキルでは, ご提示の要件を満たせる自信はありません... これからもっと勉強して, もっと高性能な EC-CUBE にしていきたいですし. |
ゲスト |
投稿日時: 2008/6/3 11:22
対応状況: −−−
|
Re: もっとパフォーマンスのよいEC-CUBE 返信ありがとうございます。
引用:
私の乏しい知識で考えた対策では、EC-CUBEでコレを実現させる、というものがありますが、DBの負荷もデータ量もかなり...。 他に何かいい方法がないかと思いつつ書込みさせていただいた次第です。 引用:
多忙の為、ついつい他力本願になってしまい申し訳ございません。 私は偉そうに言うだけ言っておいて、開発に関する知識は、コミュニティ参加者の皆様よりかなり乏しいです。 私も同様に勉強中ではありますが、お力添えするのはかなり難しいかと思われます。 また、何か進展がございましたら報告させていただきますのでよろしくお願いいたします。 |
|
tao |
投稿日時: 2008/6/4 0:06
対応状況: −−−
|
一人前 登録日: 2007/12/28 居住地: 東京 投稿: 82 |
Re: もっとパフォーマンスのよいEC-CUBE 横から失礼します。
パフォーマンスについてですが、MySQLの場合、JOINのキーになるindexを増やすだけだとダメなのでしょうか? また、現在のEC-CUBEはMySQLではviewを使わずにサブクエリを使用していますが、MySQL5系のviewはまだまだ使えないという事なのでしょうか? もし試されている様であれば教えて頂けると幸いです。 |
seasoft |
投稿日時: 2008/6/4 23:18
対応状況: −−−
|
神 登録日: 2008/6/4 居住地: 投稿: 7367 |
Re: もっとパフォーマンスのよいEC-CUBE なかなか、そこまでの規模のデータで検証したことは
無いでしょうから、貴重なデータとなりそうですね。 個人的にそこまで大規模な利用には興味は無いですが・・・ とりあえず、パフォーマンスが悪くなっている原因 (DB問い合わせ? PHP処理? etc...)を特定できたら良さげですね。 EC-CUBE がトレースログを吐けるのか分かりませんが、 可能ならばそういった辺りから。 無理なら、適時 <?php echo time(); ?> とか。
|
nanasess |
投稿日時: 2008/6/5 9:31
対応状況: −−−
|
神 登録日: 2006/9/9 居住地: 投稿: 2314 |
Re: もっとパフォーマンスのよいEC-CUBE 引用:
JOIN が複雑すぎて, あまり効果が無いと思います. 引用:
EC-CUBE の要件として, MySQL4.1.x での動作があげられていますので, MySQL で VIEW を採用するのは難しいと思われます. また, 知識不足で恐縮なのですが, MySQL では VIEW にするとパフォーマンスは向上するものなのでしょうか. # PostgreSQL や Oracle ではあまり変らないようです. |
tao |
投稿日時: 2008/6/5 10:29
対応状況: −−−
|
一人前 登録日: 2007/12/28 居住地: 東京 投稿: 82 |
Re: もっとパフォーマンスのよいEC-CUBE ご回答ありがとうございます。
PostGresの新しいバージョンも出たので色々試してみます。 |
seasoft |
投稿日時: 2008/6/8 10:39
対応状況: −−−
|
神 登録日: 2008/6/4 居住地: 投稿: 7367 |
Re: もっとパフォーマンスのよいEC-CUBE 引用:
なんら検証をしたわけではありませんが、少なくとも pgsql のテーブル定義を見る限り、インデックスで改善しそうなテーブル構造が多々あります。 MySQL に、複雑な JOIN でインデックスが適切に使われない癖があったりすと話は別ですが。
|
nanasess |
投稿日時: 2008/6/8 22:42
対応状況: −−−
|
神 登録日: 2006/9/9 居住地: 投稿: 2314 |
Re: もっとパフォーマンスのよいEC-CUBE 以前, いろいろ頑張ってみましたが, 現状のテーブル構成では諦めました...
例えば, 2.x の商品一覧では下記のような SQL が流れます. (MySQL のものですが, PostgreSQL でも VIEW を使用しているだけで概ね同様です)
改善可能な箇所がありましたら, ご教授下さい. 古いDBのバージョンも考慮しなくてはならないので, かなり大変です. 本体にフィードバックできそうでしたら, コミッターML などを通じて, 株式会社ロックオン様と交渉させて頂きます. |
フラット表示 | 前のトピック | 次のトピック |
題名 | 投稿者 |
---|