為什么Apache Event MPM表現不佳？

Question

事件MPM與Nginx的設計並不完全相同，但顯然旨在使Keepalive更加穩定並更快地發送靜態文件。 我的理解是事件MPM有點用詞不當，因為：

1. 雖然連接傳遞給kqueue / epoll，
2. 某些非常重要的模塊，如mod_gzip和mod_ssl，將阻塞/使用一個線程，直到響應完成，
3. 這對於大型文件來說是一個問題，但可能不適用於PHP生成的HTML文檔等。

不幸的是，Apache一直在失去市場份額，大多數基准測試都是MPM事件的詛咒。 基准測試是否存在缺陷，或者事件MPM對Nginx的影響是否真的如此糟糕？ 即使有這些限制，在正常流量（非惡意）和較小的文件下，它應該與Nginx有一定的競爭力。 例如，它應該在慢速連接上通過php-fpm為PHP生成的文檔提供競爭，因為文檔將被緩沖（即使是ssl'd和gzip）並且是異步發送的。 使用壓縮或不使用壓縮的SSL和非SSL連接的工作方式與Nginx在此類工作負載上的工作方式不同。

那為什么它不會在各種基准測試中閃耀？ 它出什么問題了？ 或者基准測試有什么問題？ 是一個主要的網站使用它作為它可以執行的權威的訴求？

Answer 1

它比nginx慢，因為帶有事件MPM的Apache（非常）大致相當於Apache與工作者MPM之前的事件驅動的HTTP代理（nginx，varnish，haproxy）。 事件是工作者，但事件MPM的線程將連接交給一個輔助線程，將其推送到隊列或關閉它，如果keep-alive關閉或已經過期，而不是將每個新連接交給一個線程。

事件優於工人的真正好處是資源使用。 如果需要維持1,000個並發連接，則worker MPM需要1,000個線程，而事件MPM可能會在事件隊列中管理100個活動線程和900個空閑連接。 事件MPM將在該假設中使用工作者MPM的一小部分資源，但缺點仍然存在：每個請求都由一個必須由內核調度的單獨線程處理，因此將產生轉換背景。

另一方面，我們有nginx，它使用事件模型本身作為其調度程序。 Nginx只需處理每個連接上的盡可能多的工作，然后再繼續下一個連接。 無需額外的上下文切換。

事件MPM真正發揮作用的一個用例是處理在Apache中運行繁重應用程序的設置，並且為了節省在保持活動期間空閑的線程的資源，您將部署代理（例如nginx）在阿帕奇面前。 如果您的前端沒有其他用途（例如靜態內容，代理到其他服務器等等），MPM事件可以很好地處理該用例並且無需代理。

Answer 2

對我而言，主要的操作差異在於：

• 處理程序（負責生成響應的插件）是同步的 - 如果它們執行計算或I / O，它們將占用一個線程
• 核心必須使用跨線程鎖來保護關鍵數據結構，因為它是多線程的，以支持這么多的這些同步請求

這就是為什么在非常大量的服務器上，例如nginx（或Apache Traffic Server或任何現代商業/高性能代理）通常會出現。

IMO你的問題中的子彈有點偏離標志，SSL和deflate對這里的差異沒有太大貢獻，因為它們都是過濾器，它們並沒有真正導致可擴展性問題，甚至將httpd與其傳統的API保證聯系在一起請求或連接的生命周期。 像這樣的過濾器（與處理程序或負責低級I / O的核心過濾器）可能是與處理模型相關的最少的事情。

但是，除了最極端的工作負載或極端受限的系統之外，我還認為它的表現並不差。 由於某種原因，我見過的大多數基准都質量極差。

我認為很大程度上人們希望他們今天所謂的網絡服務器是更復雜的應用服務器（Java EE，PHP等）的代理，並且設計用於在沒有API行李的情況下最有效地移動I / O的服務器將具有優勢。