event MPMのタイムアウトキュー

event MPMには4つのタイムアウトキューが存在する。

タイムアウトまでの経過時間別にキューが用意されているため、タイムアウトイベントの登録は、末尾に行われる。登録された順に、タイムアウト時間が経過することになる。キューという呼び名の通り、タイムアウト時刻が経過しているかどうかは先頭から確認される。
タイムアウトの発生前に、待っているイベント（ソケットの受信や送信）が発生すれば、各タイムアウトキューからその情報は除去される。

(1) write_completion_q

• レスポンスの送信が未完了な場合に利用される。 
• TimeOut でのタイムアウト待ちキュー。 
• TimeOut 経過前に書き込み可能になったら、書き込み処理がworkerスレッドで実行される。 
• TimeOut 経過した場合、ソケットのwrite側をshutdownし、linger_qでクローズ待ちする。 

(2) keepalive_q

• レスポンス送信完了後の次リクエスト受信待ちに利用される。 
• KeepAliveTimeOut でのタイムアウト待ちキュー。 
• KeepAliveTimeOut 経過前に読込可能になったら、リクエスト処理がworkerスレッドで実行される。 
• KeepAliveTimeOut 経過した場合、ソケットのwrite側をshutdownし、linger_qでクローズ待ちする。 

(3) linger_q

• ソケットのwrite側のshutdown後の、FIN待ちに利用される。 
• MAX_SECS_TO_LINGER(30秒) でのタイムアウト待ちキュー 
• MAX_SECS_TO_LINGER 経過前に読込可能になったら、読み捨て処理を行い、ソケットをクローズする 
• MAX_SECS_TO_LINGER 経過した場合、ソケットをクローズする 

(4) short_linger_q

• ソケットのwrite側のshutdown後の、FIN待ちに利用される。 
• SECONDS_TO_LINGER(2秒) でのタイムアウト待ちキュー 
• notesに"short-lingering-close"は存在した場合に、linger_qではなく、こちらを使用する。 
• mod_reqtimeoutで受信タイムアウト時に指定されていた。他は見当たらない。 
• SECONDS_TO_LINGER 経過前に読込可能になったら、読み捨て処理を行い、ソケットをクローズする 
• SECONDS_TO_LINGER 経過した場合、ソケットをクローズする

これらのタイムアウト待ちもworker MPMでは、workerスレッド内で待っていたが、event MPMでは、タイムアウトキューに登録し、また、対応するソケットを (centos5では)epollの監視対象に追加し、listenerスレッドで待ち受けを行うようになった。
これにより、workerスレッドの無駄な待ち時間が削減され、結果的に処理効率が改善したと考えられる。
KeepAliveTimeOutの待ち時間以外の改善個所もあることから、KeepAliveを利用していない場合にも性能改善が見られたのはこの効果ではないかと考えている。

ちなみに、KeepAlive Onで実行していると、レスポンスを返した後、ソケットはkeepalive_qに入るが、もしクライアントが直ちにソケットを閉じた場合、listenerスレッドはソケットが読込可能になったことを検知し、workerスレッドに引き渡す。その後、workerスレッドが読み込むと、EOFが検知されることになる。