タグ : coreserver

FeedBurner でフィードを配信しよう

無事に三月になりました。今の会社とは今月でさようなら。今は次の会社がビシッと決まるのを祈るばかりです。

そういえば一時期、ぼくのサイトでは不調だった FeedBurner ですが、ずいぶん前にもう一度試してみたところ、エラーが起きるようなこともなく順風満帆にフィードを配信してくれるようになってくれました。結局のところ原因はわからずじまい。きっと CORESERVER 側の負荷(そういえばこれも原因不明だ)だったんだと自分を納得させることにしています。

この FeedBurner を使えば何が便利かって、やはりどれくらいの方が RSS リーダを使って購読しているかがわかるってことでしょうか。いつも見てくださっている方、どうもありがとうございます。初見の方も見てくださってありがとう!

feedburner 解析結果

さて、たとえばこれなんかがぼくのサイトの昨日における解析結果なのですが、さっぱり賑わっていないことはともかく、RSS の購読者数と実際に配信されたフィードからクリックされた数なんかが一目瞭然なわけです。一番数が伸びているのが二月八日で、「動物殺処分に思う。」や「脱メタボ弁当」。

ただ、この購読者数だけを見て、わっほいうほほいとラブラドールレトリバーのように喜んでいると、実は半数以上がボットでした。ありがとうございます的なオチが待ちかまえており、もっとも参考になる数は、別ページで掲載される「リーチ」と呼ばれるファン的な数です。

また、FeedBurner を使っていれば、どんな RSS リーダを使っているかもわかったりするのがなかなか面白い。やはり一番強いのが Google なのですが、中には Fastladder (livedoor Reader の英語版) や、なぜか Perl の HTTP:Lite なんかもあったり(ボットだろうなあ)と、多岐にわたっています。

この FeedBurner、自由に RSS フィードの配信設定を変更できるようなウェブログではオススメです。登録自体も簡単でURL を登録するだけですし、 WordPress の場合は移行が容易にできる専用のプラグイン「FeedBurner FeedSmith」なんてものもあります。

これと Google Analytics とを組み合わせれば、アクセスの解析なんかは容易にできるのでオススメです。まだの方は登録&使用してみてはいかがでしょーか!

RSS って食えるの? いつもありがとう!

CORESERVERでWP-DBManagerを動かすために

起きたらなぜか三時だった。

二度寝しようにも目がさえて眠れないので、摩訶不思議な状態に陥いり前々から気持ち悪く思っていた問題を解決することにしてみました。

WordPress のプラグインのひとつに、データベース内のデータをバックアップ、 リストア、バックアップしたデータをメールで自動送信ができるというすばらしいプラグイン「WP-DBManager」というものがあるのですが、このサイトが動いている CORESERVER ではデフォルト状態だと設定後に手動でのバックアップはできても、肝心のメール配信機能で 0byte のファイルが送られてきてしまうという問題が発生します。

これはどうも「そんな処理できねーよ!」というサーバー側からの無言の抵抗のようで、このメール自動配信機能は cron として処理する部分である以上、CORESERVER で……というよりも XREA 系のサーバーで動かすには、PHP を CGI として動作させる必要がでてきてしまうようです。

別にそうすりゃいいじゃないというお話でもあるのですが、CORESERVER のサーバーヘルプに書かれている説明だと『モジュール版PHPに比べて、動作が遅くなる。負荷が掛かる。』とあり、重くなるんかよウゲゲーと感情的に嬉しくありません。早いほうがいいですよね!

ルートに「AddHandler application/x-httpd-phpcgi .php」と書いた .htaccess を置けば実に簡単に解決するのですが、これだと全体がそう処理されてしまうわけですから、前述の負荷云々で問題が出そうです。

かといって、CGI として動作させないことにはどうにもなりません。そこで今回、その被害(?)を最小限に食い止める方法をご紹介してみます。

方法はいたって簡単。WordPress のルートフォルダに .htaccess を設置もしくは追記してあげるだけ(たぶん mod_rewrite がらみのものがあるので、追記になるはず)!

<files wp-cron.php>
AddHandler application/x-httpd-phpcgi .php
</files>

要は WordPress の cron 部分を担当しているファイルだけを指定してやるだけです。ひとまずこれでメールの 0byte 問題は解決。負荷 pt なんかもそんなに上がらないんじゃないかなーと踏んでいます。

お困りのかたは是非どうぞ、と言いたいところですが、ぼくも今し方、書き換えたばかりのものなので他にやっぱり問題が出るかもしれないというところは、念頭に置いていてくれると助かります :-)

おっと、ちなみに CORESERVER の mysql と mysqldump のパスは


mysqldump : /usr/local/mysql/bin/mysqldump
mysql : /usr/local/mysql/bin/mysql


となります。

サーバーの負荷が急に上がってしまったヨ

契約しているホスティングサービス「CORESERVER」さんですが、管理ページ上からCPUなり転送量なり、どの程度の負荷があるのかをポイントとして確認することができます。

ここ数日、投稿時もサーバーエラーが出たりと割と難儀していたこともあり、久しぶりに管理画面を見てみると、これまではずっと負荷状況的に問題がなかったところ(負荷率 0 ポイント)が 2/2 以降に急上昇。

問題になった 2/2 頃に導入したプラグインといえば、

ぐらいでしょうか(結構入れてるな!)。

このどれかが悪さしているというのも考えづらく、色々と原因を探ってみたところ、プラグイン「Smart Archives」を利用して生成しているアーカイブページでのクエリ数が異常に多いことに気がつきました。他のページなら、およそ30程度なのですが、アーカイブのみ 120 を越える勢いでクエリを発行している模様。

これはなんだろう。このページに Google の bot なりがガツガツやってきた影響で CPU 負荷が上がってしまったとか、そういうオチだったりするのか、たぶんそうだろう、そうであって欲しいと「アーカイブ」ページの一覧生成に利用していたプラグイン「Smart Archives」を急ぎ撤去し、同機能(むしろこっちのが高機能)な「wp-mosquito」に入れ替えました。

今のところ、実際にこれで負荷が収まってくれるかは分からないのですが、ちょっと一ページで吐くクエリとしては異常だと思われるので、同プラグインを利用されている場合にはちょっと注意が必要、かもしれません。一応、理由をサポートに問い合わせているところでもあるので、はっきりとした原因が分かった際にはこちらでもお知らせします。

ちなみに一ページごとにどれぐらいのクエリ、処理速度がかかっているのかは、WordPress のデフォルトテーマにもある以下のコードをテーマのフッタにでも挿入しておけば、いつでも確認することができます。

カスタムテーマを使用しているかたも、そっと挿入しておいてみてはいかがでしょーか。

<!– <?php printf(__(‘%d queries. %s seconds.’, ‘kubrick’), get_num_queries(), timer_stop(0, 3)); ?> –>

「’(シングルクォーテーション)」が全角になっているので挿入時には注意してください :D

freshreader が突然動作しなくなった編

1/24 頃、ちょうどさくらインターネットで契約していたサーバプランの解約をしていたところ、CORE SERVER で動かしているはずの FreshReader(フレッシュリーダー)が動作しなくなってしまった。

どうも CORESERVER 側で PHP のアップデートをした模様。フレッシュリーダーを動かすために、結局色々と設定をいじくる羽目になったので、まとめメモ。

  •  フレッシュリーダーを設置しているフォルダに、php.ini を作成して、以下を追記。

    zend_extension = /virtual/アカウント/public_html/ドメイン名とか/freshreader/ioncube/ioncube_loader_lin_5.2.so

これだけだと、記事を取得してくれるクロウラーさんが「ここじゃまともに動作しないから、これを見てしっかり設定したまえ」的(<meta http-equiv=”refresh” content=”0;URL=ioncube.php” />click<a href=”ioncube.php”>here</a>)なページに飛ばされるので、併せてもうひとつ。

  • クロウラー用の cron を変更。

    /usr/local/bin/php -f /virtual/アカウント/public_html/ドメイン名とか/freshreader/crawler.php -c /virtual/アカウント/public_html/ドメイン名とか/freshreader/php.ini

ひとまずこれで大丈夫!

feedburnerの使用を止めてみる。

CORESERVERに移転後、feedburnerから毎時の勢いで

FeedBurner had trouble retrieving your Source Feed:

http://blog.newf.jp/feed/

なんてメッセージがガンガン届くようになってしまいました。

要は、あんたのところのフィードおかしいよというお知らせで、

The error message is: Error getting URL: 500 – Internal Server Error

Actions you can take:
Validate your Source Feed with Feed Validator. This service provides additional detail about the problem, and how to repair it.
Resync your FeedBurner feed once you have repaired the source feed.
Contact FeedBurner for help with your feed if all else fails.

具体的にはこんなメッセージがおまけで付属しています。

RSSフィードのURLが自分の環境(Firefox)で、たまに何も表示されなくなってしまうことがあることが関係しているような気もするのですが、そもそもこれがさっぱり原因が分かりません。CORESERVERに問い合わせてみるも、ルータの再起動をしなさいだとか、キャッシュをクリアしなさいということで。むむむ :-(

とりあえずFeedBurner 側でフィードのURLを変更しようとして、http://blog.newf.jp/feed/ 、http://blog.newf.jp/?feed=rss を新たに入力しても不正なURLだとか、フィードが含まれていないだとかではじかれるようになってしまい、にっちもさっちもいかなくなってしまいましたので、上記の問題が解消するまでは(するのかなあ)FeedBurnerは使用しないことにしました。

うーん、なんでだろう。

サーバーお引っ越し後の問題

CORE SERVERへの引っ越し後、どうもRSS Feedを表示するページに問題が起きている様子。

http://blog.newf.jp/feed/で、RSSフィードを読み込めるはずなのですが、なぜか真っ白で表示されてしまいます。さくらインターネット時代には、こんな症状は出ていなかったはず……。いろいろと調べてみたもののお手上げ状態。まったく原因がわかりません。

と思ったら表示されたりもする。ウムム、なんなんだ。

サーバーお引っ越し終了。

約一日のあいだ、当ウェブログ(newf.jp)に接続できなかったと思います。

当ウェブログ(と、他のドメイン)はこれまで「さくらインターネット」さんのレンタルサーバーを借りて運営していたのですが、「もっとじゃんじゃんペットの動画とか載せたい!」なんてリクエストに応えるには、少しサーバーの容量が心許ない感じでありました。

とはいっても、 スタンダードプランで1GBはあるし、贅沢いわなければ全然余裕あるわけで、なにせ年間五千円という低価格。あまり文句も言えまいと考えていた矢先、ドメインの管理でお世話になっている「VALUEDOMAIN」さんで新しいサーバーホスティングサービスが開始されていた模様。

CORESERVER.JP(コアサーバー)は、PHP MySQLの快適性を重視した大容量の次世代レンタルサーバーサービスです。
XREA の仕様を基本に、より高性能なサーバーと高速な回線に、より豊富なリソース配分を加え、より少ない定員数で安定性を高めた上位互換サービスです。 VALUE-DOMAINとの連携でドメインの運用を自由に行えます。

CORESERVER.JP:コアサーバー (2007-08-05)

これまでの年額五千円と同額でありながら、サーバーのスペックやら手が出せる範囲も相当広い!何より「上位互換」という響きがいい! 仮想マシン上で動かしてるのかしら、これ。安くていろいろできる、というなら躊躇う理由もないことからお引っ越しの準備をすることに。

データベースのバックアップは取っているので、特にめんどくさい作業も必要なさそう……と思っていたものの、ドメインの移管とDNSの反映に予想以上に時間を費やしてしまい、かなりの長い期間、ドメインにアクセスできない状態になってしまいました(もちろん、一度に設定したのではなくて順次していましたが)。

WordPressの移行そのものは割とすんなり。一部のプラグインで前の情報が残っていたためにうまく動作しないものがありましたが、wp_option から直接編集することで対応も完了。

おそらくおかしな箇所ももう無い(たぶん)はずですが、なにやらおかしなエラーが出ているような場合はコメントなどで教えていただけると助かります……。