Apache MPM event

與 Worker MPM 的關係

event 基於 worker MPM，實作混合多重程序多執行緒伺服器。單一路由程序 (父程序) 負責啟動子程序。每個子程序建立 ThreadsPerChild 指令中指定的固定伺服器執行緒數目，同時建立一個監聽程序執行緒，用於監聽連線，並在連線抵達時傳遞給工作執行緒處理。

執行時期設定指令與 worker 提供的指令相同，僅新增 AsyncRequestWorkerFactor。

運作方式

此 MPM 嘗試修正 HTTP 中的「保持存活問題」。當客戶端完成第一項要求後，其可以維持連線開啟，透過同一 socket 傳送進一步的要求，並在建立 TCP 連線時節省大量的額外負擔。然而，Apache HTTP 伺服器傳統上會讓整個子程序或執行緒持續等待來自客戶端的資料，這也帶來自身的缺點。為了解決這個問題，此 MPM 使用一個專屬的監聽執行緒執行每個程序，用於處理監聽 socket，所有處於保持存活狀態的 socket，已由處理常式和通訊協定過濾器完成其工作，以及僅剩將資料傳送給客戶端的 socket。

這個新架構善用非阻擋 socket 和 APR 揭露的現代核心功能（如 Linux 的 epoll），不再需要設定mpm-accept Mutex 來避免驚群現象。

單一程序/執行緒區塊可以處理的總連線數由 AsyncRequestWorkerFactor 指令調整。

非同步連線

非同步連線需要一個固定的專屬工作執行緒和先前的 MPM，但 event 不需要。mod_status 的狀態頁面會在非同步連線區段中顯示新的欄位

撰寫

在將回應傳送至用戶端時，可能會發生 TCP 寫入緩衝區填滿，因為連線過於緩慢。通常在此情況下，write()至套接字會傳回EWOULDBLOCK或EAGAIN在閒置一段時間後才能再次寫入。持有套接字的工作執行緒或許能夠將等候中的任務卸載至偵聽執行緒，而偵聽執行緒將在套接字提出事件後（例如，「套接字現在可寫入」）將其重新指派至第一個可用的閒置工作執行緒。請檢查限制區段以取得更多資訊。

保持連線

保留連線處理是工作執行緒 MPM 的最基本改善。一旦工作執行緒完成將回應傳送至用戶端，它便會將套接字處理卸載至偵聽執行緒，而偵聽執行緒進而會等候來自作業系統的任何事件，例如「套接字可讀取」。如果有任何新要求來自用戶端，接著偵聽器將其轉發至第一個可用的工作執行緒。反之，如果KeepAliveTimeout發生，那麼套接字將由偵聽器關閉。如此一來，工作執行緒不必負責閒置套接字，而可以重新用於處理其他要求。

關閉

有時候 MPM 需要執行持續性的關閉，亦即在仍持續將資料傳輸至 httpd 時傳送早期錯誤給用戶端。傳送回應，然後立即關閉連線不是正確的做法，因為用戶端（仍嘗試將要求的其餘部分傳送出去）會得到連線重設，而且無法讀取 httpd 的回應。持續性的關閉有時間限制，但可能會花費相對長的時間，因此它會卸載至一個工作執行緒（包括中斷掛鉤和真正的套接字關閉）。從 2.4.28 開始，當連線最終計時逾時時也會發生這種情況（偵聽執行緒除了等候並調度其事件之外，絕不會處理連線）。

這些改善對 HTTP/HTTPS 連線皆有效。

優雅的程序終止和計分板用量

此 MPM 早期顯示出某些可擴充性瓶頸，導致出現下列錯誤：「計分板已滿，未達 MaxRequestWorkers 值」。MaxRequestWorkers 會限制在任何特定時間點提供的同時請求數，以及允許的程序數 (MaxRequestWorkers / ThreadsPerChild)；同時，計分板會顯示所有執行中程序以及它們的工作執行緒狀態。如果計分板已滿 (所以所有執行緒皆為非閒置狀態)，但提供的活動請求數未達 MaxRequestWorkers，表示其中某些執行緒會封鎖本可提供但反而是排隊等候的新請求 (其上限由 ListenBacklog 設定)。大部分時候，執行緒會停留在 Graceful 狀態，表示它們正在等候完成與 TCP 連線相關的工作，以安全地終止並釋出計分板插槽 (例如，處理長時間執行之請求、速度很慢的客戶端，或已啟用保持連線功能的連線)。最常見的是發生下列兩個情況

• 在 優雅重啟的過程中，父程序會發訊號指示所有子程序完成自己的工作並終止，並同時重新載入組態並分支產生新程序。如果舊的子程序在停止前繼續執行一段時間，計分板會部分被佔據，直到它們的插槽被釋出為止。
• 伺服器負載會下降，讓 httpd 會停止一些程序 (例如，因為 MaxSpareThreads)。這特別容易發生問題，因為當負載再次增加時，httpd 會嘗試啟動新程序。如果此模式會不斷重複，程序數可能會增加不少，最終變成一堆舊程序嘗試停止，而新程序則嘗試執行某些工作。

從 2.4.24 開始，mpm-event 變的更聰明，能夠以更好的方式處理優雅終止。部分改進如下

• 允許使用所有計分板插槽，上限為 ServerLimit。MaxRequestWorkers 和 ThreadsPerChild 會用於限制活動程序的數量；同時，ServerLimit 也會考慮正在執行優雅關閉的程序，以在需要時允許有額外的插槽。其構想是使用 ServerLimit 指示 httpd 在影響系統資源之前，整體可以承受多少程序。
• 強迫優雅完成的程序關閉它們在保持連線狀態下的連線。
• 在優雅關閉期間，如果執行中工作執行緒的數量多於已開啟連線，針對特定程序終止這些執行緒以更快釋出資源 (新程序可能會需要這些資源)。
• 如果計分板已滿，則因負載降低而中斷更多流程的順利完成，直到舊流程終止為止（否則，一旦負載再度增加，狀況就會惡化）。

上一個重點中所述的行為可透過 mod_status 中連線摘要表格的兩個新欄位「スロット」和「正在中斷」完整觀察到。前者指示 PID，而後者指示處理程序是否正在中斷；額外的狀態「是 (舊世代)」指示處理程序在順利重新啟動後仍在執行。

限制

改良過的連線處理可能不適用於已宣稱與事件不相容的特定連線篩選器。在這些情況中，此 MPM 會回復為 worker MPM 的行為，並為每個連線保留一個工作執行緒。與伺服器一起配送的所有模組與事件 MPM 相容。

目前的類似限制用於包含輸出篩選器的要求，而輸出篩選器需要讀取和/或修改整個回應本體。如果當篩選器正在處理資料時伺服器端連線遭到封鎖，且篩選器產生的資料量過大而無法緩衝在記憶體中，則用於該要求的執行緒不會在 httpd 等待將待處理資料傳送至伺服器端時釋放。
舉例來說，我們可以考慮以下兩個情況：提供靜態資產（例如 CSS 檔案）相較於提供從 FCGI/CGI 或代理伺服器擷取的內容。前者可以預測，換言之，事件 MPM 對內容結束具有完全的可視性，且可以使用事件：提供回應內容的工作執行緒可以在傳回 EWOULDBLOCK 或 EAGAIN 之前清除第一個位元組，委派其餘部份給監聽器。監聽器依序等待 socket 上的事件，並委派工作將內容的其餘部份清除至第一個閒置工作執行緒。同時，在後一個範例（FCGI/CGI/代理內容）中，MPM 無法預測回應結束，且工作執行緒必須在將控制權回傳給監聽器之前完成其工作。唯一的替代方法是將回應緩衝在記憶體中，但這並非為顧及伺服器穩定性和記憶體使用量而能採行的最安全選項。

背景資料

事件模型得以實現是由於新的 API 導入到所支援作業系統中

• epoll (Linux)
• kqueue (BSD)
• 事件埠 (Solaris)

在這些新 API 可用之前，必須使用傳統的 select 和 poll API。如果用於處理許多連線或是連線的速率很高，這些 API 會變慢。新的 API 能夠監視更多的連線，並且當要監視的連線組經常變更時，它們的執行效能會好很多。因此，這些 API 能夠寫出事件 MPM，這種 MPM 比較容易擴充到有許多閒置連線的典型 HTTP 模式。

MPM 假設底層的 apr_pollset 實作足夠安全。這能讓 MPM 避免過度的高層鎖定，或是為了寄送保持連線 Socket 而喚醒偵聽器執行緒。目前這只與 KQueue 和 EPoll 相容。

需求

此 MPM 依賴於 APR 的原子比較及交換運算執行緒同步。如果您要編譯 x86 目標而且不需要支援 386，或是您要編譯 SPARC 而且不需要在 UltraSPARC 之前的晶片上執行，請將 --enable-nonportable-atomics=yes 加入 configure 指令碼的引數。這將導致 APR 使用舊有 CPU 中不存在的有效運算碼來實作原子運算。

此 MPM 在缺乏良好執行緒的舊平台上無法良好執行，但因為 EPoll 或 KQueue 的需求，這一點沒有異議。

• 要在 FreeBSD 上使用此 MPM，建議使用 FreeBSD 5.3 或更新的版本。不過，如果您使用 libkse，還是有可能在 FreeBSD 5.2.1 上執行此 MPM (請參閱 man libmap.conf)。
• 對於 NetBSD，建議至少使用版本 2.0。
• 對於 Linux，建議使用 2.6 核心。您也必須確定您的 glibc 版本已編譯並支援 EPoll。

ThreadsPerChild = 10
ServerLimit = 4
AsyncRequestWorkerFactor = 2
MaxRequestWorkers = 40

idle_workers = 4 (average for all the processes to keep it simple)

max_connections = (ThreadsPerChild + (AsyncRequestWorkerFactor * idle_workers)) * ServerLimit
                = (10 + (2 * 4)) * 4 = 72

ThreadsPerChild = 10
ServerLimit = 4
MaxRequestWorkers = 40
AsyncRequestWorkerFactor = 2

idle_workers = 10

max_connections = (ThreadsPerChild + (AsyncRequestWorkerFactor * idle_workers)) * ServerLimit
                = (10 + (2 * 10)) * 4 = 120

max_connections = (AsyncRequestWorkerFactor + 1) * MaxRequestWorkers
                = (2 + 1) * 40 = 120