nDiki : www.naney.org

DiKicker に grep 検索機能を追加

DiKicker には自動リンクベースの記事串刺し表示機能があって、同じキーワードを含む記事をまとめて読むことができる。 結構便利なのだが、この機能ではキーワードの設定は Blog の書き手に委ねられている。

社内で DiKicker を一部使ってもらっているのだけれども、それら他人の Blog を読んでいると「あのキーワードで串刺し表示したいな」と思うことがしばしばあることに気がついた。 やはり任意の文字列で串刺し表示する機能が欲しい。

書き手にとっても「自動リンクキーワードにするような文字列ではないけれども、串刺しで読みたい/探したい/見せたい」と思うことが少なからずある。

ということで、検索ベースの串刺し表示機能を実装してみた。

grep ベース

実現には全文検索を行う必要があるが「設置・運用の手間」「ディスク容量」という点から、事前にインデックスを生成するような方法は今回は避けようと思う (www.naney.org 上で自分が使う上での制約からくる理由が一番大きかったりする)。

ということで今回は grep 型で実装することにした。 もともと WiKicker の方の検索機能も現在のところ grep 型である。 WiKicker では自前で WikiPage をスキャンしているが、DiKicker では grep コマンドに任せることにした。 こういうのは専用の grep を使った方が速いはず。呼び出しは

 grep -Flre $escaped_string dir...

というオプション指定。Web ページとしてのページングなどは、自動リンクによる串刺し表示機能のものを流用。

で試したところ www.naney.org サーバでは、load averages が 1 以下の時でだいたい50秒前後。対象ファイル数は 2800弱。予想より時間がかかる。

ただし1回実行した後、ファイルがファイルシステム/OSのメモリ上にのっている状態では 0.1秒程度で完了する。

検索結果ページの permalink が検索エンジンにそれなりに捕捉されて、定期的にアクセスがあるようになれば、ファイルがメモリにのっている割合が増えるであろうから平均して実用に耐えられる速度が出るかもしれない。

今後は様子をみながら検索結果のキャッシュ等を処理を整備していく予定。

自動リンク機能改善による悪影響

www.naney.org がどうもまた最近重い。

load average が 30 前後まで上がっている。 しばらくするとだんだん落ちついてくるのだが、3 以下になったところでまた 30 前後までまた一気に上がるというのを繰り返している。 load average で振る舞いを変えるのは WiKicker / DiKicker の特徴なので、これはうちが原因かも。

調べてみると SpeedyCGI のフロントエンドのプロセスが順番待ちで大量に起動している。

どうやら先日追加した自動リンクの機能改善にかかわるコード修正による、若干の処理速度の低下がまずいようだ。

速度が上がるようにちょっと修正してみたけれどまだ駄目なようなので、しかたなく単語の連接チェック部分を一時コメントアウトして対応。

今後、自動リンクまわりの更なる高速化がする必要がありそう。

MSNBot が激しすぎるので deny

ここ数日の www.naney.org サーバ高負荷について様子を見ていたところ、DiKicker の処理がリクエストに追いつかなくなる時には MSNBot が激しくアクセスしてきているようである。

MSNBot のページには robots.txt の Crawl-delay を見ると書いてあるので、以前

 User-agent: msnbot
 Crawl-delay: 20

としておいたのだがどうもこれは効いていないらしい。

ちょっとこの連続リクエストはしんどいし、msn からのアクセスは現状全体の 2.5% 程度なのでしばらく弾くことにする。

[ DiKicker ] ロック獲得リトライをさらに減らす

相変わらずここ最近 www.naney.org の負荷が上がり気味。 今日は Referer spam の爆撃もきていた様子。

DiKicker の挙動やログを見ていて気がついたのだが、さばききれなくなるのはどうも記事更新チェックの時間が長いからのようだ。 排他ロック獲得ループの回数が今の設定でも長い。

どのみち負荷が高い場合は共有ロックの方が勝ち気味で、排他ロックできなくて終わることが多いはずなので、思いきってもっとリトライの回数を減らしておいた。

それとロック獲得ループの中で「結局ロックできなかった時」に余計に1回 sleep() していたのでこれを削除。

サーバの負荷が高くなったら DiKicker が 503 を返して沈静化を待つようにした

www.naney.org を収容しているサーバの負荷が高い状態。

1. Referer spam 弾きを強化。
2. 1日半前ぐらいに1度リブートしたようで、Memcached が起動していなかったので起動。

という対処をしたけれどそれでもなかなか負荷が落ちつかない。

傾向としては SpeedyCGI のバックエンド側(speedy_backend)が MaxBackends まで起動して処理が追いつかないと、起動しているフロントエンド側 (speedy) がどんどん増えてしまうという状況のようだ。

DiKicker の高速化も順次着手しているのだけれど追いつきそうにもないので、loave average が高い時は頑張らずに無条件に 503 を返すように修正して対応(以前ハイパー日記システムの時にも同じことをした)。

本当は SpeedyCGI フロントエンドの数に応じて負荷の軽い処理に切り換える等工夫したいんだけれど、フロントエンドの数を取得する方法は簡単にはなさそうなんだよなあ。

Google Analytics のデータからよく検索されるキーワードを表示するようにした

Google Analytics から1日1回キーワードのレポートを TSV 形式でメールで配信するように設定している。 このデータをもとに「よく検索されるキーワード」を抽出して、nDiki の下の方に表示するようにした。

処理の流れ

1. メールで配信された TSV 形式データをファイルに保存する。
2. 検索質問とセッション数の組のデータを抽出する。
3. 1ワード単位でセッション数を集計する。
4. 上位のワードについて、nDiki のキーワードリストにあるか照合する。
   1. 完全一致するものがあれば、それを参照キーワードとする。
   2. 大文字小文字一致するものがあれば、それを参照キーワードとする。
   3. ワードを含むキーワードがあれば、その中で文字数の差が少ないものを参照キーワードとする。
   4. ワードで記事を grep 検索してマッチするものがあれば、それを(nDiki 内で検索して見つかる)キーワードとする。
   5. でなければ関連キーワード無しのワードとする。
5. 各ワードについて、対応するリンクを設定してフッタ埋め込み用の HTML フラグメントを生成しファイルを生成する。
6. ファイルをサーバにアップロードし、サーバ側でフッタにインクルードする。

1日1回の作業なので、メールからスクリプトにかける部分とアップロードする部分は手動で。

そこそこの処理なので、そこそこの精度なのだけれど傾向は何となくわかる感じだ。

実際にはアクセスログの対象となっているのは nDiki 以外の www.naney.org 内のアクセスも含まれているけれどもまあいいであろう。

キーワードの処理

キーワードの処理は細かいことをいうと結構面倒だったりする。

• 複合語の処理: 検索ワード側も、nDiki キーワード側も複合語を含むので空白で区切られた語の扱いが大変。特に検索ワード側は語順が正しいとは限らないし、各語が個別の語を表しているのか否かの判断が難しい。
• 曖昧一致処理: 検索ワード(や nDiki キーワード)が正確な語とは限らないので、曖昧一致させる必要がある。検索エンジン側で曖昧一致させて検索結果に上がっている可能性があるのでその辺りも考慮する必要がある。

などなど。

この辺りは精度を上げようとするといろいろ工夫の余地がって楽しそうではあるな。

フィード向け AdSense を追加してみた

Google AdSenseで「フィード向け AdSense」が利用可能になったので、nDiki に追加してみた。

Google AdSenseにログインして nDiki の URL を指定してフィードを登録すると、FeedBurner 上にフィードが作成される。

www.naney.org 側では nDiki のフィードへのアクセスがきたら、FeedBurner 上のフィードへリダイレクトするように設定する。 ただし FeedBurner から巡回がきた際にはリダイレクトせずに、nDiki のオリジナルフィードにアクセスさせる。

www.naney.org のトップディレクトリの .htaccess に以下を追加。

 RewriteEngine on
 RewriteCond %{HTTP_USER_AGENT} !FeedBurner
 RewriteRule ^diki/d/rss\.rdf$ http://feedproxy.google.com/nDiki [L,R]

思ったよりあっけなく設定終了。

今のフィード URL が既にフィードリーダーに登録してもらっていることを考えて nDiki (DiKicker) に「FeedBurner 向けに別 URL でのフィード出力機能」と「現在のフィード URL からのリダイレクト機能」を追加する必要があるなと思っていたのが、mod_rewrite が使えれば手間無しだった。

nDiki のフィードと同様の内容に広告が挿入されたバージョンのフィードが http://feedproxy.google.com/nDiki で表示されることを確認。

せっかくなので FeedBurner のレポート機能もチェックしてみることにしよう。

ホスティングサービスがメンテナンスからトラブルに

昨日の 18:00 から今朝の 6:00 まで、www.naney.org のホスティングサーバがメンテナンス作業で停止したのだが、その後もメールサーバは復旧せず。 ストレージのハードウェア障害が発生したらしい。

連続運用しているサーバって止めると立ち上がらなくなるってありがちだからなあ。

とはいえ12時間のメンテナンスだけでもかなり長いというのに、その後のトラブルで1日以上メールが止まるってホスティングサービスとしてはちょっとお粗末だよ。 ガンバレ。

さくらのレンタルサーバ プレミアム申し込んだ

www.naney.org で使っているホスティングサービスは

• SSH が使える。
• daemon プログラムを起動しておいても怒られない。
• cron が使える。

という点でいろいろ遊べるのだが、

• 今の相場的にはかなり高めなのにホームが容量 100MB (メールは別に 100MB)。
• Perl が10年以上前の Perl 5.005_03。自分で新しい Perl を入れようにも容量 100MB だと厳しい。5.005_03 だと Perl 5.6 系以降の文法が使えないし、使える Perl モジュールも限定されているので悲しい。
• 夜中になると analog が動いてサーバが重くなる。
• メールの送受信が遅延することがある。

などから使いづらくなってきた。 なにより容量を気にして記事を書き控えようという心理が働くのがよろしくない。 そろそろ今後を考えて他社に乗り換えようかと。

選んだのはやはり人気があって SSH も使える「さくらのレンタルサーバ」。

選んだプランは容量 10GB のプレミアム。 スタンダードでも容量 3GB でまずまずだし cron も使えるから機能的にも十分なんだけれど、1ホストあたりの収容ユーザ数により余裕があるであろう1つ上のプランにしておいた。

Web から申し込んで、風呂に入っている間に DNS 設定が反映されて SSH ログインできるように。 順次ソフトウェアのインストール・コンテンツの移行とメールの設定をしてから、naney.org をこちらに切り替える予定。

ドメイン移転について問い合わせた

そろそろ www.naney.org をさくらのレンタルサーバ プレミアムの方へ移さなければ。 その前にドメイン移管をする必要あり。

ありがちであるが退会手続きについてはほとんど説明がされていないので、昨日の夜にお願いのメールを出しておいた。

1. Whois 情報の Registrant Email、Admin Email を(現在ホスティングサービス会社の担当宛から)自分のメールアドレス宛に変更して欲しい。
2. AuthCode を教えて欲しい。

以前サポートメールアドレスにメールを出したがすっぽかされたことがあったので、午前中返信がないことを確認し、電話にて問い合わせ。

以下電話返答およびメール回答。

• メールアドレスはすぐに変更する(変更された)。
• AuthCode は退会通知後に教えてくれるとのこと。
• 退会手続き後月末まではサーバ利用可能。

25日が月末ということなので、ドメイン移管にかかる期間と Web サイトの移行(特にスクリプト関連)の作業を考えると今月中はちょっと厳しいかな。

ノート PC の乗り換えも同時にしなければならないし。

来月末退会で進めることにしよう。