最近、サイトがやたらめったら重いと思い。
benchmarkを入れて確認してみた。
SQLクエリ数を確認してみると、とんでもないことになってた。
なんと900クエリを超えているではないか。
sqlクエリってなー100前後(100qで表示に1秒くらい)にとどめるのが普通なのではないかいな。
ちなみに別なNucleusシステムで動いてるサイトは60クエリくらいしかない。
実に15倍である。これはまずい、重いはずだ。
しかしいくらプラグインを大量に追加したからといって。
900クエリなんて数字はなかなか出ない 。9秒かかるじゃん。
なにか重大なミスを犯しているはずだ、設定したのが俺なだけに。
SQLクエリをトラッキングする方法 を試してみた。
これでどいつが犯人なのかある程度特定できる。
ログを確認してみるとcustomURLからのクエリがダントツで多い。
再設定が必要なようだ。
色々いじって767q(クエリ)まで落としたが、よくわからないタイミングで468qまで落ちる時がある。
同じページを出力して300qの誤差なんてあるものなのか?
ここに重要なヒントが隠されていそうだ
11/25追記:
よくわからないタイミングではなかった、よくわかるタイミングで300q減る。
「続きを読む」で詳細表示すると300q減る。
TOPページと詳細ページ、両者の違い。
currentサイト(skinはCURRENT)
TOP(templateは/short)は770q、
詳細(templateは/full)は470q程度
メンバ毎サイト(skinはWHITEorBLACK)
TOP(templateは/shortl)は770q、
詳細(templateは/full)は470q程度
ということはskinの違いは関係ないだろう。
これはテンプレートの違いによるものだろうか?
問題があるのはshortの方か。
続きへのリンクに書かれた下記の変数を消してみる。
<%categorylink%><%CustomURL(path)%>
と、774qから693qまで減った、やはりcustomURL関係なのか。
11/27追記:
ほとんどの原因がcustomURLにあることが判明したが、今更そのプラグインを撤去することはできない。
なにせこのプラグインを入れる為に、Nucleusコアファイル(心臓部)までいじってしまったのだから。
元に戻す為にはそれに使った時間と同じだけの時間を必要とする。
そして元に戻ったサイトは今よりも不便になる、それほどまでにcustomURLは有用だ。
自分のリソースは後ろ向きより前向きに使うべきだろう。
要は「クエリが増大してもそれと関係なくサイトが軽ければ良い」
わけだから、その結果を得る為に他の手を打てばよかろう。
それを実現する為のキーワード
「PEAR PECL memcached + memcache」
「PHPaccelerator Zend Platform ?APC XCache eAccelerator」
これらを設定してみよう。
そんな感じ。
This entry was posted in "NucleusCMS" and tagged "NP_CustomURL0.3.7", "Nucleus3.41" and "SQLクエリの増大" by Dalzy. Bookmark the permalink.