最近はあまりNucleusのカスタマイズをすることもなくなってきているのですが、Nucleus CMS Japan Wikiの更新をチェックしていて、久しぶりにちょっと使ってみようかなと思えるプラグインを見つけたので、久しぶりにNucleus関連のエントリを書きます。

NP_Revisionというエントリの差分が見えるプラグインです。

・plugins:revision [Nucleus CMS Japan Wiki]
・NP_Revision (v0.7-x) - 記事の変更履歴管理と差分表示 - あけび猫のブログ

インストール後の使い方がちょっと謎ですが、スキンに下記のような記述を入れることで履歴へのリンクが現れるようです。

単に履歴を残すだけであれば同様のプラグインにNP_ItemHistoryがありますが、こちらは任意のリビジョンを選択してグラフィカルに差分を表示させることができます。どれくらいアクセス制御ができるのかは確認していませんが、複数人で共有するブログなんかだと便利そうですね。

PHP5にしてからタグクラウドやアクセスランキングが真っ白になってしまうという症状に悩まされていましたが、それがどうも出力制御関連^*1の問題のようなのでソースコードをob_startでgrepして該当のプラグインを片っ端からはずしてみるというちょっと乱暴なやり方で原因を探ってみました。

その結果、NP_LinkCounterをはずすと症状が解決できることが分かりました。
PHP5でNP_LinkCounterを使って不具合が出ている人は検索したところいないようなので、うち固有の現象かもしれませんが、とりあえず修正にチャレンジしてみました。

PHP5に移行してからNP_SearchedPhraseの検索語ランキングが出力されなくなってしまったのですが、このエラーの原因についてはちゃんとerror_logに出力されていました。

PHP Fatal error: Using $this when not in object context in NP_SearchedPhrase.php on line 262

どうやら、PHP5からはクラス定義の中以外で$thisという変数を使うとFatal Errorとなるようです。NP_SearchedPhraseの中で$thisが使われているのはrankList()の部分です。プログラムを読む限りでは呼び出し時の引数と、関数定義の仮引数名を同一にしているだけのようだったので、この関数内の$thisを$tに書き換えて回避することができました。

php5にすると細かい部分でチェックが厳しくなっていたりしますね。まぁ、$thisは予約語みたいなものですし・・・・・こういうチェックを入れること自体はプログラムの健全性に貢献するので互換性の問題を抜きにすれば賛成ではあるんですが。。。。

先日こんなメールがAmazonから飛んできました。

[Amazonアソシエイト] ECS 3.0 サービス終了のご案内

先日もメールにてご案内しましたが、このたび、Amazon E-コマース Webサービス　バージョン3.0（以下、Amazon ECS 3.0）のサービスのご提供を 2008年3月31日 をもちまして終了させていただくことになりましたことを、改めてご案内いたします。

弊社のモニタリングシステムによる調査では、お客様のアソシエイトIDが2008年2月14日から21日にかけての期間、Amazon ECS 3.0のリクエストに含まれていましたので、このご案内をお送りしております。繰り返しのご案内になりますが、 2008年3月31日以降は、Amazon ECS 3.0のリクエストの処理が完全に停止いたします。 サービス停止日までに、お使いのサービスの提供元・ご担当者様や関連部署と連携いただき、ご利用のサービスのAmazon アソシエイト Webサービス4.0（旧称：Amazon ECS 4.0）へのアップグレードを完了し、このサービス停止による影響が発生しないようにしていただけますよう、ご対応をお願いいたします。

† 原因はNP_Amazonか！

特にECS3を使ったサービスを作った覚えもないし、たまにAmazonは間違いメールをよこしたりするので、特に気にも留めていなかったんですが、思い立ってちょっと詳細に調べてみるとNP_AmazonがECS3でできていることがわかりました。つまり、NP_Amazonは3/31日以降は動作させることができません。NP_Amazonってユーザーがそこそこ多いので地味に大きな問題なんじゃないかと思っています。

yuさんのCACHEMANAGER導入レポート。

CACHEMANAGER 適用中 - Nucleusだとか

それなのでCACHEMANAGERによるCache_Liteのファイルキャッシュだと逆に成績が落ちてしまうけど、それでも値としては悪くはない。 クエリ発行数は半減するので、DBが重くてパフォーマンスが出ない時間帯には活きるはず。このまま様子見します。

普段はmemcache版しか使っていないのでファイルキャッシュ版の性能については僕もあまり検証していませんでした。ファイルキャッシュ版は値ごとに１ファイル生成するような構成になっているので、意外とその辺りのオーバーヘッドが大きいのかも。この辺りは対象クラスごとに１ファイルにするとか、キャッシュ方法についてちょっと改良すればパフォーマンスが変化するかもしれません。

だいぶ昔、itemidの欠番を空のドラフトアイテムとして回収できるスクリプトを作った話を書いたのですが、そのままお蔵入りになっていたのでいまさらながら公開しておきます。

まぁ、番号が飛び飛びでもそんなに困らないと思うんですけど、几帳面な人向けなのかなぁ。言わなくてもわかると思いますが、基本的に自己責任でお願いします。

† 使い方

1.上記のプログラムをconfig.phpと同じフォルダに入れる。
ファイル名は同じでなくても大丈夫ですが、冒頭のブログId, 著者Id, カテゴリIdについては適当なものに書き換えてください。

2.コマンドラインもしくはブラウザからプログラムにアクセスする。
実行に成功すると、SQL文が表示されますがあまり気にしなくて大丈夫です。

3.管理画面にログインすると、回収したidのエントリがドラフトとして追加されている。

Nucleusは動的生成なので、静的ページよりは画面の表示に時間はかかるのは分かっているのですが、実際に平均でどれくらいの秒数がかかっているのかちょっと気になっていたので、レスポンスの統計をとってグラフ化してみました。

これを見ると平均で0.3秒程度の生成時間になっているようです。
もう少し時間がかかっていると予想していたんですが、思っていたよりも早いですね。

cactiが復活したのでサーバのCPU Usage ２年間分^*1を貼ってみます。CPUはPentium4 3GHzで、大半の負荷はNucleusの関連プロセス(apache, mysql, memcached)によるものです。１日あたりのPVはロボットによるアクセスも含めて現在約４万強(1700PV/h)くらい^*2です。

グラフを見ると2006年3月末と12月中に大きくCPU Usageが下がっていますが、これはアクセスが下がったわけではなくチューニングを行ったためです。特に後者についてはmemcachedの導入ポイントであり、コア改造によりプラグインオプション、スキン、テンプレート、グローバルオプションがmemcachedにてキャッシュされるようになったことにより、かなりmysqlの負荷軽減が達成できていることがわかると思います。

はてなスターですが、どうやらテンプレート/スキンの記述に依存してしまうようです。
解説を読んでNucleusでの使い方を軽くまとめてみました。

NP_MetaTagsで任意のテキストから特徴語を抽出できるようになったので、この特徴語を使ってNP_Relatedの関連検索のキーワードとしてこの特徴語を使うように改造してみます。

まず、NP_Relatedの改造前の動作ロジックですが、キーワードをエントリ追加（変更）時に手動で入力できるようになっており、基本的にはそのキーワードで検索を行います。なにもキーワードを入力していない場合にはエントリのタイトルを使って検索を行うようになっています。今回は何もキーワードを入力していない場合、エントリのタイトルの代わりに特徴語を使うように改造してみます。このようにしたのは、手動で入力しているキーワードと共存をさせるためです。

実際の動作については下記の「こんな記事もあります」のブロックでご覧いただけます。特徴語検出自体はそんなに大した機能ではないですが、こうやって他のサービス（プラグイン）のバックエンドとしてはいろいろと応用しがいがありますね。