2005年06月02日
Rast,Hyper Estraierの性能評価クリップ
Ceekz Logsさんと/.jのOliverさんが、性能評価をしているのでクリップするテスト。
Ceekz Logs Hyper Estraier のお試し結果
前回、調子乗って行っていた100万件のニュース記事のインデキシングですが、9時間ほど掛かりました。これは、月別に差分インデキシングを行ったからかもしれません。合計で 1.0G ほどかな。
他にもソートの速度が気になっているそうです。
Hit件数が多くなるとソートに必要な処理も増えてしまうので、ある程度諦めてしまうのか
高性能な仕組みを考えなくちゃですね。。。
それかインデックスを分割して、後ろの順位をばっさり切り捨てるとか。
Oliver の日記 全文検索エンジン：Hyper Estraier
速度低下はかなりリニアで、とても素直な挙動といえる。indexのサイズも元のデータが693MBなので、かなり優秀。成長させていったindexに対してestcmd optimizeを実行したところ、300MBまで縮んだ。
Oliver の日記 全文検索エンジン：Rast (ちょっとチューン)
ディスク上のDBへのsync回数を減らすことで実時間ベースのパフォーマンスは劇的にアップした。この範囲で5-8倍であるというのは、ストレートにsync回数が減ったのが響いていると思われる。この設定での使用メモリは約300MB。しかし、テストで16万エントリをいっきに登録するテストをしたところ、10万エントリを越えたあたりからパフォーマンスは劇的に低下していった。
初のRastとHyper Estraierを（おそらく）同じ文書群での性能を検証をした情報ではないでしょうか。
Rastでは約4時間40分かかっていたindex処理を、Hyper Estraierでは約12分で完了している模様。
早すぎ、、、ですが詳細なindex条件が記載されていないため参考程度ですな。
自分も検証しないと。。。
BDBをチューニングしたり、RastのDBエンジンをQDBMに変えちゃうとパフォーマンスが上がるのかを試してみたいところ。
ちなみに明日のネタは、YappoLabsの採用基準やiYappoのアーキテクチャを絡めつつ
前回のネタの紹介部分を省いた感じになると予想されます。
シナリオは大体あるので、さくっとパワポが作れるといいな。
Post a comment