Oliverの日記： 全文検索エンジン：Rast (ちょっとチューン)

Rast.pmの作者でもあるYappoさんのアドバイスに従い、Rastをちょっとチューンしてベンチマークを取り直した。

今回もベンチマークは1万エントリをindexし、その後に1万エントリづつ追加するのに必要な時間を計測し、index増大に伴う速度の低下を検証した。前回との変更点はsync_threshold_charsを100万に設定したことのみ。未設定時の場合は10万なので、ちょうとシンクロ回数が10分の1になるはずだ。

Journals indexing:
10000 entries: 0m49sec
+10000 entries: 1m26sec
=========================
20000 entries: 2m15sec
+10000 entries: 2m00sec
=========================
30000 entries: 4m15sec
+10000 entries: 2m11sec
=========================
40000 entries: 6m26sec
+10000 entries: 2m41sec
=========================
50000 entries: 9m07sec
+10000 entries: 3m14sec
+10000 entries: 3m46sec
+10000 entries: 4m24sec
+10000 entries: 4m58sec
+10000 entries: 5m58sec
+10000 entries: 6m21sec
(中略。いっきに作成)
162783 entries: 282m15sec (711MB)

ディスク上のDBへのsync回数を減らすことで実時間ベースのパフォーマンスは劇的にアップした。この範囲で5-8倍であるというのは、ストレートにsync回数が減ったのが響いていると思われる。この設定での使用メモリは約300MB。しかし、テストで16万エントリをいっきに登録するテストをしたところ、10万エントリを越えたあたりからパフォーマンスは劇的に低下していった。

チューンした結果、数万エントリではindex作り直しでも十分に実用になるが、数十万エントリにはまだまだ届かない、というのがいまのところの結論だ。バックエンドに使っているBerkley DBへsyncする段階が明らかにボトルネックとなっている。一回一回のsyncがそれだけ時間がかかる、ということはエントリをひとつだけ追加するのでもかなりの時間がかかってしまう、ということであり、初期index作成時だけの問題ではない。

明日のLinux Conference 2005にてRastの作者が講演するので、行けたらここらへんをコメントとしてぶつけてみようかな。明後日の全文検索BOFにもなるべく行きたい。