 |
||||||||||||||
|
||||||||||||||
| 前のページ 1 2 | ||||||||||||||
|
||||||||||||||
| Webサーバーのメモリ使用率 | ||||||||||||||
|
FastCGIやmod_perlでメモリ上にPerlプログラムを常駐させた場合、Webサーバーのプロセス1本あたりが使用するメモリ容量は非常に大きくなります。はてなブックマークの場合、httpdのメモリサイズは40MB以上になります。 通常Webサーバーは、クライアントからの1リクエストに対して1プロセスあるいは1スレッドでそれに応答します。高トラフィックなサイトではサーバーに対する同時アクセス数が大きくなるため、結果としてサーバー上ではWebサーバーのプロセス／スレッドが何本も立ち上がることになります。 すると、例えば40MBのプロセスが20本立ったとすると、それだけで800MBのメモリを消費してしまいます（注5）。
注5：
実際には親プロセスとの間でメモリを共有することになるので、単純に40MB ×20本という計算にはなりません。
1GBのメモリを搭載したサーバーで、Webサーバーのプロセスだけで800MBメモリを消費したとすると残りは200MB。OSが基本として必要とするメモリをここから差し引くと残りはわずか。 この状態では、メモリに余裕があればOSのキャッシュに入るであろうファイル群がキャッシュされなかったり、スワップが発生したりすることによってディスクI/Oが頻発し、極端なパフォーマンス劣化が起きてしまいます。 そこで、Webサーバーの処理のうちダイナミックなコンテンツはアプリケーションサーバーで、それ以外のスタティックなコンテンツは専用のWebサーバーで行うように役割を分離して対応するのが定番です。この後者の役割を担うのがリバースproxyです。 リバースproxyは、アプリケーションサーバーの前に配置されるサーバーです。リバースproxyという名前から特殊なソフトウェアを想像してしまいますが、なんのことはない、普通のWebサーバーです。クライアントから受け取ったリクエストのうち、画像などのスタティックなドキュメントは自分で返し、ダイナミックなコンテンツはアプリケーションサーバーに処理を転送するという点が通常のWebサーバーと異なります。 クライアントから、Perlプログラムが生成する必要のある動的なコンテンツ、すなわちダイナミックコンテンツの要求があった場合、
といった流れで処理が行われます。 一方、Perlプログラムを必要としないスタティックなドキュメント、つまり画像やスタイルシートなどのファイルは、リバースproxy自身が直接クライアントに返します。クライアントからのリクエストはまずリバースproxyで受け取り、そのリクエストが要求するドキュメントがスタティックであるかダイナミックであるかで転送の判断をする、というわけです。 このように、アプリケーションサーバーとクライアントの間に挟まって処理を代理で行う（proxyする）のがリバースproxyです。 リバースproxyはダイナミックコンテンツを処理しなくても良いため、mod_perlを組み込む必要もありませんし、Perlプログラムを実行する必要もありません。したがって、サーバープロセス1本あたりのメモリ使用量はかなり小さくなります。 そのため、大量の同時アクセスが来た場合にも、リバースproxyならたくさんのプロセスを生成してそれに応答することができます。後ろに控えるアプリケーションサーバーはダイナミックコンテンツを生成する働きだけをすれば良く、手前にいるリバースproxyが多くの処理を行うバッファとして機能する形になるわけです。 Apacheでリバースproxyを構築する場合は、mod_rewriteとmod_proxyを使います。 |
||||||||||||||
|
前のページ 1 2 |
||||||||||||||
|
|
||||||||||||||
|
||||||||||||||
|
|
||||||||||||||
|
||||||||||||||
|
|
||||||||||||||
|
||||||||||||||
-
-
連載
