worker MPMの設定

MPMは、Apache 2.4でのデフォルトは event MPMになる。

event MPMは Apache 2.2で追加になったが、長らくexperimentalという位置づけだった。

機能的には worker MPMの改善版となるので、 機能的/性能的にはもっとも優位となるだろう。

問題は品質面の評価だが、少なくとも実績という観点では他のMPMに劣ると考えられる。

デフォルトであるevent MPMの設定から見ていきたいが、event MPMはほとんどの設定がworker MPMと共通だ。

そこで、歴史的な順序に従い、まず、worker MPMの設定から見ていく

まず、前提として、Apacheの設定と言うのは、設定ファイルに書く。

普通はインストールしたディレクトリの conf/httpd.conf とかいったファイルだ。

テキストファイルで、普通のテキストエディタで編集すればよい。

たとえば、下記。

DocumentRoot    /usr/local/apache/htdocs

最初の "DocumentRoot" が設定する項目名で、ディレクティブ、と呼んでいる。

つづく、"/usr/local/apache/htdocs" はその設定値。

ディレクティブがとる値は、1つだったり2つだったり、ディレクティブによって異なる。

設定の話では、このディレクティブの説明をしていく。

clogging_input_filters

ちょっと細かい話をメモ。
clogging_input_filtersはconn_recの変数。

この変数が0でない場合、event MPMと非互換である(worker MPMと同様にワーカスレッドを通信中に占有する)。

create_connフック関数であるcore_create_conn()において、clogging_input_filters=0がセットされている。

httpd-2.4.7では、0以外がセットされている箇所は見当たらない。

2.3.4-alphaでは、ssl_engine_io.cで1をセットしていた。

   1707 void ssl_io_filter_init(conn_rec *c, request_rec *r, SSL *ssl)
   1708 {
　　：
   1724     /* We insert a clogging input filter. Let the core know. */
   1725     c->clogging_input_filters = 1;
　　：
   1741     return;
   1742 }

つまり、sslの扱いが変わっている。

あれ、いつ上記のコードが消えたのか？

追加はここ

http://svn.apache.org/viewvc?view=revision&revision=546328

消えたのはここ

http://svn.apache.org/viewvc?view=revision&revision=1515476

最近だった。

Changes with Apache 2.4.7

  *) core, mod_ssl: Enable the ability for a module to reverse the sense of
     a poll event from a read to a write or vice versa. This is a step on
     the way to allow mod_ssl taking full advantage of the event MPM.
     [Graham Leggett]

なんだか、しれっとevent MPMでssl扱えるようになっているよ。

ただし、このフラグ自体は残されている。

event MPMに非互換のモジュールであることを識別する用途で使われるようだ。

MPMのことのつづき

さてさて。

いずれのMPMであっても、同時に処理できるリクエスト数は、リクエスト処理を行うワーカスレッド数(prefork MPMの場合はプロセス数)で制限される。

同じ数の同時リクエスト処理能力を用意する場合、一般にはプロセス型MPMの方がスレッド型MPMよりもリソースの消費量は多くなるはず。

プロセス自体がスレッドより多量のリソースを消費し、実行されるプロセス数は、同じ同時リクエスト処理能力の場合、プロセス型の方がスレッド型より多いのであるから、仕方がない。

また、処理で必要なメモリについても、スレッド型であれば、同じプロセス空間内でワーカスレッド数分が共有できるメモリも、プロセス型では共有できないことから、やはり消費量が増える傾向にあるだろう。

他方、プロセス型が優位な点は何かと言うと、これは一般的な評価ではないかもしれないが、Apacheが、たとえば脆弱性などへの攻撃によってクラッシュさせられた場合、スレッド型の場合は、同じプロセスで同時に処理されていた別のリクエストも巻き添え被害を受けて異常終了してしまうが、プロセス型の場合はその攻撃を行ったリクエストが終了するだけで他のリクエストには被害が及ばないという点を上げてもよいだろうと思う。

処理構成については、図版を用意したいが、今のところ用意できていない。

とりあえず、この先少しこれらMPMの処理に関わる設定を見ていこうと思っている。

マルチプロセシングモジュールとかから

Apache HTTPサーバのリクエスト処理は、サーバとしてリクエストを待ち受け、受け付けたリクエストを処理し、応答を返す、という流れを持っている。

そして、この受け付けたリクエストの処理のために別途スレッドを生成するかどうかで、スレッド型かプロセス型かといった区別がある。

Apacheはこの処理の区別をMPM(マルチプロセシングモジュール)という名称でモジュール化し、複数の種別から自由に選択できるようにした。

とは言え、Windows用にはwinnt MPMしかないのではないか（よく知らない）。

このメモではLinuxベースで話を進めるので、Widowsなど他の環境で利用されるMPMについては書かない。知らないからだけど。

ちなみに、Apache 2.0/2.2では使用するMPMの選択は、INSTALLにおけるconfigure時に行っていたが、Apache 2.4では、実行時の設定による選択も可能になった。

Apacheは起動シーケンスにおいて、実行するMPMごとに異なるリクエスト処理方式を採用する。

親プロセスが起動され、共通的な作業として、設定ファイルの読み込みや、各種の初期処理（ログファイルのオープンやリクエスト受付け用のLisnteポートの設置を含む）が行われた後、ループ処理に入り、MPMの主処理を実行する。

prefork MPM

プロセス型でリクエストを処理するMPMとなる。

MPMの主処理内では子プロセスの生成が行われる。

子プロセスはプロセス毎にリクエストの待ち受けの監視、リクエスト受付後のリクエスト処理、レスポンスの送信の一連の処理を行っている。

worker MPM

スレッド型でリクエストを処理するMPMとなる。

MPMの主処理内では、preforkと同様に子プロセスの生成が行われる。

子プロセスはプロセス内でリクエスト待ち受けの監視用のリスナスレッドを１つと、受け付けたリクエストを処理しレスポンスを返すワーカスレッドを1つ以上用意する。

受け付けられたリクエストはスレッドで共有されたワーカーキューを介して、リクエスト待ちにあるワーカスレッドに引き渡される。

event MPM

スレッド型でリクエストを処理するMPMとなる。

worker MPMでは、HTTP keep-alive機能を利用した場合に、リクエスト処理ワーカスレッド

が次のリクエストを受け取るまで処理待ち状態のまま保持されてしまう。つまり、本来リ

クエスト処理可能なワーカスレッドのリソースが無駄になっている。

そこで、無駄になっているワーカスレッドのリソースをkeep-alive状態でのリクエスト待ちから解放し、新たなリクエストの処理を受け入れられるようにしたものが、event MPMということ(コメントを読む限りはね)。


ここまで

はじめてみた

Apache HTTPサーバの2.4系について機能とか調べてまとめていこうと思っているが、

なかなか全部出来上がるとは思われない。

できた断片、メモをそのままここに載せていけば、だんだん固まってくるんじゃないかとか、

それに、ここに何がしかのアウトプットができて嬉しいんじゃないか、とか考えている。

自分の整理のためではあるが、誰かに見てもらえることも期待している。今のところ、どうやったら呼び込めるのかは分かっていない。

基本的にはlinuxベースの話を書く。

年頭からと思っていたのに、この有様。先が思いやられる。