category.pl で時間を食っていたのはわかっていた。
そこで、連日流石に 2sec を越える時間をかけて日記を表示させるのもしゃくなので、どうすれば時間短縮できるかを考えてみた。
結果、
SELECT category_en,COUNT(category_en) FROM diary GROUP BY category_en
→ 0.1633 sec.
SELECT category_en FROM diary GROUP BY category_en
→ 0.0780 sec.
SELECT category_en FROM diary
→ 0.0018 sec.
という驚くべき(?)結果に。('A`;
そこで、COUNT と GROUP BY を使わなければ早いのでは?ということで、早速 "SELECT category_en FROM diary" を while でループさせてみた。
while (my $TMP_HASH = $mysql_sth->fetchrow_hashref) {
$CATEGORY_COUNT{$TMP_HASH->{category_en}}{$TMP_HASH->{subcategory_en}}++;
}
→ 0.14367 sec.
0.02 sec. だけ早くなったが、こうすることで今まで主カテゴリと副カテゴリの 2回クエリを実行していたのが 1回で済んだので、0.16 x2 sec. が 1/2 になったので無問題。
ただ、どうやっても 1sec. は切れないので、これはもう鯖のマシンパワー依存かと思っているが、はたしてそうなのかどうかは不明。
cles::blogのチューニングというところで "query_cache_size を使う" というのがあったので調べてみたところ、おなじく 0 になっていた。('A`;
ということでこれを 20M にして実験してみたところ、最短で 1.0 sec. 近くまで短縮することに成功。(゚∀゚)アヒャ
しかし、バッファ関係の値を弄るとなぜかパフォーマンスが落ちるという現象に遭遇しているので、今のところは query_cache_size 以外の設定を触る必要はなさそうだ。
これにあわせて while でループさせていた修正箇所を元に戻した。
主・副カテゴリの 2回ループのうち、主カテゴリの COUNT クエリを実行しなくても主カテゴリの件数を取得できるようになったので、そのループを除去。
で、現在は
SELECT category_en,subcategory_en,COUNT(category_en) FROM diary GROUP BY category_en,subcategory_en
→ 0.00063 sec.
となりキャッシュ効きまくり。
表示時間も 1.2 sec. くらいと早くなったので静的 index.html の出力をやめようかと。
└ G兄
└ G兄
└ G兄
└ G兄
└ G兄
└ G兄
└ G兄
└ G兄
└ 山銀
└ G兄