使用 libevent 和 libev 提高網絡應用性能的方法

2019-11-02 16:11:10

字體：大中小

來源：轉載

供稿：網友

有許多解決方案，但是 libevent 庫和 libev 庫能夠大大提高性能和事件處理能力。在本文中，我們要討論在 UNIX® 應用程序中使用和部署這些解決方案所用的基本結構和方法。libev 和 libevent 都可以在高性能應用程序中使用，包括部署在 IBM Cloud 或 Amazon EC2 環境中的應用程序，這些應用程序需要支持大量并發客戶端或操作。

簡介

許多服務器部署（尤其是 web 服務器部署）面對的最大問題之一是必須能夠處理大量連接。無論是通過構建基于云的服務來處理網絡通信流，還是把應用程序分布在 IBM Amazon EC 實例上，還是為網站提供高性能組件，都需要能夠處理大量并發連接。

一個好例子是，web 應用程序最近越來越動態了，尤其是使用 AJAX 技術的應用程序。如果要部署的系統允許數千客戶端直接在網頁中更新信息，比如提供事件或問題實時監視的系統，那么提供信息的速度就非常重要了。在網格或云環境中，可能有來自數千客戶端的持久連接同時打開著，必須能夠處理每個客戶端的請求并做出響應。

在討論 libevent 和 libev 如何處理多個網絡連接之前，我們先簡要回顧一下處理這類連接的傳統解決方案。

處理多個客戶端

處理多個連接有許多不同的傳統方法，但是在處理大量連接時它們往往會產生問題，因為它們使用的內存或 CPU 太多，或者達到了某個操作系統限制。

使用的主要方法如下：

循環：早期系統使用簡單的循環選擇解決方案，即循環遍歷打開的網絡連接的列表，判斷是否有要讀取的數據。這種方法既緩慢（尤其是隨著連接數量增加越來越慢），又低效（因為在處理當前連接時其他連接可能正在發送請求并等待響應）。在系統循環遍歷每個連接時，其他連接不得不等待。如果有 100 個連接，其中只有一個有數據，那么仍然必須處理其他 99 個連接，才能輪到真正需要處理的連接。

poll、epoll 和變體：這是對循環方法的改進，它用一個結構保存要監視的每個連接的數組，當在網絡套接字上發現數據時，通過回調機制調用處理函數。poll 的問題是這個結構會非常大，在列表中添加新的網絡連接時，修改結構會增加負載并影響性能。

選擇：select() 函數調用使用一個靜態結構，它事先被硬編碼為相當小的數量（1024 個連接），因此不適用于非常大的部署。

在各種平臺上還有其他實現（比如 Solaris 上的 /dev/poll 或 FreeBSD/NetBSD 上的 kqueue），它們在各自的 OS 上性能可能更好，但是無法移植，也不一定能夠解決處理請求的高層問題。

上面的所有解決方案都用簡單的循環等待并處理請求，然后把請求分派給另一個函數以處理實際的網絡交互。關鍵在于循環和網絡套接字需要大量管理代碼，這樣才能監聽、更新和控制不同的連接和接口。

處理許多連接的另一種方法是，利用現代內核中的多線程支持監聽和處理連接，為每個連接啟動一個新線程。這把責任直接交給操作系統，但是會在 RAM 和 CPU 方面增加相當大的開銷，因為每個線程都需要自己的執行空間。另外，如果每個線程都忙于處理網絡連接，線程之間的上下文切換會很頻繁。最后，許多內核并不適于處理如此大量的活躍線程。

libevent 方法

libevent 庫實際上沒有更換 select()、poll() 或其他機制的基礎。而是使用對于每個平臺最高效的高性能解決方案在實現外加上一個包裝器。

為了實際處理每個請求，libevent 庫提供一種事件機制，它作為底層網絡后端的包裝器。事件系統讓為連接添加處理函數變得非常簡便，同時降低了底層 I/O 復雜性。這是 libevent 系統的核心。

libevent 庫的其他組件提供其他功能，包括緩沖的事件系統（用于緩沖發送到客戶端/從客戶端接收的數據）以及 HTTP、DNS 和 RPC 系統的核心實現。

上一篇：訪問asp頁面出現出現“請求的資源在使用中”的解決辦法

下一篇：pear包安裝phpunit的方法