ここに関しては無償のIncapsulaのほうが向いてるな。いうことで、いつか失敗した多段に再挑戦します。その前に、ちょっとKUSANAGIのbcacheとfcacheを設定してみます。参考:詳解!KUSANAGIキャッシュ講座で、うちの場合は、サブディレクトリにWordPressをおいていますので、まずはKUSANAGIのシェルを修正します。この辺みながら雰囲気で。fcacheは早い話、nginxのリバースプロキシ機能でのキャッシュ、bcacheは動的に生成されるページを一定期間HTMLとして静的に保存する。両方組み合わせれば、bcacheで静的に生成されたHTMLをリバプロがキャッシュして返してくれると。参考:KUSANAGIでサブディレクトリにWordPressを複数インストールするで、onにします。実際効果はあるのかというところをちょっとテストしてみます。WebPageTestで測ってみました。20.163s流石にCPU性能、メモリ性能では旧オンプレ環境に負けてるので遅いですね。17.114sお、早くなりました。これを基準にbcacheとfcacheを試していきます。15.867sおおー。確実に早くなりました。以下のようにF-CACHEにHITしたことがわかります。18.046sおー、CloudFlareなしfcacheオンリーだと、初速はめちゃめちゃ早いですね。15.231s初速は落ちましたね。他の静的コンテンツがCloudFlareのキャッシュから帰ってくるので、全体的なスピードはアップした、という感じでしょうか。18.451sやはり初速は早いけど、全体的にはCloudFlareのCDNのほうが強いですね。17.531s初速遅いけど判定は、Cですね。Acceleration機能です。今回はAWSのVPCがus-eastなので、アシュバーン?が最寄りでした。13.971s初速ともにまぁまぁですね。一応両方ちゃんと通ってます。NNNなので、Incapsulaのキャッシュはまだ効いてませんでした・・・けど、CloudFlareがHITしているので、結局AWSまでは取りには行ってないはず。14.404s一つ上とまぁ誤差ですね。14.749s今これです。いうことで、初速は、CloudFlareなしで、KUSANAGIのfcacheが一番速い。bcacheが一番速いようです。今回IncapsulaはBot制御目的ですし、2箇所でキャッシュ持つとややこしいので、キャッシュはCloudFlareだけにしました。■CloudFlareとIncapsulaの多段構成について多段構成のポイント?ですが、Incapsulaを手前にすることは(おそらく無償版では)不可。無償版IncapsulaはOriginにCNAMEが使えずIPアドレスしか使えない。CloudFlareを前にする場合のポイント。(多分合ってると思う)・CloudFlareに別のドメインを作ってそっちをIncapsulaに登録する→同じ名前をCloudFlareとIncapsulaに存在すると以下のようなエラーになる。※IncapsulaのProxyが名前解決したときに自分じゃない名前解決結果が来るから?と思われる。→そんなことないです。それできなかったら導入前のhostsを使ったテストもできないので。追記】いろいろ間違ってます。普通にincapsulaにはwww.hits-net.comで登録してそのCNAMEをCloudFlareで向けつつCloudFlareのCDNを有効にすれば動きます。23の原因にはサポートとも確認しましたが、結局わからずじまいで、なぜか今日改めて試したらうまくいきました。reuseの機能を活用して、CloudFlareの本丸ドメインをCNAMEでIncapsulaに向ける。→Incapsulaにはxxx.hits-net.comで登録してるけど、そこで払い出されたCNAMEをwww.hits-net.comに向けてさらにCloudFlareのCDNとDNSをオンにして、多段にしました。■リダイレクトの初速を上げるいま「/blog」へのリダイレクトは、cloudflareがやってる・・・と思う。Incapsulaが時折古いオリジン(旧オンプレ)に転送してしまう謎現象が発生したので切り戻しました。今はCloudFlareオンリーです。このX.X.X.100っていまいま設定上どこにもないんですよねー。同じドメインを何度か消したり入れたりしてるから一部のPoPにゴミ情報のこったかなぁ。