バイクを降りたドール者の日記

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 の出力をやめようかと。

1.5 sec. の壁をようやく突破。
といっても 1.47 sec. だが。(藁

今までは COUNT(フィールド名) のデータ保持の仕方がわからず SQL をカテゴリの数だけループさせていたのだが、今日、そのデータ保持の仕方がわかったので 1発取得のコードに変更してみた。
結果、1.55 sec. → 1.47 sec. とびみょーに早くなった。

サンプル：

#!/usr/local/bin/perl5.8.6
use DBI;
my $query_strings = "SELECT category_en,COUNT(category_en) FROM diary GROUP BY category_en";
$mysql_db = DBI->connect("DBI:mysql:DBNAME:localhost", USERNAME, PASSWORD);
$mysql_sth = $mysql_db->prepare("$query_strings");
my $ret = $mysql_sth->execute;
my @MAIN_CAT_DATA;
while (my $TMP_HASH = $mysql_sth->fetchrow_hashref) {
     printf("%-15s %5d\n", $TMP_HASH->{'category_en'}, $TMP_HASH->{'COUNT(category_en)'});
     push(@MAIN_CAT_DATA, "$TMP_HASH->{'category_en'}:$TMP_HASH->{'COUNT(category_en)'}");
}
$mysql_sth->finish;
$mysql_db->disconnect;

ただ単に $TMP_HASH->{'COUNT(category_en)'} とすればいいだけだったなんて・・・。
この部分は SELECT の後ろで指定するフィールド名がそのまま使われるようで、例えば "count(category_en)" と小文字にしたら、ブレス括弧内の文字列も "count(category_en)" と小文字にしなければならない。

だが、常時 1.50 sec. の壁を破っているわけではないのでまだ不満。
そこでどの部分が一番時間を食っているかを調べてみた結果、

0.167482 sec.
　　SELECT category_en,subcategory_en,COUNT(category_en)
　　　　FROM diary GROUP BY category_en,subcategory_en
0.164456 sec.
　　SELECT category_en,COUNT(category_en)
　　　　FROM diary GROUP BY category_en
0.145685 sec.
　　SELECT * FROM diary

"SELECT * FROM diary" より遅くなるのは GROUP BY と COUNT で集計してるからか・・・。＿|￣|○
とりあえずこれ以上はどうがんばっても早くなる可能性は無い模様。

山銀さんとこの namelist.txt の調子不良が治ってよかったというか。
これらの出来事を見て思った。

次からはなりふりかまわず EUC で行く。

普通なら華麗にスルー出来るところが SJIS のおかげさまでバグを誘引するようなコードを書かなければならないこの苦労。
そんな苦労が嫌だったのでさくら for MySQL は全て EUC で記述。
すると、なんと楽にコーディングできるのでしょう。
おかげさまで気を遣わずにコーディングできるすばらしさ。

まぁこのあたりは「最初もしくは最終段階で文字コードを変換」という方法で切り抜けられるわけですが、やはり文字コードを統一した方が楽っちゃー楽。

ただ、最近は EUC を扱えるエディタも出てきているのでこの辺りは問題ないかと思ってますが。

久しぶりにアップデート。

• 月別表示した時、一番最後の日の記事が前日の記事と一緒になってしまうバグを修正。
  
• 月別表示した時、表示している月のカレンダーを表示するよう修正。
  今までは「現在の月」を表示していた。
  

表示速度は 1.5sec まで短縮できたが、プラグインを使っている限りこの壁は越えられそうにない。
プラグインディレクトリを無くしてみたら 0.7sec ってどういうことよ・・・。＿|￣|○

ちょいとさくら日記帳の「表示完了速度」つーのを調べているわけだが、これがどうにもこうにもわけがわからない。

Firefox の拡張機能である "lori" を使用すると、ページの表示が完了するまでの速度を計測できるのだが、sakura.cgi を静的生成したものを呼び出すと 0.5s くらいで表示が完了するのだが、動的生成したものを呼び出すと 3.5sec くらいかかる。
内部処理は 0.7sec くらいで終わっているようなのだが、どうやらその後が問題のようで。

Content-Length を出していないのが原因か？

---

Content-Length を出してみたが解決せず。
試しにスクリプトそのものの処理時間を計ってみた。

% /usr/bin/time ./sakura.cgi > /dev/null
　　　　　　　2.26 real　　　0.80 user　　　0.28 sys

・・・・・・。

---

もしかしてプラグインがオーバーヘッドになっているのだろうかと思って計測。

~/public_html/nikki> mv plugin plugin_
~/public_html/nikki> /usr/bin/time ./sakura.cgi > /dev/null
　　　　　　　0.64 real　　　　0.37 user　　　　0.08 sys
~/public_html/nikki> mv plugin_ plugin
~/public_html/nikki> /usr/bin/time ./sakura.cgi > /dev/null
　　　　　　　2.24 real　　　　0.87 user　　　　0.20 sys

・・・・・・・・・・・・。(´д｀;;;

更に追記で、プラグインを有効にし、かつ日記表示数を 1にしたところ速度に変わりは無かったが、プラグインを無効にして、かつ日記表示数を 1にしたところ、0.6sec くらいで帰ってきた。
どうやらデータベースの参照あたりで問題が山積みのようだ。＿|￣|○

数日前の日記を追記したり修正したりする事が多くなったので、プラグインで「最新の日記」テーブルを作成。
左バー内に仕込んであります。

どうやらエラーが出ているようなので原因調査開始。
スペース？

---

原因判明。
< と > を特殊文字にしておりませんでした。(ぉ
ちなみに description でのスペース使用可否は「使ってもいい」はずです。(汗)

っつーのがメールで飛んで来ていてかなりビビッた。('A`;
誤報かと思ったらトラックバック受けてるし。

正常動作ｲｲ(・∀・)!!

まだ SPAM コメント食らったこと有りませんが先回りという事で。

メール系の公開ブラックリストデータベース (BLDB) の事を調べていると、このデータベース、実は IP アドレスのオクテットを逆さまにして BLDB のチェック用ドメイン名を付加したものを正引きしている仕組みという事。
実に簡単な仕組みなので「これは何かに使えるかも！？(ﾟ∀ﾟ)」と思っていた矢先、DSBL でググって見ると、やたらと "MT-DSBL" というのがひっかかる。
で、これってなんだろう？と思って調べてみると、どうやら今流行の MovableType 用のアンチ SPAM トラックバック用プラグインらしい。

そこでひらめいた。

DNS で正引きチェックによるチェックなら Net::DNS 入れちまえば対応できるのでは？

という事で早速作ってみたプラグイン "reject_blh.pl (Reject BlackListHost)"。
機能は以下の通り。

• ローカルブラックリスト対応。
  IP アドレスはホスト単位とネットワークアドレスの両方をサポート。
  ホスト名は後方一致もしくは完全一致をサポート。
  ホスト名のみ正規表現対応。
  
• 今のところ DSBL のみ参照しているが、ユーザーの任意で他の公開ブラックリストデータベースを登録可能。
  
• ローカルホワイトリストは現在未対応。
  そのうち対応しないとだめかも。
  

正直、こいつが有効に働くことはないと思う。_no

自己満足ｲｲ(・∀・)!!

さくら混沌版更新しますた。

一応必要なファイル及びインストーラー (sh シェル) を固めておいたので、人柱になれる方のみご利用下さい。
テンプレートも基本テンプレートとなる sakura.template 及びカレンダーを縦型にしたテンプレートの 2種類を入れています。

機能強化はここで止めておいて、先に調整に入ります。
まだまだ中途半端に放置プレイしてるところがいくつも。(ぉ

ちなみにドキュメントはありません。

設置が死ぬほどﾏﾝﾄﾞｸｾ('A`)


このまま葬り去ろうかな。
ｲﾔﾏｼﾞﾃﾞ。
マトモに動かす方が大変。

とりあえず圧縮はしておいた。
マニュアルなんざ特殊タグの簡単な説明しか有りません。
テンプレート参考にして自分らしくテンプレ作ってくれとしか今はいえないレベルです。
質問は受け付けるけど答えられるかは不明。

• namelist.txtは正規表現をサポート出来なくなりました。
  正規表現で書いてる人は元に戻してください。
  
• ログファイルはそのまま使えます。
  log ディレクトリにそのままコピーでおｋ。
  
• sakura.ini は一応そのまま使えます。
  
• スクリプト系は全て変更されているので流用不可。
  

人柱版

というわけで、こっちで話している修正を施したのと、さくら日記帳混沌版で採用した完全テンプレート化を実施。



マジで死ねた。＝□○＿



高機能化しているのでテンプレに必要な独自タグの数が多くなり、正規表現で置換する部分がかなり多い。
その量、恐らくさくら日記帳混沌版の約 2倍。
ファイルサイズにすると約 3倍か。

いや、マジ死ねるから。('A`)
つか　テンプレ書くヤツも死ねる。('A`;

まぁ作ってしまえばあとは放置プレイでおｋうぇｗｗｗｗなので別にかまわんのだが・・・。

絶対バグありそうだよなぁ・・・。

ちなみにココまで重装備にしても内部処理的には 0.3秒くらい。
問題は表示が遅いことだけ。
ここらへんはぼちぼち考えるか。

さくら日記帳 V3 (混沌期) のやっつけ仕事テンプレを採用した例を展示中。
Azoしゃんは喉から手が出るほど欲しい仕様かもしれない。



まだ出せる段階
じゃないですから！！
残念！！！！


死んでもイイならダスト行ってみるテスツ。
「間違いなく死ぬ」に「おか泉」のざるうどん 1人前。

表示周りはまだ微妙に採用していない機能があるけど書き込みと修正の部分はほとんど弄ってないから普通に書けるはず。



とおもったら、MySQL 版でさっさとやりたいけどかなりﾏﾝﾄﾞｸｾ('A`)なカレンダー縦置きのテンプレートが先にこいつで実装してしもたよ・・・。＿|￣|○
しかもなにげに全部テンプレート化完了してるし。

MySQL 版を一部追い抜いてますから！切腹！！！！！！

窓から投げ捨ててイイッスか？





HTLM 構築部分がクソ過ぎて自分に対して腹が立つわ・・・。






1から新造しようかしら。



その(・∀・)後。








やっとひな形出来た。_no
もうやだこのスクリプト酷すぎ修正されるねうぇ。

さらにその(・∀・)後。

さくら日記帳の V3 爆弾バージョンがとりあえず表面上は修正完了。
記事全体をテンプレート化する事で、スクリプトのバージョンアップが行われても見た目の修正は一切行わずに済むというのは見た目を変更している人達には朗報かもしれないが、逆に初期導入時に基本テンプレートを修正しなければならないので結構手間がかかる。
まぁこのあたりは諦めてもらうほかあるまい。
この関係で ini ファイルに保存している設定のほとんどが消えることになると思う。

あまりにも修正個所が多いので、メジャーバージョン番号を 1つインクリメントすることにします。(ぉ

内部がいい具合にカオスしてます。(ﾌﾟｹﾞﾗ

ちょっとだけメモ。

• 本文部分をテンプレに統一
  
• 記事修正や投稿は初期ログインが必要だが、その後はログアウトするまで状態保持
  
• スクリプトやログ全てを SJIS に統一。
  ※正直、なぜ SJIS で作り始めたのかがわからない・・・。