Board logo

標題: [轉貼] Apache 2.0 性能優化 [打印本頁]

作者: adj    時間: 2007-11-30 13:17     標題: Apache 2.0 性能優化

http://www.kuanshan.com.tw/simple/index.php?t15136.html


Apache 2.0性能優化
              ————MPM的選擇與配置
作者:◇ 邢飛 甄廣啟   本文選自:開放系統世界 2003年05月27日

  談到Apache,大多數系統管理員對其穩定版1.3印象頗深。雖然Apache 2.0的系列開發版早已由Alpha、Beta發展到現在的GA(General Availability)版,但是一些人潛意識裡還認為開發版並非可用於生產環境的穩定版本。尤其是1.3版的API與2.0版不兼容,使得大量模塊必須要重寫才能在2.0版上使用。Apache 1.3和2.0之間的內部變化的確較大,用Apache創始人Brian Behlendorf自己的話來說:「這個版本包括了數百個新的特性,所以這個產品應該具有3.1或8i這樣的產品編號,而不是2.0。」Apache 2.0中加入了很多的核心改進和新功能,如Unix線程、多協議支持、新的構建系統、對非Unix平台的更佳支持、IPv6支持、新的Apache API、過濾器、多語言錯誤響應、原生的Windows NT Unicode支持、更簡單化的配置,以及升級的正則表達式庫等。它當然還包括對許多模塊的重要改進,同時也加入了一些新的模塊。

  為了使Apache更加平滑地從1.3版升級到2.0版,Apache開發團隊做了很多工作。目前很多重要的模塊已經可以很好地支持2.0版,如PHP、FastCGI、Mod_perl、Mod_python等。在httpd.conf的指令配置語法上,目前的2.0版(2.0.45)與1.3版的兼容性已做得相當好。比如,以前的2.0版如果要使用PHP,一般用過濾器實現;現在的PHP官方文檔中已經使用1.3版中的LoadModule語句做為加載PHP的推薦方式。只要略微瞭解一下Apache 2.0的新特性,從1.3版升級到2.0版將是一件非常容易的事情。使用Apache 2.0是大勢所趨,因為Apache的開發團隊已經把開發重心轉移到2.0版上。1.3版自2002年10月發佈了1.3.27後一直沒有新版本推出,而2.0版在與1.3.27同時發佈2.0.43後,在今年1月發佈了2.0.44,並於今年3月末發佈了2.0.45,並包含了很多改進和修正。

  MPM的引入帶來性能改善

  Apache 2.0在性能上的改善最吸引人。在支持POSIX線程的Unix系統上,Apache可以通過不同的MPM運行在一種多進程與多線程相混合的模式下,增強部分配置的可擴充性能。相比於Apache 1.3,2.0版本做了大量的優化來提升處理能力和可伸縮性,並且大多數改進在默認狀態下即可生效。但是在編譯和運行時刻,2.0也有許多可以顯著提高性能的選擇。本文不想敘述那些以功能換取速度的指令,如HostnameLookups等,而只是說明在2.0中影響性能的最核心特性:MPM(Multi-Processing Modules,多道處理模塊)的基本工作原理和配置指令。

  毫不誇張地說,MPM的引入是Apache 2.0最重要的變化。大家知道,Apache是基於模塊化的設計,而Apache 2.0更擴展了模塊化設計到Web服務器的最基本功能。服務器裝載了一種多道處理模塊,負責綁定本機網絡端口、接受請求,並調度子進程來處理請求。擴展模塊化設計有兩個重要好處:

  ◆ Apache可以更簡潔、有效地支持多種操作系統;

  ◆ 服務器可以按站點的特殊需要進行自定制。

  在用戶級,MPM看起來和其它Apache模塊非常類似。主要區別是在任意時刻只能有一種MPM被裝載到服務器中。

  指定MPM的方法

  下面以Red Hat Linux 9為平台,說明在Apache 2.0中如何指定MPM (Apache採用2.0.45)。先解壓縮源代碼包httpd-2.0.45.tar.gz,生成httpd-2.0.45目錄(Apache 1.3源代碼包的命名規則是apache_1.3.NN.tar.gz,而2.0版則是httpd-2.0.NN.tar.gz,其中NN是次版本號)。

  進入httpd-2.0.45目錄,運行以下代碼:

$ ./configure --help|grep mpm



  顯示如下:

--with-mpm=MPM
Choose the process model for Apache to use.
MPM={beos|worker|prefork|mpmt_os2| perchild|leader|threadpool}


  上述操作用來選擇要使用的進程模型,即哪種MPM模塊。Beos、mpmt_os2分別是BeOS和OS/2上缺省的MPM,perchild主要設計目的是以不同的用戶和組的身份來運行不同的子進程。這在運行多個需要CGI的虛擬主機時特別有用,會比1.3版中的SuExec機制做得更好。leader和threadpool都是基於worker的變體,還處於實驗性階段,某些情況下並不會按照預期設想的那樣工作,所以Apache官方也並不推薦使用。因此,我們主要闡述prefork和worker這兩種和性能關係最大的產品級MPM ( 有關其它的MPM詳細說明,請參見Apache官方文檔:http://httpd.apache.org/docs-2.0/mod/)。

  prefork的工作原理及配置

  如果不用「--with-mpm」顯式指定某種MPM,prefork就是Unix平台上缺省的MPM。它所採用的預派生子進程方式也是Apache 1.3中採用的模式。prefork本身並沒有使用到線程,2.0版使用它是為了與1.3版保持兼容性;另一方面,prefork用單獨的子進程來處理不同的請求,進程之間是彼此獨立的,這也使其成為最穩定的MPM之一。

  若使用prefork,在make編譯和make install安裝後,使用「httpd -l」來確定當前使用的MPM,應該會看到prefork.c(如果看到worker.c說明使用的是worker MPM,依此類推)。再查看缺省生成的httpd.conf配置文件,裡面包含如下配置段:

<IfModule prefork.c>
StartServers     5
MinSpareServers   5
MaxSpareServers   10
MaxClients     150
MaxRequestsPerChild 0
</IfModule>


  prefork的工作原理是,控制進程在最初建立「StartServers」個子進程後,為了滿足MinSpareServers設置的需要創建一個進程,等待一秒鐘,繼續創建兩個,再等待一秒鐘,繼續創建四個……如此按指數級增加創建的進程數,最多達到每秒32個,直到滿足MinSpareServers設置的值為止。這就是預派生(prefork)的由來。這種模式可以不必在請求到來時再產生新的進程,從而減小了系統開銷以增加性能。

  MaxSpareServers設置了最大的空閒進程數,如果空閒進程數大於這個值,Apache會自動kill掉一些多餘進程。這個值不要設得過大,但如果設的值比MinSpareServers小,Apache會自動把其調整為MinSpareServers+1。如果站點負載較大,可考慮同時加大MinSpareServers和MaxSpareServers。

  MaxRequestsPerChild設置的是每個子進程可處理的請求數。每個子進程在處理了「MaxRequestsPerChild」個請求後將自動銷毀。0意味著無限,即子進程永不銷毀。雖然缺省設為0可以使每個子進程處理更多的請求,但如果設成非零值也有兩點重要的好處:

  ◆ 可防止意外的內存洩漏;

  ◆ 在服務器負載下降的時侯會自動減少子進程數。

  因此,可根據服務器的負載來調整這個值。筆者認為10000左右比較合適。

  MaxClients是這些指令中最為重要的一個,設定的是Apache可以同時處理的請求,是對Apache性能影響最大的參數。其缺省值150是遠遠不夠的,如果請求總數已達到這個值(可通過ps -ef|grep http|wc -l來確認),那麼後面的請求就要排隊,直到某個已處理請求完畢。這就是系統資源還剩下很多而HTTP訪問卻很慢的主要原因。系統管理員可以根據硬件配置和負載情況來動態調整這個值。雖然理論上這個值越大,可以處理的請求就越多,但Apache默認的限制不能大於256。如果把這個值設為大於256,那麼Apache將無法起動。事實上,256對於負載稍重的站點也是不夠的。在Apache 1.3中,這是個硬限制。如果要加大這個值,必須在「configure」前手工修改的源代碼樹下的src/include/httpd.h中查找256,就會發現「#define HARD_SERVER_LIMIT 256」這行。把256改為要增大的值(如4000),然後重新編譯Apache即可。在Apache 2.0中新加入了ServerLimit指令,使得無須重編譯Apache就可以加大MaxClients。下面是筆者的prefork配置段:

<IfModule prefork.c>
StartServers     10
MinSpareServers   10
MaxSpareServers   15
ServerLimit   2000
MaxClients     1000
MaxRequestsPerChild 10000
</IfModule>



  上述配置中,ServerLimit的最大值是20000,對於大多數站點已經足夠。如果一定要再加大這個數值,對位於源代碼樹下server/mpm/prefork/prefork.c中以下兩行做相應修改即可:



#define DEFAULT_SERVER_LIMIT 256
#define MAX_SERVER_LIMIT 20000


  worker的工作原理及配置

  相對於prefork,worker是2.0 版中全新的支持多線程和多進程混合模型的MPM。由於使用線程來處理,所以可以處理相對海量的請求,而系統資源的開銷要小於基於進程的服務器。但是,worker也使用了多進程,每個進程又生成多個線程,以獲得基於進程服務器的穩定性。這種MPM的工作方式將是Apache 2.0的發展趨勢。

  在configure -with-mpm=worker後,進行make編譯、make install安裝。在缺省生成的httpd.conf中有以下配置段:

<IfModule worker.c>
StartServers     2
MaxClients     150
MinSpareThreads   25
MaxSpareThreads   75
ThreadsPerChild   25
MaxRequestsPerChild 0
</IfModule>


  worker的工作原理是,由主控制進程生成「StartServers」個子進程,每個子進程中包含固定的ThreadsPerChild線程數,各個線程獨立地處理請求。同樣,為了不在請求到來時再生成線程,MinSpareThreads和MaxSpareThreads設置了最少和最多的空閒線程數;而MaxClients設置了所有子進程中的線程總數。如果現有子進程中的線程總數不能滿足負載,控制進程將派生新的子進程。

  MinSpareThreads和MaxSpareThreads的最大缺省值分別是75和250。這兩個參數對Apache的性能影響並不大,可以按照實際情況相應調節。

  ThreadsPerChild是worker MPM中與性能相關最密切的指令。ThreadsPerChild的最大缺省值是64,如果負載較大,64也是不夠的。這時要顯式使用ThreadLimit指令,它的最大缺省值是20000。上述兩個值位於源碼樹server/mpm/worker/worker.c中的以下兩行:

#define DEFAULT_THREAD_LIMIT 64
#define MAX_THREAD_LIMIT 20000

  這兩行對應著ThreadsPerChild和ThreadLimit的限制數。最好在configure之前就把64改成所希望的值。注意,不要把這兩個值設得太高,超過系統的處理能力,從而因Apache不起動使系統很不穩定。

  Worker模式下所能同時處理的請求總數是由子進程總數乘以ThreadsPerChild值決定的,應該大於等於MaxClients。如果負載很大,現有的子進程數不能滿足時,控制進程會派生新的子進程。默認最大的子進程總數是16,加大時也需要顯式聲明ServerLimit(最大值是20000)。這兩個值位於源碼樹server/mpm/worker/worker.c中的以下兩行:

#define DEFAULT_SERVER_LIMIT 16
#define MAX_SERVER_LIMIT 20000


  需要注意的是,如果顯式聲明了ServerLimit,那麼它乘以ThreadsPerChild的值必須大於等於MaxClients,而且MaxClients必須是ThreadsPerChild的整數倍,否則Apache將會自動調節到一個相應值(可能是個非期望值)。下面是筆者的worker配置段:

<IfModule worker.c>
StartServers     3
MaxClients     2000
ServerLimit   25
MinSpareThreads   50
MaxSpareThreads   200
ThreadLimit   200
ThreadsPerChild   100
MaxRequestsPerChild 0
</IfModule>

  通過上面的敘述,可以瞭解到Apache 2.0中prefork和worker這兩個重要MPM的工作原理,並可根據實際情況來配置Apache相關的核心參數,以獲得最大的性能和穩定性。

(出處:http://tech.ccidnet.com/pub/article/c737_a47607_p1.html




歡迎光臨 ADJ網路實驗室 (http://dz.adj.idv.tw/) Powered by Discuz! 6.0.0