質問 > 管理機能 > 商品情報の項目追加についての最適化 |
管理機能
スレッド表示 | 古いものから | 前のトピック | 次のトピック | 下へ |
投稿者 | スレッド |
---|---|
yuh |
投稿日時: 2017/4/19 0:52
対応状況: −−−
|
神 登録日: 2013/1/9 居住地: 大阪 投稿: 1819 |
Re: 商品情報の項目追加についての最適化 よっぽど変なPHPを書かない限りDBがボトルネックになります。
商品数によってですが、商品数がある程度増えた場合最初に重たくなるのが商品一覧で、 次におすすめ商品のブロックを設置しているページになります。 LC_Page_Products_List.phpの商品を検索している部分のクエリで COUNT(*)している部分と、実際に検索している部分の二つメインのクエリがありますが、 そのクエリをSQL_CALC_FOUND_ROWSでまとめて取ってしまう方法とか、 SC_ProductsのJOINしている部分を少し変更する方法があります。 SQL_CALC_FOUND_ROWSの方は少しめんどくさいので割愛。 SC_Productsの方は getListByProductIdsに渡された$arrProductIdをlistsに渡して、そのままalldtlSQLまで渡したうえで$objDBFactory->alldtlSQLに渡して その中で
このようになっている部分を$arrProductIdにデータがある場合のみ
このような形で絞り込んだ上でINNER JOIN する事で読み込みが速くなります。 もっと色々手を加えればもっと速くなりますよ。
|
mizuvan |
投稿日時: 2017/4/15 14:13
対応状況: −−−
|
長老 登録日: 2013/3/26 居住地: 投稿: 253 |
Re: 商品情報の項目追加についての最適化 ありがとうございます
SELECTで限定する手もあったのですね 勉強になりました!
|
mizuvan |
投稿日時: 2017/4/15 14:11
対応状況: 解決済
|
長老 登録日: 2013/3/26 居住地: 投稿: 253 |
Re: 商品情報の項目追加についての最適化 ありがとうございます。
商品情報としての項目がほとんどですので1つのテーブルの方が良さそうです。DB以外を探ってみます
|
umebius |
投稿日時: 2017/4/15 7:07
対応状況: −−−
|
神 登録日: 2016/7/22 居住地: 投稿: 2085 |
Re: 商品情報の項目追加についての最適化 どちらのケースも目にするので、何が正解というわけではありませんが。
商品数はどの程度か、100以上の項目はどういうタイプが多いのかなどにもよりますね。 一度に読み込む項目が多ければ多いほどメモリ消費が増えるのは間違いないです。 SELECTで読み込む列を限定するだけで劇的に表示速度が改善したなんていう例も見たことがあります。
|
468 |
投稿日時: 2017/4/14 22:44
対応状況: −−−
|
神 登録日: 2008/10/26 居住地: 投稿: 3217 |
Re: 商品情報の項目追加についての最適化 追加された項目が常に必要では無い場合は、テーブルを分けたほうが良いかと思いますが、
商品として情報を扱う時に必ず必要なのであれば1つのテーブルにしたほうが効率が良いのではないかと思います。 基本的にテーブルの結合が無いSQLのほうが速いと思います。 表示速度の場合、DB以外にボトルネックがある可能性もあると思います。
|
mizuvan |
投稿日時: 2017/4/14 17:26
対応状況: 解決済
|
長老 登録日: 2013/3/26 居住地: 投稿: 253 |
商品情報の項目追加についての最適化 商品情報に項目をどんどん追加して、結果100項目以上を追加する状態となってしまいました
そこでお聞きしたいのですが、dtb_products へ現在追加していますがこれらは、例えば dtb_products_2 、dtb_products_3 といった具合に分けたほうが読み込み速度などが向上して最適化されるものでしょうか? どうも最近、商品一覧の表示に時間がかかるような気がします。 どなたかアドバイスをいただけますと嬉しいです [EC-CUBE] 2.13.2 [レンタルサーバ] チカッパ [OS] Windows10 [PHP] 5.4.45 [データベース] MySQL 5.6.13 [WEBサーバ] Apache [ブラウザ] Chrome 56.0
|
スレッド表示 | 古いものから | 前のトピック | 次のトピック | トップ |