2010年代には Apache の mpm_prefork とか流行らない (もしくは HTTP keep-alive のメリットとデメリット) - kazuhoのメモ置き場

HTTP の持続的接続の功罪について はじめに、HTTP の持続的接続 (keep-alive) のメリットについて。持続的接続を使うメリットは、以下の２点。 TCP 接続の確立にかかる時間の節約*1 TCP の接続と切断に必要な資源 (CPUとネットワーク) の節約 ウェブブラウザ〜データセンタ間の通信で、持続的接続を使う理由は、このうちの前者。特に太平洋を超えるようなケースだと、TCP 接続に0.2秒とかかかるので、メリットが大きい。 一方、持続的接続のデメリットは、 接続が切断されるまでの間、その接続を維持するためにコストがかかる (主としてメモリが無駄になる) という点になる。特に、１プロセス１コネクションを前提とするアーキテクチャ (例: mod_perl) だと、メモリの無駄使いが、とてもひどいことになる。 そこで、ブラウザからの接続を受ける HTTP サーバとアプリケーション

[escape_artist]

PHPだとPHP-FPM(FastCGI)に移ってきてる感じかな

[hiro_y]

「メリットは、時間 (レイテンシ) と、CPUおよびネットワーク資源の節約にある。だが、リバースプロキシとアプリケーションサーバは同一データセンタ内に配置するわけだから、レイテンシを気にする必要はない。」

[orangevtr]

Perlとかだと軽量なAPサーバーいろいろあるから最早Apache+mpm_preforkとか重いの使わなくていいよねって理解でおｋ？逆にPHPだとAPサーバーとしてはApache+mpm_preforkかFastCGIの他にあるのかな。

[yuichiro0526]

[]

[ikeikeikeike]

釣られた感がするのは俺だけじゃないはず

[nekoruri]

mpm_preforkの存在意義が無い(ただしPHPを除く)のには同意。でも、省略すると書いてあるとはいえHTTP Pipeliningの効果は実際どれぐらいあるんだろう。HTTP Keep-Aliveを無効にするかどうかはそれ次第じゃないかなあ。

[rochefort]

KeepAliveTimeout 1ってやる場合があるが、そもそもpreforkが問題と。mod_proxy_balancerだと、keepaliveが有効なようです。http://www.onflow.jp/cyano/archives/101　apache難しいな。

[terazzo]

自分の印象ではソケット接続確立はコスト高め(主にレスポンスタイムで)なのでKeep-aliveは重要。／アプリプロセス側をCometみたいに大量コネクション/少量ワーカーなモデルにできないかな。

[mtetsuka]

備忘。

[mattn]

keep-alive の dead or alive

[toton]

KeepAliveTimeout 1秒じゃダメなんだろうか/apacheのマニュアル見直したらタイムアウト単位が英語(http://bit.ly/aXCXe7)だとmsで指定可能だった。 日本語は(http://bit.ly/bnsZwU)。50msとかじゃダメかな。

[kmachu]

WebブラウザとフロントWebサーバ間はkeep-aliveが有効→同時接続数が増える→mpm_preforkだとメモリが増える→マルチスレッド等が有利 / バックエンドは組み込みHTTPサーバでいいよね、という話。 / PHPだとFastCGIなのかな？うーん

[hirose31]

keepalive