tDiary

むとうです。

長らく放置してしまっていましたが、counter.rbを
大幅に書き換えました。CVSに上げておきましたので
良かったら使ってみてください。
なにか不振な点がありましたらご連絡を。

以下、細かな内容です。長文です。

・安定性の向上
　今まで、counter.datという一つのファイルに
　アクセス元のIPアドレス・ユーザエージェントと最後に
　アクセスしてきた時間を一定期間保持するようにしていました。
　また、このファイルは１日に１回、バックアップファイルを
　作るようにもなっていまして、アクセス量の多いサイトだと
　データ量が多くなってしまっていました。
　さらに、データが増えれば増えるほどcounter.datが壊れる
　という事象が多く見られるようでした。

　そこで、今回はこの点を見直し、
　・カウンタのデータ - counter2.dat
 　　テキストで、日付と現在の数値のみを保存
　・アクセス数のデータ - counter2_access.dat　
  の２つのデータファイルに分けました。

　counter2.datは多くても100バイト程度のデータですので
　（私のサイトで80バイト程度）バックアップをするにしても
　かなりの容量削減になりました。

　counter2_access.datは基本的には今までと同じなのですが
　保持するデータをアクセス元のIPアドレス・ユーザエージェント
　の文字列（の配列）から文字列のhash値にすることで大幅な
　容量削減（と高速化）を行うことができました。
　＃１件当たり1/5程度

　ただ、結局、短期間のアクセス数が多ければ多くなるほどデータ
　が増えてしまうのはこれまでと同じなので、保持する最大数を
　指定することができるようにしました。
　＃誤解を避けるために述べますが、このデータはもともと
　＃一定期間が過ぎるとデータを削除するようになっていますので
　＃よほどのことがない限りこのオプションを使うことはないので
　＃はないかと考えています。

　あと、counter2_access.datはバックアップを取りません。
　ファイルが壊れた場合、一から生成します（以前はバックアップ
　データから復元しました）。
　その場合、クッキーを持たないユーザからのアクセスは１から
　数えてしまいますが、それほど影響は無いだろうと判断しました。
　これに加え、counter2.dat自体は元々小さいので、以前に
　比べてカウンタデータが壊れてしまうということは減ったと思います。

・カウントしないユーザエージェントとして、デフォルトでボット系
　を多く登録しました。
　今まではユーザ任せだったのですが、現状わかる範囲でボット系を
　カウントしないようにしました。
　これも、負荷削減・安定性の向上に役立つはずです。
　ただ、私のサイトで日々のカウント数（特にアップデートしなかった
　日の場合）が1/5程度になってしまいました。ちょっとがっかり
　するかもしれません（苦笑）。

・設定画面
　設定画面から全ての設定ができるようになりました。

・キリ番プラグイン(kiriban)　
　counter.rbをインストールすると、合わせてkiribanという
　プラグインが使えるようになります。
　今までは、自分でRubyのコードを書いてキリ番かどうかの処理を
　ヘッダ当たりに入れて頂いていましたが、今回は、<%= kiriban %>
  と記述するだけで、設定画面で設定したメッセージを表示するように
　なりました。

・1.x系からの移行
　基本的にはcounter.rbを入れ替えるだけです(英語版はen/counter.rbも)。
　counterのデータについては、最初だけ、counter.datというファイル
　からデータを抽出し、counter2.datを作成した上で、counter.datを
　counter.dat.oldにリネームするようになっています。
　＃したがって、1.x系と共存はできません。

-- 
.:% Masao Mutoh<mutoh@...>

酒井といいます。

RDスタイルを使っているのですが、プラグインに渡される引数がエスケープさ
れてしまっています。例えば ((%hoge "&"%)) と書いても、 "&" ではなく 
"&" という文字列がhogeプラグインに渡されてしまいます。

他のスタイルではそのようなことはないので、
RDスタイルでも他のスタイルに合わせた方が良いと思います。
それには以下のようにすれば良いはずです。

--- rd_style.rb.orig	2005-09-26 17:39:14.000000000 +0900
+++ rd_style.rb	2006-01-14 17:58:23.000000000 +0900
@@ -87,7 +95,7 @@ module RD
 
 		# use for tDiary plugin :-p
 		def apply_to_Keyboard(element, content)
-		  	plugin, args = content.join("").split(/\s+/, 2)
+		  	plugin, args = CGI.unescapeHTML(content.join("")).split(/\s+/, 2)
 			%Q[<%=#{plugin} #{args}%>]
 		end
 

--
酒井 政裕 / Masahiro Sakai

こんにちは、柴田です。

昨日、23日に開発版のping.rbを修正しました。

送信を行うかどうかの真偽判定が逆になっていたようで、昨年の2005年10月から
全くwebUpdate.pingが送信されていない状況でした。開発版のping.rbを使用し
ている方は、最新版に入れ替えてください。最新版のスナップショットのプラグ
イン集には反映しているようです。

http://www.tdiary.org/download/tdiary-plugin.tar.gz

なお、最新版のping.rbのリビジョンは1.9です。

--
SHIBATA Hiroshi mailto:h-sbt@...
URL http://www.hsbt.org/

T.Shimomura です。

On Sat, 31 Dec 2005 17:02:23 +0900
Taku YASUI <tach@...> wrote:

> open-uri で referer URL にアクセスし，その中にHost: ヘッダのホスト名が
> 入っているかどうかをチェックする．リンクかどうかはチェックしていない．
> これを PStore に保存しておき，二度目以降はアクセスしに行かない．
> パーミッションさえそろえておけば，（信用できる）他のユーザともファイルを
> 共有できる．
> 
> というものです。
> referer ページにこれが無ければブラウザがリンクで自分のページには来れない
> ので、確実なチェック方法だと思います。

ほとんど同じ方式の Anti referer spam プラグインというのを作ってます。
http://www.netlife.gr.jp/redbug/diary/?date=20051120#p01

最初のバージョンから数えて１年３ヶ月ばかりの間、基本のロジックはいじって
ないんですが、チェックをすり抜けてきた referer spam は片手で数えるくらい
しかないようです。



> ただ、2点ほど tDiary の仕様に関して質問があります。
> 
> 1. フィルタに対するオプションはどのように設定させるのが良いですか?
> 
> 今のコードでは、@options［'pagecheckrefererfilter.autolist'］
> という形で指定させていますが、これはプラグインの設定仕様にほぼ沿った
> 形です。プラグインと重なる可能性がありますが、どうしたら良いでしょうか。

「フィルタに対する設定を変更するためのプラグイン」を、フィルタと同じ
ファイル名で作る、というのはどうでしょう。（なんか嘘っぽいけど）
私はそうしてます。


-- 
T.Shimomura
redbug@...

ただただしです。

やっとコードをいじる時間がとれました。放置してすみません。

On Tue, 13 Dec 2005 21:32:10 +0900, Kazuhiko <kazuhiko@...> wrote:
>なので、かなり昔に私が変更した defaultio.rb のトランザクション・ロックの
>最小化は、誤りでした。たまにツッコミが消えたりするのは、たぶんこのせいで
>す（ツッコミの書き込みと同時にリファラ付きアクセスが来て運が悪いと消え
>る）。

ここは了解です。巻き戻すか、別の方法で手を入れるかは、このあとの議論
で。

>現状の tDiary では、一つのトランザクションで「日記、コメント、リファラ」
>全てが変更されることはないので、キャッシュもトランザクションもそれぞれ日
>記用、コメント用、リファラ用に独立させれば、より同時アクセスをさばけるよ
>うになり、またトランザクションもわかりやすくなるのではないでしょうか。
>
>たとえば、特定の日へのリファラ付きアクセスの場合は、
>
>diary_transaction { その月の日記群を読み込む }
>comment_transaction { その月のツッコミ群を読み込む }
>referer_transaction { その月のリファラ群を読み込む }
>referer_transaction { 特定の日へのリファラの追加 }
>referer_transaction { 最新の日へのリファラの追加 }
>
>という動作になる感じです。最後の二つについては、DefaultIO では月単位のデー
>タへの書き込みになり（現状と同じ）、DbiIO ではそれぞれ一回ずつの UPDATE
>になるでしょう（かなり速くなる）。
>
>トランザクションまわりとキャッシュまわりのコードの変更だけで、実際のデー
>タについては変更なく移行できるかと思いますが、いかがでしょうか。

ここで言っているキャッシュはparser cacheのことだと思うんだけど、これ
を分割するのはあんまり嬉しくなさそうな気がします。

ちょっと整理すると、diaries(DiaryのHash)を生成するのに、各世代のIOは
こんなことをしています:

【pstore_io】
diaries ------------------------->  pstore

【default_io】
diaries -----> parser_cache --+--> *.td2
                              +--> *.tdc
                              +--> *.tdr

pstore_ioではdiariesをそのままPStoreに保存していたのを、default_ioで
はそのPStoreをキャッシュとして使い、その先にテキストファイルを置いて
います。キャッシュを本文/ツッコミ/リンク元で分離すると、以下のような
イメージになりますが:

【default_io改】
diaries --+--> parser_cache.d --+--> *.td2
          +--> parser_cache.c --+--> *.tdc
          +--> parser_cache.r --+--> *.tdr

3つのキャッシュファイルを開いてdiariesを再構成するのに、けっこうな計
算量が必要です(読み込んだキャッシュをそのままdiariesに代入できた現実
装に比べて)。

現在のdefault_ioは3つのテキストファイルを開いてparseし、diariesを構
築するのに比べて、PStoreファイルを一個読む方が負荷が低いという目論見
の元に実装されていて、それは実際の測定でも裏付けられています(ただし
指摘のあるようにリンク元が肥大化するとキャッシュの読み書きがかえって
性能を劣化させるのは確か)。

ということで、先のメールにも書いたように、リンク元の情報だけを完全に
別体化する方策を練ったほうが、default_ioにとっては効果がありそう。

さらに、dbi_ioを見てみると:

【dbi_io】
diaries -----> parser_cache --+--> (DBMS)

pstore_ioとの比較からわかるように、parser_cacheは本来IOの領分です。
しかし、再利用を鑑みて現在はTDiary直下に置いてあります。このため、
dbi_ioの実装ではそのままdefault_ioと同じキャッシュを使ってしまってい
るようです。このparser_cacheの部分は、dbi_ioの特性に合わせて別の実装
を使った方がいいんじゃない?……と思うんだけど、どうでしょう。

もしくはparser_cacheをまったく使わないという実装もアリかも知れない。
少なくとも、現在のdefault_ioのデッドコピーはあんまり良くない気がしま
す。

━━━━━━━━━━━━━━━━━
ただただし <http://sho.spc.gr.jp/>
♪ツッコミは、短く鋭く愛を込めて。
━━━━━━━━━━━━━━━━━