Aug 5, 2007

再構築がホットスポットらしいので。

「そんな餌で俺様が釣られクマー!」って感じ。

再構築の高速化に本気になれない訳。 (Junnama Online (Mirror))

なぜ高速化が重要かというと「速度が永遠のフロンティアだから」。言い替えると、機能によって達成できることもあるが、速度によって達成できることが「私にとっては」同等かそれ以上に重要だから。

このブログの再構築時間に興味がある方もいらっしゃるだろう。サーバーがえらくしょぼいことはさておき、エントリー約1000個で91秒かかる。このうち77秒、つまり全体の85%の時間をエントリーアーカイブの生成に費している。エントリーアーカイブのあるタグを外せば全再構築に63秒(エントリーのみなら49秒)しかかからないことも分かっている。要は再構築においては、エントリーアーカイブの生成時間がドミナントであり、したがってエントリーあたりの生成時間をO(1)に抑えることが肝要である。

だが一方で、MTの仕組み上このルールを破ってO(n)とかO(n2)かかるテンプレートを書くことはごく容易である。WebSig7/24の折にMTのテンプレートはデザイナーが理解できる唯一のテンプレート言語であると指摘していた方がいたのを記憶しているが、今のところは「テンプレートプログラムの性質」まではデザイナーの領分としてカバーし切れていないのかもしれない。悲観ばかりしているわけではなくて、knowledgeとして共有されてくれば徐々に解決していくと思う。

さて、junnamaさんの再構築に関するエフォートの中で一番示唆に富んでいる(と私が思う)のは、実はRebuildAt1stViewである。

RebuildAt1stView(Beta) (Junnama Online (Mirror))

まず、再構築によって生成される「ファイル」は「キャッシュの実装」であると考える。

つまり、全再構築時に行われているのは、すべてのキャッシュエントリーを無効化し、すべてのキャッシュエントリーをプリフェッチする操作である、と考える。

ファイルをopenし、writeし、closeするのには1マイクロ秒くらいしかかからないのに対して、(上でも述べた通り)エントリーの再構築には数十マイクロ秒(約77/1000秒)かかる。つまり、リードにもプリフェッチにも一エントリーあたり数十マイクロ秒かかるという、かなり深刻なメモリーウォールが存在する「記憶システム」だと見なすことができる。

このような場合、全キャッシュエントリーをプリフェッチするのは時間がかかり過ぎる。RebuildAt1stViewは、プリフェッチを一切行わず、最初にメモリアクセスがあったタイミングでフェッチするという戦略でプリフェッチのコストを回避している。別の方法としてはホットスポットのみ投機的にプリフェッチするという戦略も採り得る。

残念なのは、junnamaさん自身beta版と呼んでいる通り、やや実装が不完全なことである(対応しているのがエントリーアーカイブのみであるとか、プロセスの並行性を考慮していないとか)。

もし実装をMT4に限ってしまえるなら、RebuildQueue相当の機能が組み込まれているので、よりスマートにより完全な実現が可能になるように思う、ほとんどPerl版のダイナミックパブリッシング並みに。例えば、複数のクライアントが同時にアクセスした場合にRebuildAt1stViewで起き得る問題は、TheSchwartz::Jobの排他処理の問題としてより抽象化して取り扱えるし、ホットスポットをプリフェッチするのも特定のTheSchwartz::Jobのみをバックグラウンドかcronジョブで実行するような仕組みを用意すれば済みそうだ。時間があれば実装したいのだが、それがいつになることやら。

実は再構築にめちゃめちゃ本気な訳。 (Junnama Online (Mirror))

に書いてある、古いアーカイブの再構築を行わないというのはちょっと違う気がするなあ。ワークフローとしては理解できるのだけど、キャッシュのvalid/invalidをユーザに判断させることになって結局無駄な全再構築を誘発することになるのではないか。私としては自動的にinvalidationしてくれるRebuildAt1stViewの肩を持ちたいところ。

About Me

My Photo

つくばで働く研究者

Total Pageviews

Amazon

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