サーバーをXSERVERへ移転しました(お名前SD-01プランより)
2014/12/10
当サイトでは2014/08/28付けでお名前.comのSD-01プランのレンタルサーバーより、
XSERVERのX10プランへ一旦緊急避難的に引っ越しを行いました。
この引っ越しを行った経緯についてご紹介しておきます。
Google Web Masters Toolsクローラエラーの頻発
当サイトでは過去に何度もGoogle Web Masters Toolsの
クローラエラーが発生しておりました。
クロールエラーとページビュー、サーバー転送量ログのグラフを重ねてみると、
以下のような感じです。
※厳密には横軸は合っていないと思いますが目安です。
何となくアクセスが多い日にはクロールエラーも増えていますが、
そうではない日もエラーが出ています。
また、データベース接続エラーも過去によく表示されるようになっていました。
これまではPHPの設定を変更したりしながらずるずると延命をしてきたわけです。
原因がこれかは不明ですが、
最近はアクセスがジリジリと下がってるような傾向で、
このエラーも少なからず影響しているのが感じられるようになってきました。
これはもう緊急性が高くなって、タスクの優先度が最優先になってしまいます。
疑わしきは転送量の制限
共用サーバーだけに他のユーザーさんとの兼ね合いで、
エラーの出やすい日もあればそうでない日もあるのでしょう。
また管理者側で負荷調整を取っているのか不明ですが、
しばらくするとエラーが少し落ち着いたりすることもありました。
その為、エラーが出た場合でも、しばらくすれば消えるかな・・・と、
これまでの消えた事実から希望的観測をもっていた部分もありました。
しかし、上記のグラフの通り一向にエラーが改善されません。
転送量の確認
そこで、サーバーの転送量を確認してみるわけですが、
直近では1日当たり、20GB程度の転送量が発生しています。
当然、クローラのアクセスなどの頻度にもよると思います。
また、この1ヶ月ぐらいで転送量の削減のために、
中国のクローラアクセス(スパムコメント?)をバッサリとブロックしました。
それでも「1日当たり、20GB程度」のまま変わらない状況でした。
レンタルサーバーの事業者側では目安として月間の転送量を
レンタルサーバーの選定を目的として公開していることが多いのですが、
お名前.comのレンタルサーバーでは一切そうした情報を公開していません。
また、サポートに確認しても「お答えできない」と言う回答しか得られませんでした。
でも、おそらくこの辺りの「1日当たり20GB程度」が制限を受ける目安なのかもしれません。
ただ、転送量よりもMySQLなどの同時接続数などに起因している可能性もありますが、
サポートがそうした情報を提供してくれないので、まったく原因は分かりません。
そこで、できることと言えばApache Benchを見るくらいかなと思い、
ベンチマークを取ってみました。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 |
Microsoft Windows [Version 6.1.7601] Copyright (c) 2009 Microsoft Corporation. All rights reserved. C:>cd Apachebin C:Apachebin>ab -n 100 -c 10 http://algorhythnn.jp/blg/2014/05/09/au_point-to-au_wallet/ This is ApacheBench, Version 2.3 <$Revision: 655654 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Benchmarking algorhythnn.jp (be patient).....done Server Software: Apache/2.2.23 Server Hostname: algorhythnn.jp Server Port: 80 Document Path: /blg/2014/05/09/au_point-to-au_wallet/ Document Length: 540 bytes Concurrency Level: 10 Time taken for tests: 14.852 seconds Complete requests: 100 Failed requests: 19 (Connect: 0, Receive: 0, Length: 19, Exceptions: 0) Write errors: 0 Non-2xx responses: 81 Total transferred: 3798263 bytes HTML transferred: 3774724 bytes Requests per second: 6.73 [#/sec] (mean) Time per request: 1485.185 [ms] (mean) Time per request: 148.518 [ms] (mean, across all concurrent requests) Transfer rate: 249.75 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 55 93 23.5 90 264 Processing: 245 1149 841.8 990 4331 Waiting: 245 946 501.9 939 2751 Total: 335 1242 844.9 1075 4464 Percentage of the requests served within a certain time (ms) 50% 1075 66% 1325 75% 1435 80% 1581 90% 2135 95% 3567 98% 4003 99% 4464 100% 4464 (longest request) C:Apachebin> |
1秒あたりのリクエスト処理(29行目)は速いようで、6.73が出ていましたが、
何よりも痛いのが、、、
Failed requests: 19
リクエストを返さなかったのが 19となってます。エラーが出ていると。
さすがに、一定のエラーが戻るのでは他が早くても意味がありません。
そんなことから、まずはエラーを無くすためにも引っ越すこととしました。
XSERVERへの移行手順
XSERVERへの引っ越しの手順については、また追ってご紹介しますが、
まずはさらっと流れだけをご紹介しておきます。
テーブルデータ移行
今回はphpMyAdminを利用してテーブル単位によるエクスポートでsqlファイルを取得しました。
VaultPressによるバックアップを行っていますが、
VaultPressでは同一ドメインによる別サーバーへの移行が行えませんので手動になります。
あとは、作成したMySQLデータベースへテーブルごとにインポートしました。
ファイルの移行
ファイルに関しては一旦、VaultPressを利用してXSERVER上に
別ドメインを割り当てたサーバーディレクトリに対してリストアを行って、
サーバーファイルをコピーさせました。
その後、XSERVERにリストアされたファイルを正式なドメインディレクトリへ移動しました。
これはFTPによるアップロードよりも確実にファイルのリストアが行えたためです。
XSERVERへの移行後のApacheBench
XSERVERへ移行してHostファイルの書き換えを行って、
一時的に移行先に接続しApache Benchを実行しました。
なお、以下3パターンで試しましたが、
結局は「FCGI・APCが有効+XSERVERのMySQL」利用が体感的に早い印象だったので、
特に個性を出すことなくそのまま採用しました。
Apache Benchだけで言えば、
「3.FCGI無効+APCキャッシュ無効+XSERVERのMySQL」が一番レスポンスがいいようです。
キャッシュなのでこの辺はアクセスが増えてから威力を発揮するというものかなとも思います。
- FCGI有効+APCキャッシュ有効+XSERVERのMySQL
- FCGI有効+APCキャッシュ有効+KAGOYAのMySQLへ外部接続
- FCGI無効+APCキャッシュ無効+XSERVERのMySQL
それぞれのApache Bench結果をご参考までにご紹介しておきます。
1.FCGI有効+APCキャッシュ有効+XSERVERのMySQL
通常、何も考えずXSERVERの基本構成で利用する場合には、
この「FCGI有効+APCキャッシュ有効」設定でサイトを構成するでしょう。
MySQLもXSERVER上のMySQLを利用するものと思います。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 |
Microsoft Windows [Version 6.1.7601] Copyright (c) 2009 Microsoft Corporation. All rights reserved. C:>cd Apachebin C:Apachebin>ab -n 100 -c 10 http://algorhythnn.jp/blg/2014/05/09/au_point-to-au_wallet/ This is ApacheBench, Version 2.3 <$Revision: 655654 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Benchmarking algorhythnn.jp (be patient).....done Server Software: Apache Server Hostname: algorhythnn.jp Server Port: 80 Document Path: /blg/2014/05/09/au_point-to-au_wallet/ Document Length: 508322 bytes Concurrency Level: 10 Time taken for tests: 25.393 seconds Complete requests: 100 Failed requests: 0 Write errors: 0 Total transferred: 50855400 bytes HTML transferred: 50832200 bytes Requests per second: 3.94 [#/sec] (mean) Time per request: 2539.345 [ms] (mean) Time per request: 253.935 [ms] (mean, across all concurrent requests) Transfer rate: 1955.76 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 60 117 42.9 108 354 Processing: 1549 2313 698.5 2017 4895 Waiting: 421 764 450.6 550 2420 Total: 1670 2431 691.9 2143 4975 Percentage of the requests served within a certain time (ms) 50% 2143 66% 2365 75% 2781 80% 2924 90% 3494 95% 3818 98% 4756 99% 4975 100% 4975 (longest request) C:Apachebin> |
1秒あたりのリクエスト処理(27行目)は、3.94に落ちてしまいました。
しかし何よりも助かるのが
Failed requests: 0
いや、これが当たり前であって欲しいのですけどね。
2.FCGI有効+APCキャッシュ有効+KAGOYAのMySQLへ外部接続
「FCGI有効+APCキャッシュ有効」設定でサイトを構成するものとして、
XSERVER上のMySQLは外部接続は利用できませんので、
外部から接続ができるKAGOYAのMySQLを利用してどのくらいパフォーマンスが下がるかを確認しました。
本当は外部からアクセスできたほうが引っ越しも楽だし、
データをエクスポートするのも楽なので好みなのですが、
やっぱりレスポンスは大きく落ちるようですね。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 |
Microsoft Windows [Version 6.1.7601] Copyright (c) 2009 Microsoft Corporation. All rights reserved. C:>cd Apachebin C:Apachebin>ab -n 100 -c 10 http://algorhythnn.jp/blg/2014/05/09/au_point-to-au_wallet/ This is ApacheBench, Version 2.3 <$Revision: 655654 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Benchmarking algorhythnn.jp (be patient).....done Server Software: Apache Server Hostname: algorhythnn.jp Server Port: 80 Document Path: /blg/2014/05/09/au_point-to-au_wallet/ Document Length: 508322 bytes Concurrency Level: 10 Time taken for tests: 90.081 seconds Complete requests: 100 Failed requests: 0 Write errors: 0 Total transferred: 50855400 bytes HTML transferred: 50832200 bytes Requests per second: 1.11 [#/sec] (mean) Time per request: 9008.115 [ms] (mean) Time per request: 900.812 [ms] (mean, across all concurrent requests) Transfer rate: 551.32 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 44 79 36.3 70 306 Processing: 6391 8565 1169.1 8523 14688 Waiting: 938 1555 922.4 1286 8225 Total: 6442 8644 1173.2 8581 14791 Percentage of the requests served within a certain time (ms) 50% 8581 66% 8995 75% 9270 80% 9428 90% 10008 95% 10509 98% 11539 99% 14791 100% 14791 (longest request) C:Apachebin> |
1秒あたりのリクエスト処理(27行目)は、1.11に落ちてしまいました。
ちょっと厳しい感じがしますので、これは見送るしかないかもしれないなという判断です。
それでも、エラーは発生しませんね。
Failed requests: 0
3.FCGI無効+APCキャッシュ無効+XSERVERのMySQL
「FCGI有効+APCキャッシュ有効」設定でサイトを構成した場合に、
WordPressが正しく動かなかったり、特定のプラグインがうまく動作しない場合も想定されます。
※私はそうした経験はまだありません。
一応、キャッシュを無効化した環境でも検証を行っておきます。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 |
Microsoft Windows [Version 6.1.7601] Copyright (c) 2009 Microsoft Corporation. All rights reserved. C:>cd Apachebin C:Apachebin>ab -n 100 -c 10 http://algorhythnn.jp/blg/2014/05/09/au_point-to-au_wallet/ This is ApacheBench, Version 2.3 <$Revision: 655654 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Benchmarking algorhythnn.jp (be patient).....done Server Software: Apache Server Hostname: algorhythnn.jp Server Port: 80 Document Path: /blg/2014/05/09/au_point-to-au_wallet/ Document Length: 508322 bytes Concurrency Level: 10 Time taken for tests: 23.160 seconds Complete requests: 100 Failed requests: 0 Write errors: 0 Total transferred: 50855400 bytes HTML transferred: 50832200 bytes Requests per second: 4.32 [#/sec] (mean) Time per request: 2316.032 [ms] (mean) Time per request: 231.603 [ms] (mean, across all concurrent requests) Transfer rate: 2144.33 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 56 118 33.1 120 211 Processing: 1716 2069 254.2 2042 3540 Waiting: 435 553 72.1 542 783 Total: 1854 2187 243.5 2138 3660 Percentage of the requests served within a certain time (ms) 50% 2138 66% 2226 75% 2275 80% 2295 90% 2413 95% 2663 98% 3010 99% 3660 100% 3660 (longest request) C:Apachebin> |
1秒あたりのリクエスト処理(27行目)は、4.32になってFCGI+APCキャッシュ構成よりも、
パフォーマンスが良くなってしまいましたが、
この辺はアクセスが多くならないとキャッシュのメリットがでないという感じかと思います。
それでも、エラーは発生しませんね。
Failed requests: 0
とにかく、XSERVERでは何度ABを実行しても、エラーが返ることがなかったので、
安定して利用ができるのかなと思うところです。
単にサーバーの速さと言う部分ではお名前SDの方がいいスペックなのかもしれませんが、
これは私のサイトとの相性もあるのかもしれません。
結果として、XSERVERで運用するほうが取り急ぎはエラーが減って、
より安定したサイト運用が行えるかなという判断をしました。
決め手は結局サポートの良さ
テストサイトをXSERVER上に公開し動作確認を行っている過程で、
少しわからない点があったためにサポートに電話で確認を行いました。
(平日の昼だったこともあるらしいが)電話がつながるのが3コール以内と言う驚きでした。
サポートにいろいろ引っ越しの経緯などをお話ししていると、
「X10のプランでは1日当たり50GBの転送量を目安にお使い頂けます。」
という、回答が。
ざっとヘルプは見たんですが、そうした情報が公開されているとは知らず、
逆にサポートから明確な数値を教えて頂けたことで、さらに安心感が増しました。
やっぱり、こうしたサポートの対応は印象が大きく、今後の安心感にもつながると思いますね。
事前に自分でヘルプ確認しとけよ・・・て自分も思いましたけどねw
でも試用中にすべての仕様を把握してることなんてないよね?
まず、動くか確認してから、耐えうるかというような細かい条件見ていくと思うんだ。。。
仕様が合っていて、いざ導入!ってなった時に使えない・・・
なんてことも出会うものなので^^;(言い訳)
エックスサーバー よくある質問 | レンタルサーバー 高速・高機能・高安定性の【エックスサーバー】
Q.転送量課金はなしとありますが、転送量がどれだけ増えてもいいのですか?
A.データ転送量の課金はございませんが、ネットワークやサーバに対して過大な負荷が掛かる場合には、制限を行わせて頂く場合があります。各プランの転送量の目安数値は以下の通りです。
各プランにおける転送量の目安 X10 X20 X30 50GB/日 70GB/日 80GB/日 目安数値を恒常的に上回る場合は、ご利用プランの変更をお願いする場合があります。
また、目安数値を大きく上回る転送量が発生する場合には、速度制限などの制限を実施する場合があります。
※お客さまのお喜びの声(これは個人の感想ですw)
一時避難的にとにかくサーバー移さなやばいので、XSERVERに一旦逃げる。サポートに電話したら、3コール内で出てくれて驚いた。電話口の女性の声が可愛くて驚いた。 そして、しっかり50G/日の帯域目安(現在25G前後)ですとの回答に安心。 第一印象が良すぎて怖い #XSERVER
— アルゴリズン (@algorhythnn) 2014, 8月 29
体感的速度
体感的にページを表示した感じではさほど「早くなった!」という実感はありません。
これは当サイト自体がごにょごにょしすぎていて、
処理に時間がかかる状態になってしまっているものと自覚しています。
たぶん、どこに行っても遅いんだと思う。
サイトの内部に手を入れるのは、もっと計画的に行う必要があるとしても、
取り急ぎのエラーは消え、安定して運用が行えている印象です。
取り急ぎ情報共有しておきます。
Google™はGoogle Inc. の登録商標(第4478963号及び第4906016号)です。
GoogleロゴはGoogle Inc. の国際登録商標です。
国際登録番号:881006及び926052及び1086299及び1091990及び1145934
Google Analytics™はGoogle Inc. の商標です。
Xserverおよび、Xserverロゴは、エックスサーバー株式会社の登録商標です。
登録番号は以下の通りです。
第5615066号
Xdomainおよび、Xdomainロゴは、エックスサーバー株式会社の登録商標です。
登録番号は以下の通りです。
第5620796号
sixcoreおよび、sixcoreロゴは、エックスサーバー株式会社の登録商標です。
登録番号は以下の通りです。
第5257521号
wpXおよび、wpXロゴは、エックスサーバー株式会社の登録商標です。
登録番号は以下の通りです。
第5611913号
driveeおよび、driveeロゴは、エックスサーバー株式会社の登録商標です。
登録番号は以下の通りです。
第5171204号
お名前.com、およびお名前.comロゴ(グローブロゴ)はGMO Internet, Inc. の商標です。
関連記事
-
お名前.comレンタルサーバで追加メールアドレスを設定する
Google or AdMax Promotion(it) 禁断の機能がau公式 …
-
KAGOYA™(カゴヤ)の共用レンタルサーバに独自ドメインの割り当て
Google or AdMax Promotion(it) 禁断の機能がau公式 …
-
KAGOYA™(カゴヤ)のMySQL単独プランの利用手順
Google or AdMax Promotion(it) 禁断の機能がau公式 …
-
KAGOYA™(カゴヤ)の共用レンタルサーバENTRYプランに「MySQLオプション」の追加手順
Google or AdMax Promotion(it) 禁断の機能がau公式 …
-
XSERVERのWordPressセキュリティー設定で設定される.htaccess環境変数
Google or AdMax Promotion(it) 禁断の機能がau公式 …
-
KAGOYA™(カゴヤ)の共用レンタルサーバにWordPressの設置(簡単インストール)
Google or AdMax Promotion(it) 禁断の機能がau公式 …
-
【解決12/10】XSERVER上のWordPressにログインできない・投稿できない件
Google or AdMax Promotion(it) 禁断の機能がau公式 …
-
KAGOYA™(カゴヤ)の共用レンタルサーバにFTP接続
Google or AdMax Promotion(it) 禁断の機能がau公式 …
-
KAGOYA™共用レンタルサーバENTRYプランはメールがオプションか!でも大丈夫
Google or AdMax Promotion(it) 禁断の機能がau公式 …
-
KAGOYA™(カゴヤ)の共用レンタルサーバENTRYプランにMySQLデータベースの追加
Google or AdMax Promotion(it) 禁断の機能がau公式 …