 Re: FastCGIについて ( No.11 ) |
- 日時： 2014/06/12 09:55
- 名前： くりくり
- おはようございます。
>全てが同じ動きでは無く、ユーザー毎に設定されるんですね
なるほど、サーバー全体ではなくというユーザーにもか・・・。
うむー。新サーバーの構成をフロントエンドでnginx、
バックエンドもnginxとかんがえてましたがapacheの構成なら.
htaccessつかえるしこのほうがよさそうかも。
とおもったら、
>phpのバージョンの記述を消してしまったことがありました。
.htaccessの消してしまう可能性もあるんですよね。
wordpressのプラグイン.htaccessつかうやつもあるしな。
これは参考になります。
>htmlのみのユーザーとWordPressのみのところと、
多分、サーバの動き方の理想も違う気がしたのですが、
そうした棲み分け方なんか、どうなんでしょうかね？
すごいするどいですね！！
実験の結果からphpの処理に関しては
apacheでもnginxでも大した違いがないことがわかってます。
リバースプロキシーの導入が効果的。
しかし、リバースプロキシーはhtmlとか静的なファイルに関してはあんまり効果がない。
以上の結果から、
nginx(リバースプロキシー)&apacheの構成をとって
htmlはキャッシュ化しない。
wordpressのサイトはキャッシュ化する。
という構成が一番いいんじゃないかな？
という私なりの結論です。
nginxとapacheを併用するパターンは
htmlなんか静的ファイルをnginxで、
phpはapacheで処理をするようにするのが普通らしいですが
上記の設定だと
ご存知のように私のwordpressはURLがhtmlにでてしまいます。
そうすると本当にnginxがファイルがあるかなと思いファイルを探してしまう。
結局、404エラーになってしまいます。
リバースプロキシーの話題はスレッドわけさせて頂きました。
http://todos.xsrv.jp/22patioweb/todos.cgi?no=54
ブログの方でちょっと言及しておりますが、
nginxにはfastcgiキャッシュなるものもあります。
これもリバースプロキシーと違い早いそうです。
しかし、nginx&php-fpmのみこれができるみたいです。
|
| Re: FastCGIについて ( No.12 ) |
- 日時： 2014/06/12 19:57
- 名前： りり
- くりくりさん、リバースプロキシーの独立スレッドありがとうございます。続きを期待しています。今は、他の経験者のレスは得られないかもしれないのですが、どんどん書き進むと、似たようなトライをされている方が、検索ヒットから訪れるかもしれません。こちらでは、どなたでも気づいたことや考えていることなど、気軽にちょっと書いてみようかな？という雰囲気で進むと良いなと思っています。
nginxのことは、全然分からないのですが、apacheは、シェアが落ちてきているらしいですが、.htaccessで、ユーザーがそれぞれに設定できる部分があるので、レンタルサーバなどでは便利なのかもしれませんね。
専用サーバを運用するなら、中に入るものの性質に応じて考えていくと良いのかもしれませんよね。
くりくりさんのブログ、本当に知らない単語が沢山で分からないのですが、ストーリー的には何となく分かりました。
くりくりさんのいろいろなトライで、うまい方向にまとまっていったようですね。
素晴らしいです！
FastCGIとかリバースプロキシーとか、バラバラに考えるのではなく、組み合わせというか、連携というか、サーバ運用の大枠での工夫という感じになりますね。
私は、くりくりさんのブログで高速化に苦心されていて、使っているXserverでもFastCGI利用設定があり、どういうとき利用すると良いのかということから、興味を持って、こちらのスレッドを立ててみたんですが、サーバの動きは、いろいろとあるんだなーと感心するばかりです。
|
| Re: FastCGIについて ( No.13 ) |
- 日時： 2014/08/13 17:54
- 名前： くりくり
- こんにちは
sslの導入に伴いリバースプロキシーだとサイト表示がちゃんとできないので
fastcgiキャッシュに変更しました。
これはnginxしかない機能でしてapacheにはありません。
リバースプロキシーのキャッシュありとおなじくらいパフォーマンスがあります。
|
| Re: FastCGIについて ( No.14 ) |
- 日時： 2014/08/14 16:25
- 名前： りり
- くりくりさんのブログによると
>nginxのリバースプロキシーを設定すると例のhttpとhttpsの混在なんとかになりサイト表示がブロックされてしまう。
>fastcgiキャッシュに変更し、キャッシュの保持時間をすごく短くした。
ということですね。
sslの導入で、リバースプロキシーだとサイト表示がちゃんとできない…というのは、どうしてなんでしょうね？
|
| Re: FastCGIについて ( No.15 ) |
- 日時： 2014/08/15 15:56
- 名前： くりくり
- こんにちは
Fastcgiキャッシュのベンチマークテストとりましたら、
sslを常時接続にするとサーバーの負荷が高くなることがわかりました。
負荷が高くなる原因はキーの長さ2048bitが原因だそうです。
暗号化の強度がたかくなれば負荷もあがるわけです。
これを解決してくれるのがsslオフローダーだそうで、
リバースプロキシーもオフローダーになるみたいことがかいてありました。
後の研究課題になりそうです。
|
FastCGIについて