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

さくら日記帳 for MySQL でリレーションを使ってみようかな〜とか考えていたわけだが、どこで使えばいいのかいまいちよくわからないというかリレーションすべきことでもないので今まで見送っていたが、会社で少し時間がとれたのでテストテーブル作って実験してみたところ、以外と簡単っつーか簡単すぎた・・・。orz

ちょいとテーブル構造を修正するか？

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

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

caladiumを久しぶりにメンテしていたんだが、なぜか UTF-8 な文字コードが変換できない。
なんでかなー？と思って調べてみたら jcode.pl って UTF-8 サポートしてないのね・・・。_no

という事で Jcode.pm つっこんで試してみたところ無事変換できた。

これから jcode 系使うときは Jcode.pm 使うか。

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

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

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

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

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


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

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

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

人柱版

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



マジで死ねた。＝□○＿



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

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

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

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

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

野暮用でこんなスクリプトを作らなければならないので作ったんだが、結果があまりにも酷かった。

#!/usr/bin/perl

$TEST{'STR'} = 'PC';
$TEST{'STR'}{'1'} = 'STR-1 values.';
$TEST{'VAL'} = 2;
$TEST{'VAL'}{'2'} = 'VAL-2 values.';
$TEST{'DAT'} = "テスト";
$TEST{'DAT'}{'3'} = 'DAT-3 values.';

td();

sub td {
        foreach $mk (keys %TEST) {
                print ">$mk\n";
                foreach $sk (keys %{$TEST{$mk}}) { print ">     $sk: $TEST{$mk}{$sk}\n"; }
        }
        return undef;
}

メインカテゴリとサブカテゴリを表示するというスクリプトなのだが、以下のような結果を期待していた。

>>>STR
>1: STR-1 values.
>>>VAL
>2: VAL-2 values.
>>>DAT
>3: DAT-3 values.

しかし結果はあまりにも無惨で以下のような結果となった。

>>>STR
>>>VAL
>2: VAL-2 values.
>>>DAT
>3: DAT-3 values.

連想配列名 "STR" のサブ連想配列が出てこないのだ。
これにはまいった。
何がまいったかというと、1バイト文字列では出てこないのに、2バイト文字列もしくは数列にすると "VAL" と "DAT" のように出てくるのだ。


これは使えない。('A`)


流石にユーザーに「カテゴリ名(表示用)はかならず 2バイト文字から始めてね」などと恥ずかしい指定は出来ない。
しかたがないので %CATEGORY と %SUBCATEGORY を作成して対応。

うーん、美しくない。

で、この影響なんだが、実は右テーブルのカテゴリリスト内にある「PC関連」に影響が出ていた。
なんと、サブカテゴリがいくつかあるのにそれが出てこず 1つのカテゴリにしかなっていなかった。(汗)

今までは普通に動いてたんだけどなぁ・・・。('A`)