爲什麼基於事件的網絡應用程序本身比線程應用程序更快？

Question

我們都已經閱讀了基準並瞭解事實 - 基於事件的異步網絡服務器比它們的線程更快。認爲lighttpd或宙斯與Apache或IIS。這是爲什麼？

Answer 1

我認爲基於事件的vs基於線程不是問題 - 它是一個非阻塞多路複用I/O，可選套接字，解決方案vs線程池解決方案。

在第一種情況下，您正在處理所有輸入，而不管使用什麼內容 - 因此讀取時不會阻塞 - 單個「偵聽器」。單個偵聽器線程將數據傳遞給可以是不同類型的工作線程的數據，而不是每個連接的線程。同樣，在編寫任何數據時不會發生阻塞，因此數據處理程序可以單獨運行。因爲這個解決方案大部分是IO讀/寫操作，所以它不佔用太多CPU時間 - 因此，您的應用程序可以通過它執行任何想要的操作。

在線程池解決方案中，您有單獨的線程處理每個連接，所以他們必須共享時間來切換上下文 - 每個人都在「傾聽」。在這個解決方案中，CPU + IO操作在同一個線程中 - 獲得一個時間片 - 所以您最終會等待IO操作完成每個線程（阻塞），傳統上這可以在不使用CPU時間的情況下完成。

谷歌爲非阻塞IO更詳細 - 你可能會發現一些比較與線程池也。

（如果有人可以澄清這些要點，請隨意）

Answer 2

這不是真的關於線程。這是關於線程用於處理請求的方式。對於像lighttpd這樣的東西，你有一個單線程通過事件爲多個連接提供服務。對於舊版本的Apache，每個連接都有一個進程，並且進程在傳入數據中醒來，所以當有大量請求時，您會得到一個非常大的數字。但是現在使用MPM apache也是基於事件的，參見apache MPM event。

Answer 3

這真的取決於你在做什麼;基於事件的編程對於非平凡應用程序來說確實很棘手。作爲一個Web服務器是一個非常普遍的問題，事件驅動和線程模型在現代操作系統上都能很好地工作。

正確地在事件模型中開發更復雜的服務器應用程序通常是相當棘手的 - 線程應用程序更容易編寫。這可能是決定因素而不是表現。

Answer 4

事件驅動的應用程序是而不是固有地更快。

從Why Events Are a Bad Idea (for High-Concurrency Servers)：

We examine the claimed strengths of events over threads and show that the 
weaknesses of threads are artifacts of specific threading implementations 
and not inherent to the threading paradigm. As evidence, we present a 
user-level thread package that scales to 100,000 threads and achieves 
excellent performance in a web server. 

這是在2003年肯定線程現代操作系統的狀態已從那時起提升。

編寫基於事件的服務器的核心意味着在您的代碼中重新開發協作式多任務（Windows 3.1樣式），很可能在已支持正確的搶先式多任務的OS上，並且沒有透明上下文切換的好處。這意味着您必須管理堆中通常由指令指針隱含或存儲在堆棧變量中的狀態。 （如果你的語言有他們，關閉可以顯着緩解這種痛苦，在C中嘗試這樣做會少得多樂趣。）

這也意味着你可以獲得所有合作多任務意味着的所有注意事項。如果其中一個事件處理程序由於某種原因需要一段時間才能運行，它將停止該事件線程。完全不相關的請求滯後。即使冗長的CPU密集型操作也必須發送到其他地方以避免這種情況。當您談論高併發服務器的核心時，「冗長操作」是一個相對術語，預計每秒處理100,000次請求的服務器的微秒數量級。我希望虛擬內存系統永遠不必爲你從磁盤中提取頁面！

從基於事件的體系結構中獲得良好性能可能會非常棘手，尤其是當您考慮延遲而不僅僅是吞吐量時。 （當然，也有很多的錯誤，你可以使用線程使以及併發還很難。）一個新的服務器應用程序的作者

幾個重要問題：

• 如何線程執行在你打算今天支持的平臺上？他們會成爲你的瓶頸嗎？
• 如果你仍然堅持一個糟糕的線程實現：爲什麼沒有人解決這個問題？