「自宅サーバー運用」カテゴリーアーカイブ

ブログをMovableTypeからWordPressへと移行したときの作業記録


先日のことですが、今までMovableType 5.1で運営していたこのブログをWordPressへと移行してみました。

移行したきっかけはやはりMovableTypeの再構築にかかる時間の長さです。現在は自宅サーバーで運営されている当サイトですが、近日中に諸事情から安いVPSに移行しようかと計画しておりまして、その際ブログのカスタマイズを行ったりする度に(安い低スペックなVPSでは)再構築に何十分も待たされるんだろうな、と考えていたことから、WordPressへと移行したというわけです。

作業工程

1.MovableTypeのブログデータをエクスポートする。

MovableTypeにはブログデータをエクスポートする機能が標準で備わっていますが、今回はこれを使いません。一度この機能を使って移行してみたのですが、ブログエントリの「タグ」が移行されませんでした。

そこで

MovableTypeからWordPressに固定リンク込みで完璧に移行する方法を参考に、一旦MovableTypeのデータをXMLで書き出してそれを利用することにしました。

2.古いブログの画像データなどを別のディレクトリに移動

私の環境では、今までMovableTypeで扱ってきた画像などのファイルは全て/blogディレクトリ以下の様々なディレクトリに保存されているのですが、この/blogディレクトリを/mt_oldに改名します。と同時に、中にある画像以外のファイル(MovableTypeが生成したhtmlファイルなどは全て削除します) 本当はこのディレクトリを名称変更せずにそのまま使いたかったのですが、このディレクトリ内部にMovableTypeが生成した日付などのフォルダが存在するとWordPressで不具合が発生したので思い切って別ディレクトリに移動しました。

3.MovableTypeからエクスポートしたXMLデータ内で、画像などのメディアファイルにリンクしている部分を新しいディレクトリのパスへと置換する。

1の工程でエクスポートしたXMLファイルをエディタ等で開き、href=”hogehoge/blogやsrc=”hogehoge/blogとある場所(以前のブログの画像などのパス等)をhref=”hogehoge/mt_oldやsrc=”hogehoge/mt_oldに置換します。

4.XMLファイルをWordPressへインポート

画像パスの置換さえ上手くできていれば、先ほどのXMLファイルをWordPressへインポートするだけで既にブログとして機能するようになりますが、パーマリンクなども維持したいという場合にはもう少し作業が必要です。

5.パーマリンクの設定

私の場合は、以前MovableTypeで使用していたパーマリンクの書式に則って、以下のように設定しました。

 

6.カテゴリのスラッグを再設定

MovableTypeからインポートすると、カテゴリのスラッグは引き継がれずカテゴリ名のままになってしまいますので、これを修正します。 カテゴリが多数有ると面倒ですが、手作業でやらないといけません。

 7.カテゴリアーカイブのパーマリンクから「/category」を削除

MovableTypeの時には、カテゴリアーカイブのパーマリンクは「/blog/categoryname/」となっていましたが、WordPressの場合ですと「/blog/category/categoryname/」のように、「category」という文字が途中で入ってしまいます。そこで、MovableTypeの時のパーマリンクと互換性を持たせるためにこの部分を消してやります。それには「WP No Category Base – WPML compatible」というプラグインを使います。

WP No Category Base – WPML compatible

 8.問題点

以上の作業で、MovableTypeのブログをWordPressに移行することはできましたが、若干の問題が残ります。
MovableTypeで作成したブログのエントリのパーマリンクにハイフン「-」が含まれていると、WordPressにインポートする際にアンダースコア「_」に変換されてしまう事があります。(変換されない場合もある)

私のブログの場合はアクセス数も少なく、ソーシャルブックマークなどからもあまりブックマークされていませんので、そのまま放置して、Googleに再インデックスしてもらうのを待つことにしました。

9.移行後はやはりアクセス数が激減

パーマリンクのハイフンがアンダースコアに変換されてしまう問題のおかげで、404 Not Foundが大量に発生し、Googleのウェブマスターツールを見ると大量の404エラーが記録されていました。当然、アクセス数は5分の1まで激減! それでもこのブログはアクセス数の減少はそれほど致命的ではないので再インデックスを気長に待つことにします。

 移行を終えての感想

やはり、ブログをあれこれいじくったあとに再構築をしなくても良いというのは快適です。また、画像などのアップロードがドラッグ&ドロップで行えるようになったので、時々ではありますが画像を多用する当ブログでは編集作業も楽になるのではないかと思います。

ちなみに、移行後「WordPress Super Cache」というプラグインを入れて、負荷を少しでも減少させるようにしてみました。

 

 

.NET FrameworkのBeginGetResponseメソッドが実行中のスレッドをブロックしてしまう件


数日前の事ですが、当サイトで公開しているDMMアフィリエイトの商品リンク作成ツールの利用者の方から「今までに比べてリンクの作成に非常に時間がかかるようになった」とのご報告を頂きました。

今までは遅くても数秒以内に作成できていた物が、早くても10秒以上かかるというのです。

こちらではしばらくプログラムの変更は行っていませんでしたので、単にDMMのサーバーが重くなっているのではと考えていましたが実は完全に私のミスでした。

何が原因だったのか

当サイトのDMMアフィリエイトのリンク作成ツールでは、開発言語としてC#が用いられています。つまりは、.NET Frameworkの機能を利用して実装されているということです。

プログラム中では、ユーザーの問い合わせに応じてDMMのサーバーから実際に商品情報と商品パッケージ画像を取得するのですが、この時に.NET FrameworkのBeginGetResponseメソッドを用いています。実はこのメソッドにちょっとした問題がありました。

このメソッドはインターネットリソースの非同期要求を開始するメソッドであり、通常このメソッドが呼ばれた瞬間に、要求の完了・未完を問わずに一瞬で呼び出し元に制御が返ってきます。

ところが、条件によってはBeginGetResponseメソッドから制御が帰らずにスレッドが長時間ブロックされたままになってしまうことがあります。私のツールがリンクの作成に非常に時間がかかるようになったのもこれが原因でした。

どんな条件の時にスレッドがブロックされるのか

例によって、海外サイトを検索していたら次のサイトを発見しました。

webrequest.begingetresponse is taking too much time when the url is invalid
https://stackoverflow.com/questions/1232139/webrequest-begingetresponse-is-taking-too-much-time-when-the-url-is-invalid

要約するとインターネットからのリソースの取得は非同期的に行われるけどDNSの解決なんかは内部で同期的に実行されるから、無効なURLなんかを指定してDNSの解決に失敗したりするとスレッドがその間ブロックされてしまうとのこと。

ところが。
私のプログラムでは無効なURLは指定していませんし、そもそもDMMの商品URLに通常のブラウザからアクセスするとあっという間に結果が表示されます。

しかし、同時にとある事を思い出しました。

実は数日前にApacheの実行ユーザをWindowsサービスのデフォルトユーザから、セキュリティをガチガチに固めた「Apache」というユーザ変更しました。そして改めて検証してみると、Apacheをデフォルトユーザで起動した場合にはリンク作成ツールは今まで通りの速度で動作するのですが、ユーザを「Apache」に変更すると10秒以上の遅延が発生するのです。

ひょっとして、ユーザ「Apache」のインターネット接続設定がおかしいのでは?と思い、ユーザ「Apache」でログオンしていみたところ・・・。

容疑者発見!

internetoption.png

「インターネットオプション」を開いてみたところなぜか「設定を自動的に検出する」というチェックボックスがオンになっていました。物は試しにこのチェックボックスをオフにして再度リンク作成ツールをテストしてみると、見事に遅延は解消されました。犯人はおまえだったのか。

参考までに、なんでこのような現象が起きるのかを調べてみたのですが、マイクロソフトの英語版公式リファレンス によると、こんな記述がありました。

The BeginGetResponse method requires some synchronous setup tasks to complete (DNS resolution, proxy detection, and TCP socket connection, for example) before this method becomes asynchronous. As a result, this method should never be called on a user interface (UI) thread because it might take some time, typically several seconds. 

要約:このメソッドは非同期状態になる前に、いくつかの同期タスク(例えば、DNS解決、プロキシ検出、TCPソケット接続等)を完了する必要があり、場合によってはそれらの同期タスクには数秒を要するため、このメソッドはUIスレッドから呼び出されるべきではありません!

 なお、日本語版のリファレンスには載っていませんでした・・・。


まとめ

 というわけで、どうやらスレッドをブロックしている要因はDNS解
決だけではなく、プロキシ検出なども含まれるため、「設定を自動的に検出する」オプションにチェックが入っているにもかかわらず設定の検出に失敗したり時間を要した場合には、その間スレッドはブロックされてしまうっぽいです。


 ところで、デフォルトでは「設定を自動的に検出する」はオフになるはずなのですが、なぜオンになっていたのでしょうね。