sshログインの応答がやたら遅いとき
現在使っているサーバー２台のうち、一方だけが、やたらsshログインの応答が遅い問題に、随分長い間悩まされてきました。
２台とも同じマシン、同じ設定なのに何故？！！
で、本日、こちらの記事を拝見して、いろいろ試してみたんですが、、、
確かに、遅いマシンの/etc/hostsにクライアントのIPを登録すると、早くなるのです。しかし、接続する全部のクライアントを登録するわけにもいかんし、、、
と思いつつ、/etc/resolv.confをあけてみて仰天、、、
プライマリDNSのアドレス、打ち間違ってるやん……（大汗）
というわけで、プライマリのDNS設定が間違っていたために、そいつがタイムアウトするまで時間がかかっていたのでした……（汗）
正しいアドレスにしたら、さくっと早くなりましたm(_~_)m
ローカルのDNSサーバがまともに動いてないと、うまく接続できんだろう、というのは最初から分かっていたのですが、サーバー側もSSH接続確立するまでに、DNSとやりとりするんですね（汗） しらんかった。
案外、こんなアホなミスで遅い場合もあるかもしれない、という話。
Updraft Plusで設定ファイルも保存する
この記事は、
Wordpressの便利なバックアップ／リストアプラグイン - UpdraftPlus リストア編
の追記です。
さて、実際にリストアをやってみて、UpdraftPlusの威力を実感したのですが、こうなると、wp-content以下以外の場所に保存してある設定ファイルなども自動バックアップしたくなります（笑）。
殆どの方はホスティングサーバにsshログインして作業はしないでしょうから、そういう方には使えない手なのですが、もしsshログインが出来るサーバーだったら試してみてはいかがでしょうか。
wordpress/wp-contentの下に、miscディレクトリを作成。
shellから以下のように入力($はプロンプト）。ただし、wordpressはpublic_html直下のwpという名前のディレクトリにインストールされている、と仮定。
#以降はコメントです。
$ pwd # public_html直下にいることを確認 $ cd wp/wp-content $ mkdir misc
設定ファイルをコピー
$ cd misc $ cp -rp ../../wp-config.php . $ cp -rp ../../.htaccess .htaccess_wp $ cp -rp ../../wp-admin/.htaccess .htaccess_wp_admin $ cp -rp ../../../index.php . $ cp -rp ../../../.htaccess .htaccess_top $ ls -a # 全てのファイルがコピーされているか確認する。 $ chmod 604 .htaccess* # .htaccessからグループのアクセス権を消去
このうち、.htaccess関係は、存在していないものもあると思います。
(xrea, coreserverユーザの方は多分wp-adminの下の.htaccessを弄っているはず）
また、5,6行目は、wp以下にwordpressをインストールしているが、アクセスしたときにはwpの文字をURLから抜く設定をしている人向けです（つまり、wpのインストールディレクトリと、公開ディレクトリが異なる人向け）
要するに、wordpressを動かすのに必要なものは、wordpressのソースファイル以外全てmiscにコピーしてしまえ、ということです。
設定ファイルをシンボリックリンクに変更
こうやっておいて、現存する設定ファイルをmisc以下のファイルへのシンボリックリンクに置き換えます。
$ cd （行き先を指定しなければ、ホームディレクトリに移動します） $ cd public_html/wp $ rm wp-config.php; ln -s wp-content/misc/wp-config.php . $ rm .htaccess; ln -s wp-content/misc/.htaccess_wp .htaccess $ cd wp-admin $ rm .htaccess; ln -s ../wp-content/misc/.htaccess_wp_admin .htaccess $ cd ../../ $ rm index.php; ln -s wp/wp-content/misc/index.php . $ rm .htaccess; ln -s wp/wp-content/misc/.htaccess_top .htaccess
以上で、設定ファイルその他が全てシンボリックリンクに置き換わりました。
今後は、これらのファイルの設定を変更するときにmisc以下のファイルを変更するようにすれば、あとはUpdraftPlusが自動でバックアップしてくれるので、いきなりwebアカウントが消去されても、「リストア編」の要領でwordpressを新規インストールして復旧したあと、miscディレクトリからシンボリックリンクを張り直すだけで完全復活します。
……なんでこんな記事書いたかというと、Coreserverからの更新時期メールがこの１ヶ月でまったく届かなくなり、更新わすれてさくっとアカウント消されたから、なんですけどね……(-_-);;
（サポートに泣きついて復活してもらったが。）
サポートとのやりとりの結果、ValueDomain側はメールを送信していたと判明。で、iCloudメールが怪しいと、連絡メールアドレスをniftyに変えてみたら届きました……
mac.com→mobileme→iCloudと使ってきましたが、iCloudになってからホント最悪です。突然勝手にいままで迷惑判定していなかったメールを迷惑フォルダに突っ込むようになるわ、今回に至っては、どうやら特定単語が含まれるメールは自動的に破棄して送信側にも受信側にも連絡しない、というとんでもない仕様にひっかかった模様。
このフィルターは、ユーザの受信箱に届く前に行われるので、ユーザ側がいくら迷惑メール設定をオフにしても無駄なのです。
特定単語といったって、ホスティングサーバからの更新お知らせメールに一体どんな危険な単語が隠れてるっていうのさ？！
メインアドレスとして使ってきたので残念ではありますが、今後はもうiCloudメールは信用できないものとして、別サービスに重心を移す必要がありそうです。
タダメールだからって言われてもさ、、あたしゃ、mac.comからの使い手で、そのころはちゃんと金払って使ってたんだよ！！
フリーメールは信用できないから、わざわざそうしてたのに、勝手にフリーに移行して不都合は我慢しろってのはあんまりじゃないかApple。
だったら、フィルター通す前に他アドレスに転送する機能つけろ、とマジ思います。
大体、これが実際の郵便なら、他人への郵便物開けて検閲するのも、勝手に消すのも犯罪なんだよ。。
ネット上では、スパム撃退、犯罪防止の名目のもと、そのへんがどんどん何でもアリになっている印象を受けますが、そのへん、どこの会社ももうちょっと慎重になった方がいいんじゃないですかね？ と思う今日このごろ。
しかし、度々SPAM判定されるValueServerもどうかと思うので、ValueDomainのサービスを使っている方は、更新通知用メールアカウントをもう一つ登録しておくことを強くおすすめします。（更新通知のみ、２カ所に送る設定ができます）
JASRAC管理曲の楽譜をダウンロード販売する（ついでに紙の楽譜もオンデマンド印刷）
ヴィオラ３本とピアノのための小曲、をウン十年前におねだりして身近な作曲家に書いてもらいました。なにしろ初心者でも弾けるように、ということで難易度は低いのだけど、アンサンブルはとても綺麗な曲。是非皆さんに楽しんでいただきたい曲です。
2014/12/9追記：
結局ヴィオラ版はタダで公開。こちらからダウンロードできます。
ところが、演奏の機会がなく、出版の機会もないので、このままでは埋もれてしまって勿体ない。
だったら、（例によって）自費出版してしまえ、という話になるのですが……
しかし、アンサンブル楽譜というのは、短いくせに各パートに１部ずつ楽譜が必要になって、印刷すると大変コストがかかるのです。。
というわけで、ダウンロード販売にしようと思い、どこに委託するか迷って色々調査した記録です。
ダウンロード販売したいのはJASRAC管理曲だから、まずはそこのところの手続きを代理でやってくれる、というのが必要条件。
@ELISE
ここも楽譜の量ではかなりいい感じなんだけど、やっぱり個人からの投稿は受け付けてないっぽい。というわけで、パス。
同人音楽の森
ここはアカウント作れば誰でも投稿できる。
しかし、手数料40%って……！！！（JASRAC申請料10%含む）
Amazonのe託と同じだよ！！ Amazonは、実際に商品を受け取って、在庫を抱えて、発送して（しかもほとんどの場合送料無料）ってやってるから、40%でも、まあそんなもんだろう、と思うけど、データのダウンロード販売なんて空気みたいなもんじゃないですか！！
（芸術的内容のことを言っているのではなく、紙の楽譜を出版・保管するのに比べたら断然コストがかからない、という意味）
クレジット手数料は精々５％、JASRACに１０％で、残り２５％がシステム利用料って、どう考えても高すぎ。
あと、プロの作曲家の曲なので、「同人」音楽の森、というサイトに委託するのはやはり申し訳ない、、、ので、パス。
オケ専♪
オーケストラやってる人は多分知っている「オケ専♪」というSNSみたいなのがあるのですが、このなかに、アンサンブル楽譜だけを扱っている「アンサンブルの楽譜マーケット」なるものがあります。
ここは、メンバーからアレンジャーを募って販売する形式だから、やはり登録すれば販売可能。
しかも、今回の場合、ターゲットはオーケストラを趣味でやっている人だから、場所的にも問題なし！
…と思いきや、ここも手数料が４０％！
あと、値段が５００円、１０００円、１５００円と５００円単位でしか決められないのが厳しい。趣味のアレンジャーも募ってるみたいだけど、趣味のアレンジにいきなり５００円って壁が高すぎないか。
検索機能もないしなあ。
（ん？ アレンジャー募集、ってことは、オリジナル曲は扱わない？ そんな縛りはないよな、普通、、、）
DLmarket
今回初めてみつけたところ。
結論をいうと、ここが一番だと思う。
何がいいって、
１）手数料は１５〜２０％（購入者がどの決済方法を用いるかによる）
２）JASRAC管理曲を使うときは、手数料に10.8％上乗せ。更に四半期ごとに売上げ数の報告義務あり
３）楽譜を買う人が、紙の楽譜で欲しいと思ったら、オンデマンド印刷された冊子が同時に注文できる（！）
４）国際化対応
上記２件と比べて、手数料がリーズナブルなのは勿論ですが、３）と４）が非常に素晴らしい！
つまり、曲を提供する側が冊子を作らなくても、買う側が欲しいといえば、DLmarket側が勝手に製本して販売してくれるのです！ 勿論、楽譜発送の手間もナシ。
（ただし、製本されてしまうので、パート譜が必要な楽譜は注意が必要？ スコアとパート譜をそれぞれ別売りして、セット販売すればよさそうだけど、その場合JASRAC認可番号はどうつけるのか、とかちょっと考える必要アリ。）
これをやるには、別途「製本直送.com」にアカウントを作り、DLmarketのアカウントとリンクする必要があります。
また、製本楽譜分のJASRAC許諾は自分でやらなければならないみたいです。
どうするかというと、発行部数を報告してお金を払ってJASRAC許諾番号をもらうんですが、オンデマンド出版の場合、最初に部数が決まっていないので、適当に少部数を報告するのかな？
それで、その部数枠使い切ったら、また報告する、という感じだと思います（昔楽譜にJASRACシール貼ってた頃そんな感じだったから、多分同じだろう）。
以前こちらの記事で楽譜の自費出版について書きましたが、このシステムなら、１００部も売れないよ、って楽譜でも簡単に１部から出版できますよね。
しかも、よくあるオンデマンド楽譜出版サイトみたいなお仕着せの表紙じゃなくて、自分で表紙から何から作って入稿すればいいわけですから、かなりオリジナリティの高いものが作れると思います。
国際化標準対応なのも素晴らしいです。楽譜なんて、言語関係ありませんから、できれば全世界で売りたい。
英語の紹介文は自分で書かねばなりませんが、購入ボタンなどちゃんと英語用のものが用意されているのは大変有り難いです。
更に、こちらではこんな機能もついてきます。
- PDF保護機能（PDFファイルに購入者情報を書き込み。閲覧パスワードを設定して不正コピーを防止。）
- セット販売機能（単品商品を自由に組み合わせてセット販売できます。組み合わせは自由！）
- 今すぐ購入リンク（サイトから商品ページを介することなく直接DLmarketのカートに商品を入れられます）
- 購入ページにYouTubeなどの音源をはりつけて宣伝できる
などなど。どうも楽天傘下らしく、購入には楽天ポイントも使えるらしい。
PDF保護機能はスグレモノです。pdfをアップロードして、簡単な設定をするだけで、PDFの全ページのヘッダかフッタに購入者情報を書き込むことができるのです！
更に、購入者専用のパスワードをかけることも出来ます。
これは、購入者のe-mailをパスワードに設定するものです。
これは非常に賢い方法だと思います。PDFを誰かにあげちゃうにしても、パスワードとして自分のメールアドレスを教えなければならないからです。
知人ならいいですが、それ以外の人にメアド教えるのは躊躇しますよね。
勿論、やろうと思えばPDFのパスワード制限を外すのはわけないんですが、それでもフッタに購入者名が書いてあるファイルを、たとえばインターネット上で不特定多数にばらまくのはちょっと躊躇すると思いますし、PDFに「記載された購入者以外の使用はお断り」と書いておけば、不正コピーは一見して不正コピーであることが分かります。
唯一難点があるとすれば、楽譜に特化したサイトではないので、ゲームやらソフトやら何でもアリ状態、更に楽譜についていえば、現在の利用者のジャンルが非常に偏っているように見受けられるので（やたらギター譜が多い）、たとえば弦楽アンサンブル譜なんてのは置くだけではお客は絶対来ないだろう、ということでしょうか。
宣伝は別の部分でやる、と割り切る必要がありそうです。
しかし、決済システム利用手数料としてはかなり安いと思います。
で、結局どうするの、って話なんですが。。
今のところ、DLmarketとオケ専♪に登録してみようかと思います。
というのは、どっちも、売れない限り手数料かからないから。
で、オケ専♪の方はヴィオラ３本＋ピアノ版とヴァイオリン・ヴィオラ・チェロ＋ピアノ版の両方をつけて500円で販売し、紹介のところに「ヴィオラ版だけ、もしくはヴァイオリン・ヴィオラ・チェロ版だけが欲しいひとはDLmarketに行ってくれ、楽天ポイントでも買えるよ♪」とか書いておけば、多分殆どの人はDLmarketにいってくれるんじゃないかなー、と思います。
両方とも欲しいひとはそんなにおらんでしょう。
買ってくれそうな人の目に触れる率という意味では、やはりオケ専♪の方に軍配があがりそうなので。
というわけで、楽譜の個人ダウンロード販売（＋オンデマンド出版）もかなり現実的になってきたなー、と思った、という話でした。
また結果はそのうち追記します。
2014/4/15 追記：
DLmarketに登録してみました（３本のヴィオラのためのカプリスじゃなくて別の曲ですが）。
以下のボタンをクリックすると、商品詳細ページに飛びます（このボタンを押しただけでは、まだ購入にはなりません）。
45秒のサンプル音源もつけてみました♪
すばらしいです。DLmarket!
非常に痒いところに手が届く仕様です。
作曲家の皆様、出版出来ずに眠っている楽譜、是非公表されてはいかがでしょう？
Wordpressの便利なバックアップ／リストアプラグイン - UpdraftPlus リストア編
以前、「Wordpressの便利なバックアップ／リストアプラグイン - UpdraftPlus」という記事を書いたのですが、本日リストアの方を試してみましたので、その記録です。
リストアの状況として、サーバー引っ越し(A)、またはwordpressクリーンインストール(B)を仮定しています。それぞれの場合の手順に(A)、(B)の記号がついていますので、ご参照下さい。
通常はサーバー引っ越しの方法で殆ど対応できますが、たとえばwpをハックされた、サーバーが死んでバックアップファイルしか残っていない、などの場合は、クリーンインストールを行います。
文字コードが設定した覚えがないのにUTF-7になっていた、などの現象があったら、まず間違いなく既に管理パスワード破られてハックされていますので、危険ですからwordpressをクリーンインストールしましょう！
※今回、リストア先はvalueserverを使っています。これは、セーフモードがないサーバなので、特に問題ありませんでしたが、xrea/coreserverではもしかしたら問題が発生するかも知れません。
その際は、一時的に、トップディレクトリの.htaccessに
AddHandler application/x-httpd-phpcgi .php
を足して、全てのファイルをcgiモードで動かしてしまえば良いと思います。
どうせ一回だけの作業ですので……
（作業が済んだら、消しておくのを忘れないように！）
最新バックアップをとる。（A、B共通）
※（B）クリーンインストールを行う場合は、wordpress本体及びUpdraftPlusを最新にアップデートするか、バージョンを確かめて同じバージョンのファイルが入手出来ることを確認しておくこと。
旧サーバのwordpressにログイン。プラグインからUpdraftPlusの「設定」をクリックし、「今すぐバックアップ」ボタンを押します。
更に、外部サーバにバックアップファイルを保存する設定にしている人は、その設定をメモ帳にでもコピーしておきます。
（B）クリーンインストールを行う場合は、wp-config.phpもローカルにダウンロードしておきます。
wordpressのアップロード
データベースを作成（A,B共通）
xrea/coreserver/valueserverなら、管理画面の「データベース」から作成可能。このデータベース名及びパスワードは、旧サーバのものと同じでなくても良い。データベースの文字コードを旧サーバのものと揃えておくこと！
エックスサーバの場合はこちらのページを参考にしてください。
wp-config.phpを変更（A,B共通）
wp-config.phpの以下の部分を変更。
（旧サーバと全く同じデータベース名、パスワードの場合は、変更しなくて良い）
/** WordPress のためのデータベース名 */
define('DB_NAME', 'データベース名');
/** MySQL データベースのユーザー名 */
define('DB_USER', 'ユーザー名');
/** MySQL データベースのパスワード */
define('DB_PASSWORD', 'パスワード');
/** MySQL データベースのあるサーバ。通常はlocalhostのままでよい。*/
/** エックスサーバはmysqlXXXX.xserver.jpなどの指定サーバに変更する */
define('DB_HOST', 'localhost');
更に、以下の二行を追加。
これは、サイト引っ越し中に、旧サイトにリダイレクトされてしまうのを一時的に防ぐための設定です。
define('WP_HOME','http://新サーバのドメイン名/wp');
define('WP_SITEURL','http://新サーバのドメイン名/wp');WP_HOMEは公開アドレス、WP_SITEURLはwordpress本体が置かれているアドレスを書きます。最後の'/'は書かないこと。公開アドレスに'/wp'を含めない設定にしている場合は以下のとおり。
define('WP_HOME','http://新サーバのドメイン名');
define('WP_SITEURL','http://新サーバのドメイン名/wp');ひとたび引っ越しが完了し、データベースに埋め込まれている全てのドメイン名を新サーバのものに変更するか、独自ドメインを利用しているならDNSを変更して独自ドメインから新サーバへアドレスを向けた後は、コメントアウトします。
引っ越しではなく、同じサーバ上で再インストールを行う場合は、これらの行は書かないこと。
wordpressのインストール（A,B共通）
新サーバのwordpressの管理画面にアクセス。
http://サーバー名/wordpress/wp-admin/
アクセスしたら、ユーザー名とパスワードに、旧サーバのwordpressで一番最初に作成した管理用のユーザー名とパスワードを入力する。多分、こうしないと、idの重複が起きるような…？
データベース読み込み時に「復元」ボタンを押すと、ここで設定したユーザ名は消えて、もとのサイトにあったユーザの情報がコピーされる模様です。なので、adminとか攻撃されやすいユーザ名でなければなんでもOK。
UpdraftPlusのインストール
(A)サーバー引っ越しの場合
この場合は、既にwp-contents/pluginにUpdraftPlusが存在するはずなので、新サーバでwordpressにログインし、プラグインからUpdraftPlusだけを有効化するだけで良い。
(B)クリーンインストールの場合
UpdraftPlusを新規インストールし、有効化しておく。
バックアップファイルのコピー（A,B共通）
UpdraftPlusの設定画面へ行き、
バックアップログ & 復元: 可能な設定
となっているところの「可能な設定」をクリック。すると、以下のような設定窓が開く。
ここで、保存先設定を弄っていなかった人は、「新しいバックアップ設定のフォルダを再スキャン」を押す。
一方、別のサーバにバックアップを保存していた人は、「バックアップファイルをアップロード」をクリックし、最初に保存しておいた旧サーバのバックアップファイルをアップロードする。
バックアップファイルのリストア
ファイルのアップロードが済んだら、「復元」ボタンを押す。新しい小ウィンドウが開く。
(A)サーバー引っ越しの場合
「データベース」のみにチェックを入れて、「復元」ボタンを押す。（テーマファイルなどは既にコピーされているはずなので、復元するのはデータベースのみで良い）
(B)クリーンインストール
全てにチェックを入れて、「復元」ボタンを押す。
別のサーバにバックアップを保存していた場合、しばらくすると、「これはリストアではなく、マイグレーションになります」みたいな忠告メッセージが出てくる（こんなの↓）
どのみちデータベースは空なので、もう一度「復元」を押す。
(プラグインが有料のオプションを勧めてくるが、必要ありません）
(B)クリーンインストールの場合、wp-content以下に、xxx-oldという名前のディレクトリやファイルが出来ている。これらは、中身が空であることを確かめて消してしまって良い。
(language-oldのみ空ではないけれど、これはwordpressがインストールしたものなので、再インストールしたwordpressが同じバージョンなら消してしまって問題ない。より新しいバージョンをインストールしてしまった場合は、language-oldの中身をlanguageディレクトリに移動。）
UpdraftPlusの設定（A,B共通）
UpdraftPlusの保存設定を行う。旧サーバは廃止して新サーバに完全移行するのであれば、旧サーバの設定をそのままコピーすれば良い。
以上！
結論を言うと、めちゃくちゃ簡単です！！
お金を払えば複数のサーバにバックアップも出来るようですが、無料版でも十分だと思います。
xrea、coreserverでwordpressの表示速度を上げる
以前から、xreaとcoreserverで公開しているwordpressサイトがやたら重くて、本日ついに高速化プラグインを入れることを決意しました。
で、例によって、セーフモードで上手く動かないものが頻発する中、色々トライしてみた結果です。
お約束のセーフモード対策
もともと、xrea/coreserverでwordpressを使っている人は、.htaccessでいくつかのphpをcgiモードで動かすよう設定しているはずですが、一応念のため。
wp-admin/.htaccessに以下の記述があるか確認。プラグイン周りで足りないものがあれば足しておく。
# ファイルのアップロード <files async-upload.php> AddHandler application/x-httpd-phpcgi .php </Files> #プラグインとテーマの管理パネル <Files update.php> AddHandler application/x-httpd-phpcgi .php </Files> # wordpress本体のアップデート <Files update-core.php> AddHandler application/x-httpd-phpcgi .php </Files> # blog管理 <files admin.php> AddHandler application/x-httpd-phpcgi .php </files> # プラグイン管理 <files plugins.php> AddHandler application/x-httpd-phpcgi .php </files> #プラグインの自動インストール <files plugin-install.php> AddHandler application/x-httpd-phpcgi .php </files>
xrea
まず、xreaでwordpress、というのがそもそもかなり無茶になってきたのかも、と先に断りつつ……（笑）
実は、xreaでは、別にMovable Typeで運用しているサイトがありまして、そちらは勿論静的html書き出しなので、見る分には殆どストレスはありません。
…が、wordpressのサイトの方は、テーマもほとんどtwentytwelveそのまんまなのに、めちゃくちゃ重い。トップページ表示に１０秒以上かかります。
なので、最初は、完全に静的htmlを作ってくれるプラグインを探したんですが、やっぱりセーフモードがひっかかってうまく動かない。
有名なWP Super Cacheなんか、キャッシュディレクトリの下に何やっても消せないディレクトリを作ってくれちゃって（ユーザーapache、グループapacheの持ち物で、それ以外のユーザに書き込みOKが出ているにもかかわらず、消せない…正直何がおきているのかさっぱり）もうこのディレクトリはアカウント閉じるまでゴミ箱ディレクトリに入れとくしかない、って感じです。
あとで紹介するWP Fast Cacheはものすごく私好みにシンプルなんですが、コメントがついたときに自動で静的htmlを作り直すのをやってくれないので、ブログには不向き。
というわけで、キャッシュ系を検討。
すると、評判が良いのはQuick Cacheなのだけど、これはphpが5.3以上でないと動かない。xreaのモジュール版phpは5.2.5なんですね…（涙）
cgiモードなら5.3が提供されているので、それで動かそうと思いつく限りのphpファイルを5.3で動かすよう指定してみたが、やっぱりダメ。
というわけで、結局、以下の組み合わせになりました。
Hyper Cacheは、インストール後に、wp-config.phpに以下の行を足す必要があります。
/**
* for Hyper Cache plugin
*/
define('WP_CACHE', true);しかし、それ以外はデフォルト設定で大丈夫です。
このほか、流行のCDNで、CroudFlareとかも試してみたんですが、最初は速いように見えたものの、時間をおいて接続してみるとかえって遅くなったりすることもあって、結局断念。（まあ、タダでやろうと思えば皆どこも同じようなものになるわな…）
ただ、CDNはサーバーが落ちたときにもキャッシュでwebを表示してくれるので、そのうちまた時期をみて検討してみようと思います。
ちなみに、速度調査したのはここでした。
http://tools.pingdom.com/fpt/
この手の速度調査でよく目にする話ですが、これで良い数値が出ても、体感速度はあまり変わらないこともあったりするので、あまりこれでチューニングを繰り返すのではなく、あくまでブラウザでアクセスしてみて、体感速度が早くなっているかどうかで決めるのが良いと思います。
で、どのくらい早くなったか、というと、、、
実際のところ、今迄は「サイトおちてるの？」ってくらい遅かったのが、「オッソーイ！」ってくらいになりました（笑）。以下のサイトです。
…というわけで、wordpresssサイトはそのうちxreaから引っ越すことになると思います。
coreserverの方を引っ越すつもりでとったvalueserverのアカウントにミラーを置いて、速度を比べてみるつもりです（valueserverならセーフモード外れてるから、WP Super Cacheが試せるし）。
coreserver
coreserverのcore-Aを使っているんですが、さすがにxreaほど遅くはありません。
なので、上の対策を講じても、あまり早くなりませんでした。
（プラグインの数がかなり多いのと、jQueryでスライダーやったり色々してるからかも）
しかし、こちらのサイトはブログサイトではなく、コメント欄は皆無なので、静的html書き出しが使えます！
勿論、静的html書き出しをやってくれるプラグインは沢山あるんですが……
もう、ファンシーなことは何もやらなくていい！ とにかく見たままのhtmlを吐いてくれ！という方におすすめなのが、WP Fast Cacheです。
これは、文字通り、記事（ページ）を書いて、公開して見栄えを確認して、これでヨシ、と思ったら、記事編集画面のタイトルの下にある「Add Page To WP Fast Cache」ボタンを押すだけ。
これを押すと、こうなります。
昔の記事を修正したので、それを反映させたい、というときは、「Refresh Page Cache」ボタンを押せばいい、というわけです。
また、このプラグインは、ページ（投稿）単位でキャッシュするかどうかを決められます。
このページはダイナミック出力ページを見せて欲しい、と思ったら、最初から「Add Page To WP Fast Cache」ボタンを押さずにおくか、「Remove Page From WP Fast Cache」ボタンを押してリストから外します。
また、今迄に書いた記事をまとめてキャッシュする場合は、プラグインの設定から出来ます。
この設定窓がまた超簡単。
青いボタン左から、「キャッシュを全部消す」「キャッシュを全部作り直す」「最近の２５ページをキャッシュする」「最近の投稿２５件をキャッシュする」「カテゴリーページを全部キャッシュする」
その下が、「指定URLをキャッシュする」
です。つまり、過去の記事全部をキャッシュする場合、大体記事の数が500程度、と思ったら、25と数字が入っているところを適当に1000とか入力してボタンを押せばいい、という仕組みです。
なにしろ、圧縮だの何だのと面倒なことをしないから、キャッシュを作るのもかなり速い。負荷制限があるホストマシンでは、この軽さは有り難いです。
とにかくシンプルな作りなので、自動でキャッシュを作ってくれたり、時間がきたらキャッシュを作り直したり……みたいなことは一切やりません。
全部手動。
Movable Typeを使ったことがある人なら、かなり「再構築」に近いイメージです。
（…といっても、最近のMTはよく知らんのだけど）
ちなみに、管理ログインした状態でページにアクセスした場合には、キャッシュファイルではなく、wpが吐くダイナミック出力のページが表示されます。
プラグインをインストールしたブラウザでトップページの再読み込みをして、「全然速くなってないじゃん！」とキレないように（笑）。
一度ログアウトして表示しなおすか、別のブラウザで確認してみて下さい。
静的htmlが表示されているかどうかの判別は、pluginsディレクトリ以下に出来ているキャッシュhtmlに試しに手を加えて表示してみれば分かります。
もっとファンシーなプラグインなら、「これはキャッシュです」みたいなコメント行を突っ込んでくれるものもあるんですが、、いや、シンプル・イズ・ベストで（笑）
で、どのくらい速くなったかというと、、、、
これは、もう、目に見えて速くなりました。
わざわざ測定サイトに行くまでもないです。「そういえば、昔、webってこのくらいの速度で見えるのが当たり前だったわ〜」と思い出させてくれる速度です（笑）
以下がそのページ。
http://www.hoshina-music.com/home
ただ、色々つめこんでいるトップページはまだちょっと重いので、あとはcssのゴミを掃除してデータ量を減らすとか、javascriptを整理するとか、地道な作業で軽量化をはかろうと思います。
…ってか、これ、wordpressの標準機能にしてよ、って感じ……。
ダイナミック・パブリッシングが売りなのはわかるけど、やっぱり静的htmlは軽いよ！
（だからといってMTに戻る気はさらさらないのであった。自前関数が使えない世界には最早戻れない……）
coreserverからvalueserverに乗り換えようとして止めた件〜セーフモードはあった方がいいです
一時期、借りているcoreserverの共有ユーザーのcgi使用率が異常に高く、サーバーレスポンスが極端に遅かったため、この際valueserverに乗り換えようと思い、アカウントをとりました。
……が、結局、引っ越しは取りやめました。
理由は勿論、1/19に起こったs1.valueserver.jpの大規模改竄事件です。
開いていてはいけないポートが開いていたとか、管理側の問題もあった模様ですが、どうやら直接のきっかけはwordpressの脆弱制をつかれたことらしい。
とのこと。
実は、こちらの記事にも書いたとおり、私も一度wordpressをハックされています。
これは、アメリカのサーバーで運営しているページで、前管理者から管理を引き継いだ３日目にやられました。wpに移行してからの公開日数は１ヶ月ほどで、理由は、おそらくパスワードが単純すぎた上に、パスワード回数制限プラグインも入れていなかったので、ブルートフォースアタックにやられた、ということだと思います。
たった１ヶ月ですよ！
どんだけハッカーに狙われてるんだ、wordpress (苦笑）
しかし、私はそれ以前に、xreaとcoreserverで何年もwordpressのサイトを運営していました。wpの管理パスワードも当時は簡単なものでしたが、一度も被害を受けたことがありませんでした。
別のサーバで被害を受けて、初めて理由がわかりました。
つまり、ハッカーはログイン後、直接index.phpのテンプレートを「テーマの編集」タブから書き換えていたのです。
ところが、xreaやcoreserverは、デフォルトではこれらの変更が出来ません。
いわゆるセーフモードというやつが働いているおかげで、見るのは出来ても、変更は出来ないんです。
また、新しいフォルダを作成させるようなプラグインはインストールはできても、そのままでは稼働しないことが多いです。
結局、動かすにはFTPソフトを使わないといけないけれど、xreaやcoreserverのFTPパスワードというのは、ユーザーが自分で決めることができなくて、完全にランダムパスワードです。これは、素人がゴロ合わせで作るパスワードよりずっと強いので、簡単には破れません。
つまり、多分、今迄にもおそらくxrea, coreserver上の私の管理するwordpressはハックされていたかもしれませんが、セーフモードのおかげで何も（ハッカーにとって）面白いことが出来なかったため、ハッカーが何もせずに帰った可能性もあるわけです。
勿論、セーフモードが働いていても、記事全消去とかはできますから、弱いパスワードは絶対ダメですが。
（その後、これらのサーバーにあるwordpressは、最新版にアップデートの上、パスワードも複雑なものに変更し、かつログイン監視プラグインと、パスワードトライ回数制限プラグインを入れました。詳細はこちらの記事）。
web上をみると、xreaとcoreserverについては、セーフモードに関する不満を述べた記事も結構あるわけですが……
セーフモード、というのは、名前の示すとおり安全弁なわけで、その威力を思い知ることになりました（笑）
Valueserverの評判がそれほど悪くなかったようなので、値段も安いし、乗り換えを検討したんですが、やっぱりやられたか、という感じです。
いや、乗り換える前に分かってよかった。
勿論システム側で防御することも大事だけど、人間のやることだし、システムアップデートのたびにセキュリティーホールがあく恐れはあるわけですから。
それだったら、多少の不便は我慢してでも、少しでも安全な方がいいです。
2/1 追記：
php5.2以前のセーフモードは、もともと共有サーバで動かす際にapache権限で動かしちゃうため他人のファイルでも書き込みが出来てしまう、という問題を一時的に解決するための苦肉の策だったらしい。。
なので、php5.4以降ではこのオプションはなくなったらしいです。
というわけで、結局消え逝く運命なんですね、コレ…
でも、あのいい加減なパスワードで何年も無事だったのは、セーフモードのお陰としか考えられないわ……
管理画面からphpファイルを書き換える機能はオプションにしとけばいいのに。
共用サーバの怖いところは、住人の誰かが侵入を許すと、全体に被害が及んでしまいかねない、というところです。
私はそんなにマメな人間ではありませんから、他のどなたかのミスで自分のウェブがのっとられるのは困りますが、それ以上に自分がミスをして他の人に迷惑をかけるのが怖いです。
というわけで、なんだかvalueserverの登場でxreaやcoreserverはもういらないんじゃないの、って空気が漂っている今日ですが……
是非これらのサービスはやめないで欲しい、と思います！！
それに、多分、アファリエイト目当てのやたらサーバに負荷かけるサイト群は、より安くて自由度が高いvalueserverに移っただろうし（笑）
（xrea plusはいらん、core miniでいいんじゃないの、って話もききますが、xreaは基本タダ、ってところがすごいのです！
だから、お金払い忘れても、ファイルやアカウントが消去されることはありません。広告は入りますけど。
私は一度、coreserverで更新忘れて、アカウント削除＋ファイル全消去されましたので（汗）それほど安定性を求めない趣味のブログは全てxreaにおいています。）
Flickrの写真がiframeのせいでブログに貼れなくなって困っている方は、Flickr2HTMLが便利です。
「Wordpressの便利なバックアップ／リストアプラグイン - UpdraftPlus」の記事を書くのに、山ほどスクショとって、全部flickrに上げて、いざ記事に埋め込もうと思ったら、flickrのShareオプションからhtml書き出しが消えていて、iframeしかコードを吐いてくれません！
はてなダイアリはiframeを許してくれないので、こうなると折角flickrに上げた写真全部手でhtmlタグ書くはめに……（汗）
というわけで、先のエントリーには、「ちくしょう！」を連発しながら昔ながらのaタグとimgタグを使ってスクショを貼ったのですが、今日になってもっと簡単な方法があることが判明。
その名も、Frickr2HTML!
Flickrをブログに貼りつけるタグを取得するブックマークレット、Flickr2HTMLが完全リニューアル！！
随分昔からあるブックマークレットのようですが、今回のflickrの改悪のお陰で需要が急激に増すのではないかと思います。
これがあれば、今後Flickrがお仕着せのビューワーを強要してページの表示を著しく重くするようなことがあっても、そういう改悪とは無関係でいられます。
気になるのは、htmlを生成するのに、人様のサーバーを使わないといけないことですが……
しかし、いずれにせよ、開発者様ありがとう！
ところで、FlickrのAPIをとってくるところが多少リンクされていた説明と変わっていたので、補足しておきます。
まず、flickrにログインしたら、ExploreからApp Gardenへ。
すると、右肩に以下の項目があります。
スクリーンショット 2014-01-26 1.35.17 PM Photo by Nohara no Mogura
この中から、「Get an API Key」をクリック。
すると、以下の画面になるので、Non-Commercialを選択。
スクリーンショット 2014-01-26 1.35.29 PM Photo by Nohara no Mogura
以下の設定事項を入力します。
どのみち、自分にしか使えないAppを作成するので、ものすごく適当でいいです。
スクリーンショット 2014-01-26 2.25.08 PM Photo by Nohara no Mogura
そうすると、こんな感じでAPIキーが発行されます。
（ちなみに、わざと途中で切っているので、このキーを入れても動きませんよ（笑））
スクリーンショット 2014-01-26 1.37.29 PM Photo by Nohara no Mogura
実際このページで使ってみましたが、いかがでしょう。
というか、下手にあの使いにくいインターフェースをクリックしてコード取得するより、こっちの方がよっぽど早いことに気づきました（笑）
一応Flickrには改悪をもとに戻せ、とコメント送っておきましたが、別にもうどうでも良くなったり。。
