 Re: FastCGIについて ( No.6 ) |
- 日時： 2014/06/05 17:45
- 名前： りり
- くりくりさん、いつも情報をありがとうございます。
APC / OPcacheは、使っているXserverでも対応しているようで、情報がありました。
うちは、サーバ自前ではないので、似たようなことがレンタルサーバではどうなっているかということで、参考になります。
http://www.xserver.ne.jp/manual/man_server_php_apc.php
なるほどーーー
PHPの初回実行時に、PHPの内容を最適化した状態でキャッシュしておき、次回以降、同じPHPにアクセスがあった際にキャッシュを利用することで、PHP実行時のCPU負荷の軽減や、PHPの大幅な高速化を図る…ということなんですね。
こちらでは、
>「APC」はPHP5.3 / PHP5.4のみ、「OPcache」はPHP5.5でのみご利用可能です。
とあるので、PHPのバージョンが上がったら、「OPcache」に移行という感じなのかな？
Xserverで行ったベンチマークにおいては、「FastCGI + APC」もしくは「FastCGI + OPcache」を利用することによって、利用しない場合との間に約3.5倍程度の高速化が見込まれる結果が出ているということなので、FastCGIと組み合わせるとより効果的ということでしょうか？
|
| Re: FastCGIについて ( No.7 ) |
- 日時： 2014/06/05 21:06
- 名前： くりくり
- こんばんは
上で書いたのはphp5.5.12でアパッチベンチマークをしました。
おまけでphp5.3.3も測定していました。
>「Requests per second」は、１秒当たりに処理できるリクエスト数を表します。この項目は
ベンチマークで一番重要な項目で、この値が大きくなれば、性能が向上していると考えられます。
http://www.uetyi.mydns.jp/wordpress/linux-server/entry-441.html
ノーマル
Requests per second: 4.67 [#/sec] (mean)
mod_fcgid
Requests per second: 4.78 [#/sec] (mean)
APC
Requests per second: 9.54 [#/sec] (mean)
ノーマルとmod_fcgidはFailed requests:3
apcは失敗はなくちゃんと処理できました。
php5.5をつかったほうが処理能力はあがりますね。
>PHPのバージョンが上がったら、「OPcache」に移行という感じなのかな？
サーバーの仕様がそうなっているんでしょうね。
試したことはありませんが、php5.3でもopcacheを使えるとどこかで読んだことがあります。
>FastCGIと組み合わせるとより効果的ということでしょうか？
これも近いうちにやってみたいと思いますが、
私のちょっと前のwordpressがnginxでopcache&php-fpmの構成でした。
さて、php5.3とphp5.5の速度で
FastCGI + OPcache > FastCGI + APCになるとおもいます。
|
| Re: FastCGIについて ( No.8 ) |
- 日時： 2014/06/06 16:15
- 名前： りり
- >php5.5をつかったほうが処理能力はあがりますね。
なるほど…くりくりさんのブログに詳しく書かれていますね。
他にリバースプロキシーの効果が凄いみたいなことも…
OPcacheは、php5.5.12での数値向上がはっきりしていますね。
だから、Xserverでは、
>「APC」はPHP5.3 / PHP5.4のみ、「OPcache」はPHP5.5でのみご利用可能です。
と、PHP5.4からOPcacheに対応させているのかしらね。
>>FastCGIと組み合わせるとより効果的ということでしょうか？
>これも近いうちにやってみたいと思いますが、
>私のちょっと前のwordpressがnginxでopcache&php-fpmの構成でした。
>さて、php5.3とphp5.5の速度で
>FastCGI + OPcache > FastCGI + APCになるとおもいます。
はい。結果を楽しみにしてます。
|
| Re: FastCGIについて ( No.9 ) |
- 日時： 2014/06/11 13:59
- 名前： くりくり
- こんにちは
うーん、php-fpmとmod_fastcgiですが、
参考サイトをみてみますと
phpをcgiでうごかしたりと変更を加えて色々改造するみたいですが
うまくいきません。
個人のサーバーならともく安定性を重要視するなら
使えそうな技術ではありません。
それを実用化してるXserverは流石です。
|
| Re: FastCGIについて ( No.10 ) |
- 日時： 2014/06/12 07:59
- 名前： りり
- Xserverがどのようにしているのかは分からないですが、全体的に、ユーザーが設定すると、例えば、FastCGI使用とかに設定すると、そのユーザーのドメインの.htaccessが、それ用に書き換えられるようです。
ですから、全てが同じ動きでは無く、ユーザー毎に設定されるんですね。
.htaccessの書き換えも、それまでに使っていた設定があれば、それに追加する形で書き加えられます。
なので、自分で.htaccessを編集するときは、注意が必要なんですね。
サーバ側が追加した記述を消さないようにしないとなりません。
以前、WordPressのマルチサイトを試したとき、マルチにするには、.htaccessをこう書けという指示があって、そのとき、置き換えてしまってphpのバージョンの記述を消してしまったことがありました。マルチサイトには、新しいphpでないとダメで…ということで、堂々巡りをし、気づいて、phpのバージョンの記述を残してマルチサイトに必要な記述を入れました。
Xserverは、.htaccessをいじれない人でも、コントロールパネルで設定したら、いろいろと活用できるようにしているんですね。
これは、レンタルサーバにより、いろいろと仕組みがあるようです。
くりくりさんのブログに書かれている試行は、難しくて良く分からないのですが、htmlのみのユーザーとWordPressのみのところと、多分、サーバの動き方の理想も違う気がしたのですが、そうした棲み分け方なんか、どうなんでしょうかね？
そういう棲み分けを考えて、Xserverなども、WordPressに特化したレンタルサーバを打ち出したのかもしれません。
|
| 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について