ロリポップからwpXクラウドへの引っ越しとブログ最適化

  • このエントリーをはてなブックマークに追加
  • 0




8月くらいに、独自ドメインを取ってwordpresでサーバー運用しているこのブログのサーバーをロリポップからwpXクラウドに移行させた。wpXとはwordpressの運用に特化した高速レンタルサーバー、というのが売り。レンタルサーバーとクラウドのサービスを展開している。以下のリンクはレンタルサーバーの方だが、上の方のボタンをクリックすると、、、

以下のような薄い青のクラウドのページが出てくる。私が契約をしたのはこっちの方。
WordPress専用の高速クラウドサービス_wpX_ダブリューピーエックス_クラウド

ブログのトラフィックによって、グレードを変えてスペックアップできると言うのが売り。私のブログのような個人目的だとグレードAで十分なので、月額500円の契約。ただ、ドメイン1つ=wordpressを1つしか運用できない、という限定条件になる。
2

今回初めてサーバーの移管というのを自分でやってみたが、慣れればなんて事無い作業なんだろうが、かなり困難だった。なにせ、決心したのは2月で、サーバーのお試し契約もしたのに、途中、大変すぎて諦めて数ヶ月放置、そしてやっと完了したのが8月というくらい大変だった。あまりに大変で1万円払うから、だれかやってくれないか、とまで思ったくらいだった。またこれは移行先のwpXの癖のせいもあるのかもしれない。wpXはWordpressのフォルダの下にあるwp-conetentsだけ移行させるという、ちょっと特殊な方法を取るため、データは移行しているのに、ドメインがうまくスタートページに飛ばなかったりして、移行させてからhtaccessをいろいろ書き換えてやっと飛ぶようになった。頼りのGoogle先生を検索してもwpXサーバーの引っ越しの話は出て来ても、wpXクラウドへの引っ越しの話はあまり出て来なく、色々な人の情報をつなぎ合わせてなんとか引っ越しできた感じだった。

ロリポップからサーバーを引っ越した理由を上げてみると、大きな理由はロリポップではサーバーダウンがしばしば起こっていたからだった。Wordpressのプラグインで色々な便利な機能が含まれているJetpackとプラグインがあって、それにはサーバーが落ちるとメールをよこしてくるサービスがあり、これが数日に1度、たった数分ではあるが、サーバーが落ちた、という連絡をよこすようになっていたからである。気がつかないうちにロリポップのサーバーにより、自分のblogが落ちていることがあったらしい。

たしかに、クリックしたときの読み込みも何となく遅い気がしたし、コントロールパネルであるダッシュボードを開くときももっさりした感じがする。ロリポップは安いし、導入としては難しさを感じさせないようなポップなスタイルでよかったのだけど、もう少し安定したサーバーがほしいな、と言うのが引っ越し理由だった。

そしてwpXクラウドが月500円だし、安そうだからいいかな、と思って契約して、使ってみること3か月ほどで今(11月)に至っている。しかし、ここまで来るのにもいろいろあった。まず、当初の移転理由であるサーバーダウン、これはしなくなったのでロリポップよりはwpXのほうが安定しているのだろう。しかし、移転の時、ブログ投稿記事情報が含まれるmySQLデーターベースも移管しなければならないが、その容量を見てみてびっくり。気が付いたら307.6MBとなっていた。移転先のwpXクラウドの契約はグレードAで、MySQL容量は150MB以内というガイドラインが出ており、どう考えても現在は容量オーバー状態。

しかも、どうもCounterize、つまりCounterize IIのプラグイン関係のSQL容量だけで約170MB。つまりこのブログのMySQLの容量の半分以上をこのCounterize IIのプラグインで食っている、ということになる。ある意味異常値だと思うので、Counterize IIには見切りをつけることにした。
sql2

Counterize IIはこのブログのどこに使っていたのかというと
Total:1076624
Today:1133  Yesterday:2422
現在の訪問者数は12人です

右上のこのカウンターの部分である。更にCounterize IIにはダッシュボード画面でアクセス解析やらブラウザ解析がついているのだが、多分そのデーターベースが容量を取っているようだ。正直そっちは全く見ておらず、カウンターだけあればいいので、カウンターのプラグインを新たに探さなければならない。

検索して代わりになりそうなプラグインはcount per dayかなと思い、早速ダウンロード。訪問者数=ユニークユーザー、閲覧者数=PVという違いで、これまでのcounterizeはPVしかカウントしてなかったようなのと、いまいち基準がわからなくなってしまったので、訪問者数=Google Analyticsユーザー数、閲覧者数=Google Analyticsのページビュー数を初期値として使用スタートした。

実はCounterize IIもデータベースを初期化とやったらMySQLの総データ容量は140MBにがくんと減ったのだが、カウンターまで吹っ飛んでしまう試用なので、やはり継続利用はしないことにした。

counter per dayも立派な解析ツールがついて来ているので、データベースの容量圧迫には注意しなければならない。
php4

しかし、スパムデータを削除するクリーンアップ機能がついていたり、
php2

カウンター情報を維持したままの古いデータの整理も可能なので、データベース量のコントロールという意味ではCounterize IIよりいい感じがする。
php3

MySQLを最適化し、しばらく3か月ほど、そのままで運用していたが、ここ最近、ダッシュボードでの作業で503エラーを頻発するようになった。ここ2か月ほどあまりブログを触ってなかったので、気が付いてなかった節もあるが、なにせ、何をするにもダッシュボードがのろいし、肝心なところで503エラーなのである。高速が売りのwpXじゃなかったの?と疑問を持たざるを得ない。まず、プラグインのUpdateも3つとかまとめてやると503エラー、プラグインを追加したり削除したりしようとプラグインを開こうとするとレスポンスが戻ってこないで挙句の果てに503エラー、という感じ。

一般的にwpXは独自の機能で高速化しているため、キャッシュプラグインなどは入れると弊害がでるということであるので、キャッシュ系プラグインは入れていないのだが、それでも503エラーが頻出。サポートに問い合わせても以下の回答。

▼上限を設けているリソースの例
——————————————–
・PHPやCGIプログラムの実行、FTP接続など
 全ての動作における「同時稼動数」
・ご利用アカウント内のファイルに対して
 一度にアクセス可能な「同時接続ファイル数」
・MySQLデータベースに対しての「同時接続ユーザ数」
——————————————–
これらのリソースが上限に達しますとWEBサイトへのアクセスの際に500エラーや503エラーが表示されます。

しかし、ロリポップでもプラグイン複数個を一挙にアップデートしてもこけることはなかったけどなー。割と通常使用であるのにダッシュボードで503エラーが出続けるのは非常によろしくない。ということで、wpXに移行したことで解決したかと思ったらサーバー問題再燃。

またブログ自体も重いようでブログ表示を無料で計測するGoogleのPageSpeed InsitesPingdom Website Speed TestGTmetrixで速度表示をしたところ、Jetpackがかなり悪さをしていることがわかった。結果的にJetpackはプラグインから削除した。3つのサイトでの削除前・削除後の結果は以下の通り。

PegeSpeed Insites: 58/100点→70/100点。赤信号からオレンジ信号に改善したが、モバイルはまだ赤の58点。
Page

Pingdom: グレード68/100, ロードタイム5.46s、容量1.3MB→ グレード67/100、ロードタイム2.81秒、容量646kB。グレードがあまり変わらないのでグレードの意味が不明だが容量とロードタイムはかなり改善した。
Pingdom

GTmetrix:削除前の詳細の結果は記録し忘れたが、前後で変化があまりなかった。
GT

Jetpackは便利だっただけに削るのはもったいなかったが、重いのであれば致し方なく、削除。しかしまだまだよろしくない判定結果なので、改善作業の道は長いなと言った感じ。

ブログを運営するにあたっては、自分が快適に作業するための環境改善(ダッシュボードのレスポンスの高速性)と見てくれる人が快適であることが大事だと思うし、後者はSEO的にも大切だと思っているので、暇を見つけては改善できるように努めたいというところ。
(まずその前にたまった旅行記を書きなさいという問題もあるけれども)

Comments

応援よろしくお願いします!
にほんブログ村 旅行ブログ 女一人旅へブログランキングならblogram
にほんブログ村 海外生活ブログ サンディエゴ情報へ


  • このエントリーをはてなブックマークに追加