最終的にSharkSpaceに決めた理由は２つ。

• ブログの表示速度が速い。さくらとDreamHostと比較しても一番速かった。
• 一生涯有効の50%オフのクーポンがあり、1年以上使う事を視野に入れると、USD53.70/年と安かった。

「ブログの～」と言うのは、一応僕のブログの、です。テーマファイルや使用プラグイン等が人それぞれ違うので、一概には言えないと思いますが。値段は今のレートで換算すると約4856円。もしも今後円安ドル高に転じ、1ドルが100円になったしても、5370円。さくらインターネットの5000円/年とほとんど同じです。

僕が気にしていたSharkSpaceのイマイチな点は以下のようにして解決。

メインドメインがpublic_html直下に固定されるのは、メインドメイン用に新たにドメインを取得して、SharkSpaceのサポートにメインドメインの変更手続きを取りました。一応、前から取ろうかなぁと思っていたドメインなので、完全な捨てドメインではありません。手が空いたらちょっとそのドメインでちょこちょこっとした事があります。ドメイン名はそれまで秘密。

FTPが遅い件は、HiroKwsさんに教えていただいた通り、圧縮してアップロードするのが非常に快適だと分かりました。サーバ管理画面のcPanelは相変わらず使いづらいのですが、その機能の１つである「ファイルマネージャー」が意外や意外、使いやすいんです、これが。圧縮と解凍、ダウンロードやアップロード、ファイルの削除や移動、がサクサクとできます。この点に関してはDreamHostよりも良かったですね。あと、DreamHostの場合だと、違う画面で一度開いて、また専用のログインとパスワードが必要ですが、SharkSpaceだとcPanelから一発で開くので使い勝手も良い。SSHのシェルログインは今後試してみようと思います。

と言うわけで、1週間半前くらいにDreamHostからSharkSpaceに戻ってきました。このまま、少なくとも1年は使い続ける予定です。

ただ１つ今後に少し気がかりなのは、サポート及びチケット。チャットのサポートの返答が、こちらが質問した事と少し違う内容で帰ってきたこと。そして、WP-DB Managerとの相性（?）に問題があってチケットを切った時、このブログの管理画面へのadmin ID及びパスワードを聞いてきたこと。結局僕がごそごそいじっている間に急に、何故か、解決しちゃったので良かったものの、いくらなんでもIDとパスワードを唐突に聞いてくるかな。そこらへんがなんかちょっと心配ではありますが、たまたまイマイチなサポート担当さんに当たっただけかもしれません。この点は他のレンタルサーバ会社でもありうる事だと思うので、様子見です。

アップロードの速度計測の為にアップしたファイルはRAWファイル（.PEF）で、サイズは14,903,491バイト。使用したFTPソフトはWinSCPです。それぞれのサーバで、外部公開フォルダのルートにファイルをアップロード。そしてアップロードしたファイルをローカルにダウンロード。この２つの速度を測りました。今回はそれぞれ1回ずつです。ちなみに、我が家の通信環境はフレッツ光です。

結果はこの表の通り、ぶっちぎりでさくらインターネット。SharkSpaceとDreamHostでは、アップロード速度に差はほとんどありませんが、ダウンロード速度ではDreamHostの方が約3倍速いです。ただし、SharkSpaceのダウンロード速度はFTPがSFTPに負けているので、たまたまだった可能性が無いとは言い切れません。

ともかくこれで、国内サーバには当然勝てないにしろ、海外サーバでもそれほど遅い訳ではないのがわかりました。やはりWordPressのコア・フォルダのように大量のファイル及びフォルダを一度にアップロードするのがよくないんですね。よくない、と言うか、それだけサーバに大きな負荷をかけることになる、と言うことでしょうか。

ただ、アップロードはともかく、ダウンロード＝バックアップ、だけは定期的にやっておきたいので、FTPソフトを使わないで行う手を検討した方がよいかも。

ちなみに…

もしかして先日檄遅だったのは、週末だったから？米国では感謝祭の連休だったから？とも思い、もう一度「WordPressのコア・フォルダを一度にアップロード」を試みました。

結果はものの見事に返り討ちにあいました。速度は先日でていたのと全く同じです。そして例の如く途中でエラー。残念。

WP Super ChacheはAutomatticの社員の一人でもあり、WordPressの主要開発者の一人でもあるDonnchaが開発したプラグインです。アクセスされたページのキャッシュ（htmlファイル）を作成し、ページのロード時間を短くすると共に、サーバへの負担を軽くする事を目的としたプラグインです。おそらく国内外問わず、アクセス数が大きいWordPressブログは必ずと言ってインストールされているんじゃないでしょうか。

そんな凄いプラグインですが、実は僕はまだ試して見たことがありません。DreamHostが、一定のアクセス数を記録するようになったら「WP Super Cacheを入れてくれ～！」と言ってくるそうなので、せっかくの良い機会だから、さくらインターネットとSharkSpaceと共に、先日の結果と比較してみようと言うわけです。

比較方法

1. 各サーバにて構築してあるwaviaeiブログにWP Super Cacheのプラグインをインストールしてオン。
2. 昨日の比較テストでも用いた/category/photographyと/category/diaryの2ページを数回アクセス。
3. ページのソース及び管理画面の「キャッシュされたファイルのリスト」にて、各ページのキャッシュが作成された事を確認。
4. 昨日の比較テストと同じ計測方法で合計ページロード時間を計測する。

結果

まずは結果の表です。

リクエスト数と合計ページサイズは、昨日と比較してほぼ同じですが、微妙に違います。今回に比較用には許容範囲の誤差とします。

さて、合計ページロード時間の平均の比較ですが、SharkSpaceはphotography、diary共にほとんど変わらないのに対し、DreamHostは約1.4から1.9秒弱、さくらインターネットは約0.6から0.8秒早くなっています。特にDreamHostは、少なくとも今回のテスト中では確実に時間が短縮されています。DreamHostは「インストールしてくれ！」と言ってくるだけあって、WP Super Cache用のチューニングか何かをしているのでしょうか？

逆にほとんど短くなっていないどころか、/phographyではさらに時間が掛かってしまったSharkSpaceですが、他の２つとは違い、そもそも動作が速いApache moduleモードでPHPを動かしている為、それほど効果は無いといったところでしょうか。しかし、僕のブログはアクセス数がとても少ないので、WP Super Cacheの本領を発揮できていないとも推測します。キャッシュを作成する目的の１つとして、プラグインのサイトでも書かれているのですが、サーバの負担を軽減して過剰なアクセス負荷、特にDiggの上位なんかにリストアップされた時など、によるサーバーダウンを未然に防ぐ効果があるとしています。ちょっと僕のところでは検証できないんですがw

DreamHostにWP Super Cacheを導入すると、少しはSharkSpaceのWP Super Cache導入前のロード時間に近づくのですが、やはり1歩及ばずと言ったところ。

今回もグラフを作ってみました。

まとめ

• やはりWP Super Cacheを導入する効果は、小さくてもあるようである。
• 特にPHPがCGIモードとして動いてるサーバにおいて効果がある。
• サーバによっては、WP Super Cacheを意識したチューニングを施している、もしくは単純にスペックの違いでその効果が違う可能性がある。

ただし

• 今回の比較はアクセス数が小粒程にちいさなWordPressブログなので、WP Super Cacheの性能とサーバ自体の性能も含めた、真の実力が問われるであろうアクセス数が高いブログサイトの結果ではない。
• あくまでブラウザの合計ページロード時間で、厳密な意味でのサーバへの負担の値ではない。時間の短縮とサーバへの負担軽減度は、単純な比例的な関係にあるとは思わないので、そこらへんの結果が逆に知りたい。

使い勝手はともかく、やはりWordPressブログのロード時間を短くするには、PHPがApache moduleモードで動いているサーバの方が良いということでしょうかねぇ。SharkSpaceがそれにあたりますが、それ以外だと、Host GatorにBlueHost、、、う～ん。

比較に利用したのはSite24x7 – Online tool to analyze webpage and its objectsと言うサイトです。このサイトは指定したURLのページをダウンロードするのに掛かる時間を結果として返してくれます。結果をグラフにもしてくれる他、リクエスト数やサイズ等も表示してくれるので非常に分かりやすいです。

比較したのは、写真の表示が比較的多いカテゴリーのPhotographyのアーカイブページと、テキストメインの記事ばかりのDiaryカテゴリーのアーカイブページです。ホーム（トップ）のページは、DreamHost以後に記事を投稿した為、表示される内容が違うので、比較の対象から外しました。

今回の比較の注意点としては、ロードされるスクリプトが微妙に違う事です。DreamHostの方ではAkismetの他、GoogleAnalyticsやWordPress.com等のアクセス解析プラグインをオンにしています。

まぁようするに、厳密で完璧な比較テストではないと言うことです。しかし、個人ブログをサクッと比較するには必要十分だと思ういます。

さて、僕の感覚ではSharkSpaceが一番早くて、ワンテンポ遅れてDreamHost。一番遅いのがさくらインターネットです。これをきちんと数値で比較し、確認しようと言うのが今回の目的ですが、結果を先に言うと、まさしくその通り、でした。

結果

まずは結果を表にしてみました。相変わらず手抜きで、エクセルの表を画像貼り付け（汗）

まず、留意点として、SharkSpaceのリクエスト数だけ少ないです。合計ページサイズもしかり。理由はサイドバーの最近のコメントのGravatarです。SharkSpaceでは前回の記事で書いた通り、一部のプラグインの設定を管理画面から変更できない問題があります。最近のコメントの表示で用いているGet Recent Commentsがちょうどそれにあたるので、SharkSpaceだけGravatorを表示できないのです。

さて、合計ページロード時間5回分の平均ですが、/photography、/diary、共にSharkSpaceが他の２つを圧倒しています。飛び抜けて早いです。前述したGarvatarを表示できてもおそらく一番早いと思います。

もうちょっと分かりやすくするためにグラフにしてみました。

一番早いSharkSpaceを基準とすると、DreamHostはその約2倍～2.8倍、さくらインターネットは約2.9倍～4.5倍の時間が掛かっています。DreamHostから比べるとさくらインターネットは約1.4~1.6倍の時間が掛かっています。正直言うとDreamHostはもうちょっと早いかなって思っていました。

/photography対/diaryで比較すると、当たり前ですが、/diaryの方が全てのサーバで早いです。最近アップしている写真は全てFlickrにアップしているので、実はSharkSpaceとDreamHostの方がFlickrのサーバに物理的に近いので、その影響が結果に反映されるのでは、と思っていましたが、そうでもないみたいですね。

それよりも興味深いと思ったのは、/photographyと比べて、/diaryがどれだけ早くなるか、です（緑の矢印）。全てのサーバにおいて同じくらい早くなると思っていたのですが、そこにバラツキがでています。SharkSpaceは約1秒も早くなり、Dreamhostは0.8秒。なのに、さくらインターネットは0.5秒。

まとめると…

結果を纏めるとだいたいこのようになります。

• やはりSharkSpaceが圧倒的に一番早い。これはPHPがApache_moduleモードで動作しているのが大きな要因と思われる。
• PHPがお互い同じCGIモードなのに、DreamHostが約2倍近く早いのは、Fast CGIの影響が大きな要因と思われる。
• ただし、サーバスペックの違いやデータベース周りの仕様はそれぞれ少し違うはずなので、その影響もあると考えられる。
• 処理が早いサーバであれば、大きな画像の有無で、ページロード時間は比較的大きく変わってくる。大きな画像がない方がもちろん早い。しかし、処理があまり早くないサーバでは、比較的小さな影響しかない。
• Flickrのサーバへ画像を読み込みに行くことは、レンタルサーバがどこに有るかはそれほど大きな問題点ではなさそう。

サーバ周りの事や、PHPやMYSQL最適化に詳しい方であれば、突っこみどころ満載の比較かと思うので（汗）、是非コメントでお願いします！

（注：091130にWP Super Cacheをインストールしています！）それから、SharkSpaceにアップしたwavaieiを体感されたい方、URLは次の通りです：http://72.11.144.84/~waviaeic/waviaei/category/diary/

じつは、taiさんに言われているのですが、DreamHostはある程度アクセス数が増えてくるとWP Super Cache入れてね、って言われるそうです（笑）。実はさくらインターネットにいた頃も導入しなかったので、いい機会です。３つのサーバ全てにWP Super Cacheを入れて比較したいと思います。

• PHPがCGIモードの為WordPressの動作が少しもっさりとしている。
• MYSQLのデータベースが１つしか作れないので、WordPress等のCMSを１つ以上インストールする時に面倒。
• PHPやMYSQLのバージョンアップの対応が早くない。

特にこれら３つは是非とも今後改善、対応してほしいところです。しかし、

• （少なくとも僕は）メールでのサポート対応の反応が早いし、きちんと対応してくれる。
• 時間は掛かったが、最終的にはPHPもMYSQLも両方ver.5にバージョンアップしてくれた。

といった点を含め、値段相応のサービスとは言え、最低限やらねければいけない事はやっている、との感想を僕は持っています。

一時期PHPがCGIモードで運営されているが為に、大量の負荷が掛かれば発生する「503 Service Temporarily Unavailable」問題と「403 Forbidden」問題が、今年の4月から5月頃頻繁に発生していました。サポートに、僕のブログはアクセス数の小さなブログなので、本当にそんなに負荷が掛かっているのか見て欲しい、と問い合わせると、制限を少し解除してくれました。それ以降同様の問題は発生していません。

しかし、今回、この5年間借りてきたさくらインターネットのサーバから、別のサーバにお引っ越しする事を、本格的に検討する事にしました。具体的には海外のサーバです。日本国内だとヘテムルが良さそうなんですが、個人で使うには月々1500円はちょっと高い。特に僕のブログはそんな人気ブログでもないですし。逆にCORE SERVERは安いですが、あんまり良い評判は聞かないし、当たり外れが大きいようなのでパス。海外は安くて、機能も豊富で、MYSQLのデータベースも複数使えるし、PHPもCGIではなくApacheモードで動いているので早い。そんな評判を良く見かけるので、海外に的を絞りました。検討したのは次の7つ。

• JustHost
• HostMonster
• FatCow
• DreamHost
• BlueHost
• Host Gator
• SharkSpace

JustHostとHostMonsterは月々5ドル以下の超格安レンタルサーバです。しかし、やはりその分やすいなりの理由はあるようで、人によっては結構不満が、特に処理の遅さや不安定さ、があるようです。なので却下。他の５つはそれぞれ契約するプランによって若干違いはあれど、どれも似たようなものです。大容量のサーバスペースと転送量。無限数のMYSQLデータベース。複数のドメイン利用。等々。値段もどれも月々７ドルから9ドルくらい。DreamHostは最近不安定で落ちたりする事をちらほら見るようになったのと、PHPがCGIモードで動いているのがマイナス点。BlueHostは一番高い。FatCowはこの中では一番機能が劣る。

そんな感じで最終的に絞ったのはHostgatorとSharkSpace。SharkSpaceは永久的に50％オフとなるクーポンを発見！1年契約だと月々8.95ドルなのが半額の約4.5ドル。それに、サーバの場所も東海岸、西海岸、中央、と選べられる。と言うことで、まずSharkSpaceを試すために契約することとしました。

さくらインターネットはとりあえず1ヶ月契約で延長。

さて、SharkSpace（シャークスペース）ですが、22日の夜に使い始めたのですが、これがまた色々とくせ者だと言うことが分かりまして。。。（続く）

PHPMyAdminを使用してエクスポートしてきたSQLファイルを、ローカルPCにインストールしたXAMPPにインポートすると、文字化けしまくりで大変だった事が以前ある。なので、データベースのインポートとエクスポートが必要となる今回のバージョンアップ作業は正直見送りにしようかと思ってました。

が、注意箇所および詳しい手順がかかれている記事を参考に、ビールを飲んだ後の勢いで「えいやっ」と昨晩やってしましました。参考にさせていただいた記事は次の３つ。ありがとうございます。

• MySQL 4 から 5へ : dogmap.jp
• さくらインターネットMySQL5化 (nni’s blog)
• HashiMのたわごと(？) : 2009年3月14日(土) – MySQLを4から5へ

手順

僕はコマンドを使ったMySQLの設定方法がよく分からないので、それ抜きでやってみました。

1. DBのエクスポート

まずはさくらのコントロールパネルからPHPMｙAdminへログインし、DBをエクスポート。PHPMyAdminへは文字コードに気をつける。WordPressの場合はUTF-8。この記事を参考にして、「構造」欄の「DROP TABLEを追加」と「IF NOT EXISTSを追加」にチェックを入れ、圧縮無しのファイルとして保存する。ちなみに僕の場合15.7MBで、うち約11がjprelatedでした。

次のステップで、このエクスポートしたDBファイル（sql）をちょこっと編集したりするので、コピーを作成するなどして、バックアップしておくのが良いと思います。

2. エクスポートしたDBファイルの編集

データベース名がhogeとだとすると、エクスポートしたsqlファイルには先頭に「DB名hogeのデータベースを作成する」との内容の命令文が1行書かれています。しかし、さくらでDBを作成すると自動的のこのhogeのDBが作成されます。このsqlファイルをこのままインポートすると「DB名hogeのDBはもう既にあるよ！」とエラーが発生してインポートがストップしてしまいます。そこでこの命令文をコメントアウトしてやります。

テキストエディタでsqlファイルを開きます。この時にUTF-8で開く事に注意してください！

上から20行目あたりにある

[sql]CREATE DATABASE `hoge`;[/sql]

を以下のようにコメントアウトします。

[sql]– CREATE DATABASE `hoge`;[/sql]

sqlを保存して閉じる。

3. エクスポートしたDBの圧縮

PHPMyAdminのインポート画面にて、SQLファイルをアップロードしてインポートできる機能があります。これを使ってインポートするのですが、実は8MBのサイズのファイルまでしかインポートできません。そこでbzip2と言う形式に圧縮してアップロードします。エクスポートしたSQLファイルが8MB以下だと圧縮する必要なし。圧縮しても8MBを超えるようだと他の手段を。

bzip2の公式サイトから、Windows用の「Executables for 1.0.5」をダウンロード。これを適当な場所に保存します。ここではCドライブの直下としておきます。また、ファイル名が長ったらしいのでbzip2.exeに変更しておくと良いかも。

必要はありませんが、一応先ほどエクスポートしてきたSQLファイルをbzip2と同じ場所に移動しておきます。コマンドプロンプトを立ち上げ、Cドライブ直下に移動してから次のコマンドで圧縮開始。

C:\bzip2.exe C:\waviaeimysql4.sql

bzip2.exeの後にスペースを１ついれて、圧縮するファイルをフルパスで入力します。Enterを押すと圧縮が始まり、数秒で完了します。

4. MySQL4のDBの削除とMySQQL5のDBの作成

さくらのコントロールパネルに戻ります。PHPMyAdminは閉じておいてください。

「データベースの設定」画面にある「データベースの削除」をクリックしてください。確認のダイアログが出てくるのでOKを押すと、DBが削除されます。これでもう後戻りできません～！

「データベースの設定」画面に戻り、今度は新しくDBを作成します。このときにバージョンの選択を5.1して作成します。接続パスワードの設定を求めらるので入力。以前のDBと同じでもいいですが、一応変えときました。

これで新しくMySQL5のDBが作成されました。データベースサーバが変更されている点も注目してください。おそらく以前のDBよりも数字が大きいDBになっていると思います。

5. DBをインポートする前のMySQLの設定

PHPMｙAdminを開きます。データベース名がhogeだとすると、画面左側のサイドバーからhogeを選択します。データベースhogeが表示されます。作成されたばかりなので中はにはまだ何も入っていません。

「操作」タブを開きます。そして一番下にある「照合順序」を変更します。sjisになっていると思いますが、ここをエクスポートした時のDBの照合順序に合わせます。WordPressの場合、utf8_generalciです。実行を押して変更完了。

6. DBをインポート

続いて「インポート」タブをクリックします。「インポートするファイル」の「参照」から、先ほど作成したbzip2のファイルを選択。実行して、問題なければOK！

7. wp-config.phpの編集

この時点で一度ブログをブラウザで開いてみてください。「データベースへの接続を確立できませんでした～」云々と表示されるはずです。さくらのMySQL4から5へのアップグレードでは、いったん4のDBを削除するため、DBが変わってしまうからです。

サーバにアップしているwp-config.phpの「DB_HOST」を新しいDBに書き換えます。もしパスワードも変更した場合は「DB_PASSWORD」も書き換えます。

編集したwp-config.phpファイルをアップロードして、再度ブログにアクセスすると、今度はちゃんと表示されるはずです。

8. チェック

すべてが問題なく終わって、元通りに表示されるようになったら、一応どこか変なところがないかチェックしておきましょう。特に過去記事の文字化けです。僕はあまりつかわないのですが、「～」（＝波ダッシュ）をよく使う方は「波ダッシュ問題」と言うのが存在するそうです。その場合はwokamotoさんの記事を参考にしてForce Wave Dashプラグインを使用する等して解決してください。

しかしその原因と対策方法がようやく分かりました。

• さくらのレンサバではlibxml2のバージョン2.7.2がインストールされている
• このver.2.7.2にバグが有る
• このバグがWordPressのXML-RPC投稿との間に問題を引き起こす

というものでした。libxml2のバグはver.2.7.3で解消されているそうなのですが、レンタルサーバなので勝手に新しいバージョンをアップすることはできません。

ということで結局WordPress側での対応となるんですが、この問題を解消するプラグインがリリースされているので、これをあてればOK。

この問題はチケット#7771 (XMLRPC api stripping leading angle brackets) – WordPress Tracとしても取り上げられていますが、そもそもこの問題はlibxmlにあり、また、その最新版を利用していないサーバ側の問題であると言う事から、WordPressコアでの対応よりも、必要な人だけインストールして利用できるようプラグインの方が良いのでは？と言うことでプラグインのリリースとなったようです。

さくらインターネットのレンタルサーバを利用している人は、とりあえず入れておくとよいかもしれません。一応バージョンアップしてもらう要望をだしてみます。

以下、参考になった記事です。

• うすよごれ。 – （また）ブログエディタ替えたんだぜ…そしたら、
• watermint.org » Blog Archive » WordPressのXML-RPC投稿でHTMLタグが消えるのはlibxml2のバグ
• wigglin’ bloggin’ » WordPressのXML-RPC投稿でHTMLタグが消える問題
• 投稿するとタグが消える | appling weblog
• さくらサーバへのXML-RPC投稿不具合を「LibXML2 Fix」で回避 | 本質思考道場