誰(どこ)? がサーバーの負担を負うべきか。

MTのモブログ機能拡張の開発をやりはじめて約一ヶ月。

今日はスタティックバージョンがほぼ完成した。ページ分割も含めて静的HTMLで携帯サイトを構築するもの。

追記:とりあえず暫定公開

• 携帯版(スタティックバージョン)

(画像のサムネイルをキャッシュしたいところ...というかこれも生成の際に自動作成してやろうか...再構築重そうだけど「サムネイルが存在しなければ生成」ならまぁなんとかなるかも) /追記ここまで

---

こういうの↓見てると、やっぱりダイナミックよりスタティックかな、と。

• Googlebot、猛威を振るう

ただ気になるところもあって、普通にやると「再構築」時間が倍かかる。何に時間食ってるかというとページ分割部分である。そこでいくつかの工夫を。

プラグインの設定画面で「強制的に再構築」オプションを付けた。

エントリーのmodified_onをチェックして、10分以内に更新されていない且つ静的ファイルが存在している場合は再構築しないように。

インデックス・アーカイブ関係はBlogのエントリーの最終更新日を見て再構築の要不要を判断するようにした。コードはこんな感じ。

unless ($need_rebuild) {
	use MT::Entry;
	my $entry =  MT::Entry->load({
		blog_id => $blog_id,
		status => 2,
		},{
		sort => 'modified_on',
		direction => 'descend',
		limit => 1,
		});
	if (-f $checkfile) {
		my $modified_on = $entry->modified_on;
		$modified_on = &get_unixtime($modified_on);
		if ($modified_on > &offset_time(time, $blog)-600) {
			$need_rebuild = 1;
		}
	} else {
		$need_rebuild = 1;
	}
}

問題はカテゴリーアーカイブなんやけど、上手い手が見つからないなぁ。

my $entry = MT::Entry->load({blog_id => $blog_id,}, {
		'join' => [ 'MT::Placement', 'entry_id',
		{ blog_id => $blog_id,,  category_id => $cat_id,},
		{ 'sort' => 'modified_on', # <<これが駄目, MT::Placementにないから...
		direction => 'descend',
		unique => 1,
		limit => 1 } ],
	});

ループで回すのは効率悪いし...

まぁ、また明日。