2009年8月アーカイブ

すっかり告知が遅れてしまったのですが、来週の木曜日(9月3日)に大阪でセミナーがあります。告知が遅れていたのは内容が決まらなかったこともあるのですが、決まらなかった理由は実はPower CMS for MTではなく新しくリリースする3つのプロダクトがどこまでいけるかはっきりしなかったということも関係しています。

実際、来週時点で完成・リリースできるものはないのですが、3つとも9月にリリースということで日付は決定しましたし、明日には何らかの発表ができるかと思います。

追記 : 発表しました。

9月3日のセミナーでは、新しいプロダクトについてもご紹介する予定です。関西方面の方は是非ご参加ください!

もうMT5がどうとか言っているこの時期にMT4(MTOS4.261)に移行しました。

移行をためらっていたというか放置していた理由は特にないんですが(忙しいし...そもそもブログを書く分にはMT3で困らないし)、大阪オフィスの移転時にオフィスに置いていたサーバーがトラブルがちになってしまい管理者のM君に怒られて移行せざるを得なくなった、ということで良いきっかけなので移転を契機に長らく親しんだMT3.3からMT4系の最新バージョンに移行することにしました。

忙しいし面倒という以外に移行をためらっていた理由があるとすれば、

  • Permalinkが変わるのは嫌。
  • MT3用に自分のブログ用に作っていたプラグインの検証が面倒。相当カスタマイズしていたし、そのままじゃ動かんだろう。
  • CSSをインラインで書いていて美しくないし、デザイン変えたらインラインで書いていたCSS全部書き直すのかよ。

そこで。以下のエントリーの方法でPermalinkを引き継いでエクスポートできるインデックステンプレートを作成し、インラインで書かれたCSSを削除するプラグインを書いてエクスポート。

ドキュメントルート以下のデータはtarに固めて移行、移行先で展開。新規にインストールしたMTOSに「既定のブログ」テンプレート適用し、エクスポートしたデータをインポート。

スタイルは先日公開した STYLE LEAVES の「Gear Module」を選択。

最後にアーカイブマッピングの調整をして再構築して移行完了しました。

テンプレート調整とチューニング

上記の移行を行ったデフォルトの状態での再構築時間は3分30秒前後(550エントリー)。MT3.3の時はだいたい1分45秒程度だったのですがそもそもサーバー(ハード)自体が違うしプラグインやテンプレートのインクルード等でチューニングしまくっていたから単純に比較はできないと思います。

それでも、まぁ、趣味再構築だし当時よりは色々知識も蓄積されていますから、時間の許す範囲でテンプレ調整と高速化を行ってみました。

EntriesPerRebuild 値の変更

これで、400とか指定してテスト。確かに2分台にはなりました。でも劇的って程じゃないな。そもそも一度にどれだけのエントリーを再構築するのか、ってこと何だから値を上げるってことはそれだけ負荷をかけるということ。サーバースペックがそこそこあるからいいけど、どこでも使える対策じゃないですよね(最終的には150程度にしました)。

そこで、負荷軽減と高速化として次のステップへ。

MTRequestCache プラグインのインストールとテンプレ調整

以前書いたRequestCacheプラグインをインストール。共通部分をキャッシュするように変更しました。

サイドバー部分のテンプレートを少し変更(これは高速化と関係なく好みの問題で)して、最近のブログ記事10件を表示するようにした。そしてこの部分やカテゴリーリスト、月別アーカイブリストなど、主に右側のサイドバーの共通部分にMTRequestCacheブロックタグを適用。

例 : アーカイブウィジェットグループ

<MTBlogID setvar="blog_id">
<MTRequestCacheBlock key="ArchiveWidget" blog_id="$blog_id">
<mt:Ignore>
    アーカイブの種類に応じて異なる内容を表示するように設定されたウィジェットです。詳細: http://www.Movable Type.org/documentation/designer/widget-sets.html
</mt:Ignore>
<mt:If name="category_archive">
    <mt:IfArchiveTypeEnabled archive_type="Category-Monthly">
        <$mt:Include widget="カテゴリ月別アーカイブ"$>
    </mt:IfArchiveTypeEnabled>
</mt:If>
<mt:IfArchiveTypeEnabled archive_type="Category">
    <$mt:Include widget="カテゴリアーカイブ"$>
</mt:IfArchiveTypeEnabled>
<mt:IfArchiveTypeEnabled archive_type="Monthly">
    <$mt:Include widget="月別アーカイブ"$>
</mt:IfArchiveTypeEnabled>
</MTRequestCacheBlock>

要するにMTの再構築って1度のcgiへのリクエストで複数のエントリーやアーカイブをファイルに出力するわけですが、その1回のリクエストで処理される複数ページのテンプレート構築処理の際にMTRequestCacheBlockタグ内は最初の1ファイルのみ再構築され、2ファイル以降についてはメモリにキャッシュされたデータが使われるわけです。よって、このブロックを処理する時にSQLによるリクエストやテンプレートに関する処理は行われず、その分負荷軽減と高速化が図られます。

最終的には4カ所をMTRequestCacheBlock化して、全再構築時間1分30秒程度。

3分30秒→1分30秒ですから2倍以上。まずますではないでしょうか。

Twitterの某発言に反応して書いたものです。

任意のエントリーをトップページとしてインデックスに取り込んだとき、そのエントリーの行き場がないのよ リンクされてないだけだから実害はないのか?(RSSとかサイトマップとか検索とかがまずいよね)

出力時にフィルタリングして静的ファイルを吐かないようにすることも出来るけど、条件指定が面倒だし(実装の都合)、ダイナミックパブリッシィングが有効だったらURL叩けばページ出てくるだろうし、RSSや一覧なんかでは逆に出力しない指定しなきゃならないから「トップページに取り込んだ任意のエントリーを、ステータスが下書きでも出力できればいいんじゃないか」ということで。

<mt:entryblock key="id" value="1">
<!--EntryIDが1のエントリーのコンテクスト-->
</mt:entryblock>

<mt:entryblock key="basename" value="toppage">
<!--EntryBasenameが「toppage」のエントリーのコンテクスト-->
</mt:entryblock>

<mt:entryblock key="title" value="トップページ">
<!--EntryTitleが「トップページ」のエントリーのコンテクスト-->
</mt:entryblock>

当該エントリーを下書き状態にしておけばページは生成されませんから、これで要件が見たせるんじゃないかと思いますがどうでしょう?

随分間が開いてしまいましたが、Power CMS for MT ランチ付きお勉強会 開催の経緯について少し。

何か、Twitter(コミュニティ)のスピード感を実感した一件なのでした。

  • tomixさんが某案件でPower CMS利用
  • 自分でテンプレ組むのでレクチャーしてよ
  • なら他の人も誘って勉強会にしましょうか
  • そうしましょう
  • Twitterでつぶやく
  • tomixさんの他に fuuri さん mersyさん、KIASMAさん、julia28dfさん、d4rさん、kara_dさんが参加表明
  • Twitterで日程調整
  • kara_dさんだけは都合付かず
  • +数名参加表明、この時点でウチの会議室キャパオーバー
  • julia28dfさんから会議室紹介してもらう
  • 会議室予約する
  • 告知する

この間たった2-3日の出来事です。1週間後には開催、結局30名程度参加して実施することができたのです。

そしてもうひとつ、我ながら(?) Power CMS for MT便利と実感したんだ。

Power CMS for MTでサイトでの告知を行う際には、

  • 製品サイトで過去のセミナー関係の記事を「複製」して告知記事を作成
  • コーポレートサイトのブログ「SSL(このブログにウェブページを作るとURLがhttps://〜になるテンプレートが仕込んである)」に参加申込フォームを作成(拡張フィールド機能を使えばすぐ出来る)

たったこれだけの手間でできてしまった。いや、便利です。本当に。

副次的な? ことだけど、このフォームを作って自分で送信テストしてみた時に気づいた点が2点あって、

  • 拡張フィールドの値に「<span></span>」ってのが入っててそれがそのままフォーム送信確認メールに含まれてしまう(これは最新版で対処済み)。
  • フォームから送信されたデータを一覧出来る「フォームデータ」オブジェクトの一覧画面から、選択・一括してメールの返信が送れると便利(この機能があれば後がもっと楽)

やっぱり、自分たちが製品を実際に使うこと、そして気づいたことを反映して行くこと。つまり、机の上だけで考えた製品でない、本当のユーザー指向製品にしていくことが大切なんだということを改めて感じた出来事でした。

Facebook

Twitter

このアーカイブについて

このページには、2009年8月に書かれたブログ記事が新しい順に公開されています。

前のアーカイブは2009年7月です。

次のアーカイブは2009年9月です。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。

Powered by Movable Type 6.2.6