Sep 27, 2007

mt-searchがどうこうという話

「検索結果テンプレート」の修正でMTの検索結果表示にどの程度の効果があるか? (Junnama Online (Mirror))

面白いデータですね。

私が「下手な最適化」と書いたのは、

記事のメタ情報について「タグ」や「カテゴリー」を利用しているけど、エントリーの概要欄やキーワード欄、追記欄を利用していない、という場合はこれらのフィールドをできるだけ活用して他のテーブルにクエリを投げる回数を減らしてやる (MTからデータベースへのクエリの発行回数を減らす (mt-search.cgiを例にとって)。 (Junnama Online (Mirror)))

ようなハックのことです。高速化したければ、外部メタ情報の抽出をO(1)でできるような手段を下位レイヤーで提供するのが筋で、既知のデータベースの構造を元に局所的な最適化を行うのは二次的な方法に過ぎません。「局所的」と言ったのは、データベースの構造が変わった途端に有効でなくなるからです。「MTEntryDateは定数時間で取り出せるが、MTEntryCommentCountはそうではない」という知識は有用ですが、恒真ではありませんし、テンプレート作成者が「最適化」と称して再利用性の低いテンプレートを作り出すことも望ましいことではありません。

実のところ、MT4はそのような、つまり外部メタ情報の抽出を定数時間で取り出すための、手段を提供しています。FastCGI環境かmemcachedを使った環境で試すと分かりますが、エントリのコメント数などの外部メタデータはキャッシュされます。エントリーのコメント数を得る場合を考えてみると、初回はO(N)、2回目以降はO(1)、したがって平均的にはO(1)で得られるはずです。Junnamaさんの環境がどのようなものかは分からないので何とも言えませんが、もしFastCGI環境ならキャッシュハンドリングに改善の余地があるのでしょう。

2007-09-30追記: 仔細にコードを読んでいたらFastCGI環境では外部メタ情報をキャッシュしないことが分かりました。もう少し詳しい話は別のエントリで書く予定です。

あと実験に関して付け加えると、やや公正さに欠けると思います。2.が「ブログ記事のメタデータ」モジュールのみ外した状態になっているのは比較上問題があります。利用するテンプレートの個数が異なりますから。それなら最初からflatteningしたテンプレートを使って比較すべきです。

また、計測時間はMT::Builder::build()メソッドの実行時間を計測したものとほぼ同じとみなせると思いますが、ということは、スクリプトの呼び出しオーバーヘッドや検索本体の処理、テンプレートのコンパイル時間などを含まないということです。これらの時間が全体の実行時間においてdominantなら効果は限定的となりますね。実際のところは分からないわけですが。


ちょっと試しに計ってみました。単位は全部「秒」。

オリジナル
MaxResults レンダリング トータル 差分
10 0.304314 1.528 1.224
20 0.517478 1.868 1.351
40 0.927628 2.364 1.436
60 1.343529 2.865 1.521
80 1.786946 3.451 1.664
100 2.208508 3.996 1.787
メタ情報のうちコメント・トラックバックに関するものを削除したもの
MaxResults レンダリング トータル 差分
10 0.168146 1.406 1.238
20 0.237147 1.543 1.306
40 0.376270 1.795 1.419
60 0.514390 2.058 1.544
80 0.659881 2.309 1.649
100 0.821395 2.606 1.785

相変わらずふざけるなってくらい遅いです、特にオリジナルの方。MaxResultsを大きくすればするほど全体時間に占めるレンダリングの割合が増加していて、オリジナルの場合には50%を越えています。やはり10〜20が実用域ですね。私の感覚からすると、0.5秒を切らないと常用する気は起きません。

About Me

My Photo

つくばで働く研究者

Total Pageviews

Amazon

Copyright 2012 Ogawa::Buzz | Powered by Blogger
Design by Web2feel | Blogger Template by NewBloggerThemes.com