毎日モザイク

トップページのrssリーダにfile_get_contentsを使っていたのですが、nginxがgzipされたキャッシュを返すので、file_get_contentsでは対応できないため、curlで引っ張る方法に変更しました。

記事作成時にプレビューが効かないのは、WordPress Nginx proxy cache integratorにわかりやすい設定例があって、それを、nginx公式リファレンスを見ながら書き直したら、おおむね予定通りになりました。

ここは、/以下にいきなりwordpressを置かず、他のディレクトリもある、wordpress推奨（ってわけでもなさそうだけど、プラグインなんかに、その仕様で決め打ちしてあるものがある）の構成ではなく、キャッシュさせたくないディレクトリもあるので、スルーの設定がいまいち分らなかったのですが、公式のlocationの項目を見ると、

• location = / — /だけにヒットする。
• location / —/以下ぜんぶが対象

以上が特別なもので、以下、

• location ~* —大文字小文字を区別しない正規表現
• location ~ —大文字小文字を区別する正規表現

で、ファイルやディレクトリを指定すれば良いようです。

proxy_cacheなんたらを書かず、proxy_passだけ書けばバックエンドに飛ばされます。

##backendのapache2を指定
upstream my_backend {
    server 127.0.0.1:xxxx weight=1 fail_timeout=10s; --ここはバックエンドが一つなのでweight,fail_timeoutは飾り
}
server {
    #################
    # その他、必要な設定
    #################

    #以下、除外設定
    #/が更新を拾ってくるphpなので、常時バックエンドから
    location = / {
        proxy_pass   http://my_backend;
    }

    #wordpress以外のページは常時バックエンドから
    location [regex] {
        proxy_pass   http://my_backend;
    }
}

これで、除外設定もぼちぼち。

あと、edit_postのフックでキャッシュ全消しは企画倒れっぽい……。

edit_postのフックに、下書きとして保存も、自動バックアップも含まれるので、自動バックアップが動くたびにキャッシュが消えるw

さすがにこのままでは消しすぎ……。

publish_post(投稿を公開）、publish_page(固定ページを公開）、publish_to_draft（投稿を下書きに戻す）、edit_comment（コメント追加削除）にフックを掛けることに

nginxのキャッシュ問題は、プラグインで対応。

プラグイン作成はあんまし得意ではないので、自環境でまともに動けばよしとします。

add_action('edit_post', 'hage');

に、

`rm -rf /var/cache/nginx/proxy_cache1/*`　 /* 俺環決め打ち */

を仕込んで、投稿更新時にサイト全体のキャッシュを消し去ることにしました。

/var/cache/nginx/以下はwww-data（俺環）の所有なので、phpから普通に消せます。

更新されたページ関連のキャッシュだけを選択して消すのが正しいんでしょうが、会社のサイトは新刊情報で、コメントの類いもないので更新の頻度も低く、キャッシュを全部消しても影響は一時的なもので済みます。

nginxのcache purgeモジュールのアクセス制限問題からも逃げられるし、通常のaptで更新できるし、俺環にはちょうどいいかも。

wordpressのedit_postフックはコメント投稿も対象なので、コメントをポストしてもキャッシュが消えます。

しばらくここで試してみよう。

追加メモ。

会社のサーバに仕込む時に忘れてはいけないこと。

• 日付で変わる表示があるので、毎日00:00にキャッシュをクリアするcronを仕込むこと。
• だから、キャッシュの有効期限は1dでいい。
• キャッシュクリア後に403が出ることがあるので、今日の設定のまま使わないこと

とりあえずキャッシュを殺して、リバースプロキシだけにしました。

この構成だとスルーしてるだけなので、かえって遅いですが、apacheを正面に出す設定に戻すのが面倒くさいので、このままにして、またの機会にキャッシュを試してみます。

今日のところは、会社のレンタルサーバにも使える、cache_purge付きのdpkgが出来たからこのくらいにしておきます。

nginxはマジ速い。wordpressでサーバが苦しくなったら、apacheはそのままで、nginxを咬ませるだけで救われそう

残骸でもおわかりのように、んぎなんとか（←なぜか読めない）nginxでキャッシュ付きリバースプロキシをテストしています。

性的なファイルはもちろん、動的なファイルも丸ごとキャッシュするようにしている（今現在）ので、アホみたいに爆速です。

キャッシュの有効期限が切れるまではapache2には読みに行かず、んぎなんとかさんが全部処理してくれます。

.phpだろうが、生成したファイルをキャッシュして返しているので、性的なHTMLを読んでいるのと同じ速さで返します。

新規投稿時のキャッシュ更新は、プラグインのnginx cache purgeで上手いこと行きますが、コメント欄の更新が上手くいかない。

会社のサイトをこの仕様にしたら、恐らく同業者最速伝説に名を連ねられると思うんですが、会社のサイトで使うには今ひとつ不便なところが出てきます。

1. クッキーを読んで、ログイン時はキャッシュしない設定でも変更をプレビューが効かない
2. wordpress内のアクセス解析が全く効かなくなること。
3. webalizerをnginxのログに変更しないといけないこと。
4. 性的なファイルは全部キャッシュされるので、画像の変更が面倒くさくなること。
5. キャッシュさせる部分とさせない部分の選別の書式を今ひとつ理解していないので、怖いこと。

1.はかなり不便。設定で解消できるような気もしますが、設定例に添っても今ひとつ上手くいきません。

2.もかなり不便。WP-slimstat-exがかなり便利なのでちょっと辛い。

3.は、まあどうにでも。

4.は設定を理解すればなんとかなるはず。

5.が一番の課題。

あたりがクリアできたら、現状の100倍（応答速度が速すぎて、Firefoxでは計測不能）以上の応答速度が出せるはず。

現状でも処理能力は有り余っているので、当分、自サイトで練習してから考えよう。

追加

もう一つ問題が……。

会社の回線が固定ではないので、投稿時にキャッシュを削除するnginx cache purgeのアクセス制限がうまく付けられない。

こちらのスクリプトは素のままではログインが必要だし。

意外と山は高いな。