買い物、自重。なバイク乗りの日記

別に CGI を用意して作成中。
現在はこんな感じ。
→ 月別
→ カテゴリ別

カテゴリ別はサブカテゴリのみ分割。
メインカテゴリは出力できてない。
ページ分割リンクは一番下の中央に。

毎日変更しまくりｗｗｗｗｗｗｗｗ

今回は HTML の分割をしてみようとおもふ。
で、できればプラグイン化したいのだが、どこにどうプラグインとして突っ込めばいいのやら・・・。
サンプルは出来ているのでこういうことをやろうと。

http://griffonworks.net/sakura_mysql/archive/2005-05.php

いっちばん下に "1 | 2 | ALL" というリンクがあるのでそれを使用する。
中は php で書かれていて、一部抜粋するとこんな感じ。

<?php
  $mynum = "2005-05";
  $num = $_REQUEST{'page'};
?>

<?php
  include("top_bar.html");
?>
<div id="nikki-block">

<?php
  $max = 2;
  if ($num == 0) {
    for ($i = 1; $i <= $max; $i++) {
      include("${mynum}_$i.php");
    }
  }
  else if ($num < 1) { $num = 1; }
  else if ($num > $max) { $num = $max; }
  if ($num > 0) { include("${mynum}_$num.php"); }
?>

<?php
  for ($i = 1; $i <= $max; $i++) {
    if ($i == $num) { print "$i | "; }
    else { print "<a href=\"?page=$i\">$i</a> | "; }
  }
  if ($num == 0) { print "ALL"; }
  else { print "<a href=\"${mynum}.php?page=0\">ALL</a>"; }
  print "<br>\n";
?>

<?php
  include("bottom_bar.html");
?>

超強引ｗｗｗ

いや、オレ php わかんねーし・・・。
Perl と似てるっちゃー似ているが。

こんなんなりました。(・∀・)



アイコンは自分で描くのもだるいので Web で探しているのだが、設定とログアウトのアイコンでよさげなものが見つからない・・・。

---

&img:() 変換プラグインを更新。
今回は _NB オプションを増設。
&img_NB のように使うことで画像周りのボーダーラインを 0 にすることが可能で、_R や _L と共存可能。
共存させる場合は _L_NB のように使用する。

sakura.cgi?num=XXXX という型式で記事に飛べなくなったので、MT の php 化でよく採用されている

Redirect permanent で静的 HTML ファイルに飛ばす

という手法を使おうと少し実験。

.htaccess に

Redirect permanent /nikki/sakura.cgi?num=1 http://griffonworks.net/nikki/archive/1.php

と書いて実際に num=1 にアクセスしてみた。
普通だとこれでリダイレクトされるだろうと思っていたのだが、何故かリダイレクトされない。
そこで "?" が悪いのかと思って "&" に置き換えてみたらリダイレクトされた。
ならばと .htaccess の方を "\?" として sakura.cgi?num=1 にアクセスしてみたのだが、これでもやっぱりダメ。

どうやら "?" 以降の文字列は見ない仕様になっているのかはわからないが、とりあえず "?" が付いているとリダイレクトしてくれない。

それならばと強引な手法でリダイレクトしてみた。
というのも、sakura.cgi ロードの初期部分で条件分岐があるのだが、そこで

num=* もしくは date=* かつ、mode=null であれば Redirect permanent する

という perl スクリプトを挿入、HTML ヘッダで 302 permanent でリダイレクトさせるようにした。
とりあえずこれでトラックバックした分と日単位での表示は今の静的 HTML にリダイレクトさせられたが、他の分に関しては諦めるか。

ちなみにこのリダイレクトコードは、条件分岐用プラグイン (redirect.pl) に追加してあるので、使わないときはプラグインのファイル名を変更するだけで外せるというお手軽仕様。
submit_check のプラグインがここで使うとは思っても見なかったり。

静的 HTML 化やっと完了。orz
これでもう後には引けなくなった。

というのも、トラックバックすると記事に対して直接リンクが張られるわけだが、この URL が静的 HTML ドキュメントになる。
そうすると、.htaccess でリダイレクトするとか諦めるとかしなければならないのだが、このあたりが非常にﾏﾝﾄﾞｸｾので、一度静的 HTML 化をしてしまうと後には引けないというわけ。

とりあえず、大幅に負荷が下がったのでこれはこれでよしとしよう・・・。

多少 SQL の最適化をして軽量化。
と共に、以前から設定インターフェイスを作成しようと思っていたのでこんなものを作成。



無駄すぎ・・・。＿|￣|○

順調に進んでまふ。
月別、日別、カテゴリ・サブカテゴリ別、記事別の全てに対応できたので、あとは編集したときの適時構築の部分と連携させるだけ。
問題は今までに TB したところの番号をどうするか・・・だな。
それ以外の外部からのリンクはあきらめる。(ｗ

いやほんとまじで勘弁してくだつぁい(つд`)っつーほど頭が痛くなりますた・・・。orz
php で include 使ってサイドバーとヘッダ・フッタを結合すれば静的 HTML の生成負荷はかなり減るんだが、問題はサイドバーとヘッダ・フッタの扱い。
これらのテンプレ (一度きりテンプレ) と本文テンプレ (繰り返しテンプレ) の中には共通のテンプレ変数という物があるが、これをいったいどうやって変換させようかというもの。
今のところ、共通テンプレ変数は別エンジンでまとめて変換をかけているが・・・。

内容をまとめるためにあえて日記として残しておこう。

---

やっぱり難しいよﾏﾏﾝ。｡･ﾟ･(ノД`)･ﾟ･｡
HTML 構築部分を 1から仕様決め直したほうがいいかもしらん。

日付単位で抽出する際の SQL 発行回数の減少とコメント入力時の自動リターン。
自動リターンは一応変数クリアして戻ってるけど障害になる可能性も・・・ｗｗｗｗｗｗ

ちまちまちまちまと SQL の最適化と無駄なループを行わない地道な努力・・・疲れる。('A`;

さくら日記帳 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 くらいで帰ってきた。
どうやらデータベースの参照あたりで問題が山積みのようだ。＿|￣|○