Ogawa::Memoranda

「検索結果テンプレート」の修正で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環境ならキャッシュハンドリングに改善の余地があるのでしょう。

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

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

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

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