MySQLで動かしたことは無いですが、SQL文を見る限り遅いんだろなとは想像がつきます。という事は、改善できる余地は十分にありますね。

しかし、1000点なら大丈夫という動作実績を聞いて安心しました。
1000〜10000点の間に、現状の限界がありそうですね。

ちなみに現状では、商品数とともに、商品をどれだけ多くのカテゴリに所属させているかも大きく影響します。(なので、テスト商品生成スクリプトが生成するデータは、現実よりも負荷が大きい結果となると思います。)

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

書き忘れました。
１．４．６です。

２．１．２で、複数カテゴリなどをふんだんに使ったものだとたぶん、もうちょっときついのでは無いでしょうか？たぶん
ＳＱＬをざっと眺めてると、ずいぶん酷使してるっぽいので。

以前、当方の環境でテストしたのですがver2系をmysqlで利用した場合、商品数500からいっきにパフォーマンスが落ちました。その後、postgreに変更し500商品ごと追加しました。postgreの場合は500〜1000商品だと問題なかったと思います。（規格は登録していない状態）ただし、3000商品だと以前書き込んだような状態になります。

なんとか改善していきたいです。

１．４．６
２．１．２
ＳＱＬ

2byte文字を用いているのも
妙に引っ掛かル。

そういえば、本日からゲスト書き込みできなくなるんでしたね。
ID登録すると、書き忘れたことも後から付けたし出来て便利ですよ。

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

よく知られたネット販売の式

　　売上＝商品数×顧客数×購買率

1.売上を上げるためにはより多くの商品を出品する
2.SEOや広告でより多くの顧客を呼び込む
3.見た目や説明の充実でコンバージョンを上げる

楽天　5000〜25000点　契約により変わります。
YAHOO STORE 無制限
YAHOO AUCTION 1ID 3000点

楽天もヤフーもビッターズも一番に言うことは
売上を上げるには出品商品数を多くすること！
と必ず申しておられます。

商品数を制限されたツール(EC-CUBE)を使用することは
『売上を上げない』と決めたことになります。

YAHOO STOREに特化するのがいちばんいいかも。
コンサルも無償だし。
株式会社ロックオンさんはQAの場の提供だけだし。
パートナーさんは当然有償だし。
レコメンダーも5万円/月だし。
（YAHOOはレコメンデーション機能はついてません。）

携帯サイト自動生成につられて
期待が大きすぎました。

もうすこし調べてみます。

引用：
そりゃ言うでしょう。
向こうさんも商売ですから。

引用：
それは違うと思います。

hoge 様ほどに多くの商品数を掲載しようと考える方の方が少ないので、多くの商品数を掲載するよりも、別のことにリソースを当てているのだと思います。
(そういう面では、多売の販売業者よりは、生産者直売などに向いているソフトなのでしょう。)

ちなみに、多くの商品数を掲載することに特化させる改良は、そんなに困難ではないと思います。私が、多くの商品数を掲載することに興味があるなら、速攻取り掛かりますが… 興味ないなぁ… DBのパフォーマンスといった技術的視点では興味ありますが、ビジネスとしての興味はそこに無いです。

現状では一般論として、カスタマイズが不要な場合、ASPを使う方が良いのでしょうね。

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

おっしゃる通り

蟹とか
うにいくらとか
shopjapanの商品とか

少量商品をう〜〜〜んと引っ張って
縦長にitempageを作成するには
すごくEC-CUBEは向いていると思います。

入力できる項目数がやたら多くありましたから。

web担当者ではなく
カメラマンや
デザイナーが
中心のサイト構成ですね。

売上を上げるには出品商品数を多くすること！
と必ず申しておられます。
彼らはマーチャントのロイヤリティを上げることも
重要なミッションの一つですが
ページの質の向上を重視した人は極端に少ないです。

　売上＝商品数×顧客数×購買率　で学んでいるのでしょう。

YAHOO AUCTIONは3000と限られているので
まず3000まで出しましょう。
次にかにのように縦長のなが〜〜いページ作成を言ってきます。

ま、取り扱う商材によって違ってきますね。
日々学習学習･･･。

ローカル環境ですが、1500点ほどダミーデータ入れてみたのですが、やはりパフォーマンスが落ちることが確認できました。
1100、1200とか段階的に入れてみたわけでは無いので、どこらへんで極端に落ちるのかわからなかったです。

一応、やってみた結果でした。

さすがに公開しているサーバでやるわけにはいかなかったので、実際はどうなるかはわかりませんけど。

引用：

上記と, 一般ユーザーが使用する EC-CUBE の運用環境は大きく異なります.

楽天や, Yahoo! のインフラ環境と, EC-CUBE を設置したレンタルサーバーのインフラ環境を比較するのは筋違いです.

レンタルサーバーなんてケチなことはせずに, 高速なハードウェアを使用して比較して下さい.

経験則ですが, ボトルネックのほとんどは, I/O だったりするので, SAS などの高速なディスクを使用することで大幅にパフォーマンスが向上します.

PostgreSQL でしたら, 8.3 になって大幅にパフォーマンスアップしたので, こちらも試してみると良いと思います.