Apache是世界使用排名第一的Web服務(wù)器軟件，下面就由愛站頻道的小編分享一篇關(guān)于Apache HTTP服務(wù)器提高性能的教程給大家吧!大家可以參考一下哦!

　　相比于Apache 1.3 ，2.0版本作了大量的優(yōu)化來提升處理能力和可伸縮性，而且大多數(shù)的改進在默認(rèn)狀態(tài)下就可以生效。但是，在編譯時和運行時，都有許多可以顯著提高性能的選擇。本文闡述在安裝Apache2.0時，服務(wù)器管理員可以改善性能的各種方法。其中，部分配置選擇可以使httpd更好地利用硬件和操作系統(tǒng)的兼容性，其他則是以功能換取速度。

　　硬件和操作系統(tǒng)

　　影響web服務(wù)器性能的最大的因素是內(nèi)存。一個web服務(wù)器應(yīng)該從不使用交換機制，因為交換產(chǎn)生的滯后使用戶總感覺"不夠快"，所以用戶就可能去按"停止"和"刷新"，從而帶來更大的負(fù)載。你可以，也應(yīng)該，控制MaxClients的設(shè)置，以避免服務(wù)器產(chǎn)生太多的子進程而發(fā)生交換。這個過程很簡單：通過命令計算出每個Apache進程平均消耗的內(nèi)存，然后再為其它進程留出足夠多的內(nèi)存。

　　其他因素就很普通了，裝一個足夠快的CPU，一個足夠快的網(wǎng)卡，幾個足夠快的硬盤，這里說的"足夠快"是指能滿足實際應(yīng)用的需求。

　　操作系統(tǒng)是很值得關(guān)注的又一個因素，已經(jīng)被證實的很有用的經(jīng)驗有：

　　*

　　選擇能夠得到的最新最穩(wěn)定的版本并打好補丁。近年來，許多操作系統(tǒng)廠商都提供了可以顯著改善性能的TCP協(xié)議棧和線程庫。

　　*

　　如果你的操作系統(tǒng)支持sendfile()系統(tǒng)調(diào)用，則務(wù)必安裝帶有此功能的版本或補丁(對Linux來說，就是使用Linux2.4或更高版本，對Solaris8的早期版本，則需要安裝補丁)。在支持sendfile的系統(tǒng)中，Apache2可以更快地發(fā)送靜態(tài)內(nèi)容而且占用較少的CPU時間。

　　運行時的配置

　　相關(guān)模塊 相關(guān)指令

　　* mod_dir

　　* mpm_common

　　* mod_status

　　* AllowOverride

　　* DirectoryIndex

　　* HostnameLookups

　　* EnableMMAP

　　* EnableSendfile

　　* KeepAliveTimeout

　　* MaxSpareServers

　　* MinSpareServers

　　* Options

　　* StartServers

　　HostnameLookups 和其他DNS考慮

　　在Apache1.3以前的版本中，HostnameLookups默認(rèn)被設(shè)為 On 。它會帶來延遲，因為對每一個請求都需要作一次DNS查詢。在Apache1.3中，它被默認(rèn)地設(shè)置為 Off 。如果需要日志文件提供主機名信息以生成分析報告，則可以使用日志后處理程序logresolve ，以完成DNS查詢，而客戶端無須等待。

　　推薦你最好是在其他機器上，而不是在web服務(wù)器上執(zhí)行后處理和其他日志統(tǒng)計操作，以免影響服務(wù)器的性能。

　　如果你使用了任何"Allow from domain"或"Deny from domain"指令(也就是domain使用的是主機名而不是IP地址)，則代價是要進行兩次DNS查詢(一次正向和一次反向，以確認(rèn)沒有作假)。所以，為了得到最高的性能，應(yīng)該避免使用這些指令(不用域名而用IP地址也是可以的)。

　　注意，可以把這些指令包含在段中使之局部化。在這種情況下，只有對這個區(qū)域的請求才會發(fā)生DNS查詢。下例禁止除了.html和.cgi以外的所有DNS查詢：

　　HostnameLookups off

　　HostnameLookups on

　　如果在某些CGI中偶爾需要DNS名稱，則可以調(diào)用gethostbyname來解決。

　　FollowSymLinks 和 SymLinksIfOwnerMatch

　　如果網(wǎng)站空間中沒有使用 Options FollowSymLinks ，或使用了 Options SymLinksIfOwnerMatch ，Apache就必須執(zhí)行額外的系統(tǒng)調(diào)用以驗證符號連接。文件名的每一個組成部分都需要一個額外的調(diào)用。例如，如果設(shè)置了：

　　DocumentRoot /www/htdocs

　　Options SymLinksIfOwnerMatch

　　在請求"/index.html"時，Apache將對"/www"、"/www/htdocs"、"/www/htdocs/index.html"執(zhí)行l(wèi)stat()調(diào)用。而且lstat()的執(zhí)行結(jié)果不被緩存，因此對每一個請求都要執(zhí)行一次。如果確實需要驗證符號連接的安全性，則可以這樣：

　　DocumentRoot /www/htdocs

　　Options FollowSymLinks

　　Options -FollowSymLinks +SymLinksIfOwnerMatch

　　這樣，至少可以避免對DocumentRoot路徑的多余的驗證。注意，如果Alias或RewriteRule中含有DocumentRoot以外的路徑，那么同樣需要增加這樣的段。為了得到最佳性能，應(yīng)當(dāng)放棄對符號連接的保護，在所有地方都設(shè)置FollowSymLinks ，并放棄使用SymLinksIfOwnerMatch 。

　　AllowOverride

　　如果網(wǎng)站空間允許覆蓋(通常是用.htaccess文件)，則Apache會試圖對文件名的每一個組成部分都打開.htaccess ，例如：

　　DocumentRoot /www/htdocs

　　AllowOverride all

　　如果請求"/index.html"，則Apache會試圖打開"/.htaccess"、"/www/.htaccess"、"/www/htdocs/.htaccess"。其解決方法和前面所述的 Options FollowSymLinks 類似。為了得到最佳性能，應(yīng)當(dāng)對文件系統(tǒng)中所有的地方都使用 AllowOverride None 。

　　內(nèi)容協(xié)商

　　實踐中，內(nèi)容協(xié)商的好處大于性能的損失，如果你很在意那一點點的性能損失，則可以禁止使用內(nèi)容協(xié)商。但是仍然有個方法可以提高服務(wù)器的速度，就是不要使用通配符，如：

　　DirectoryIndex index

　　而使用完整的列表，如：

　　DirectoryIndex index.cgi index.pl index.shtml index.html

　　其中最常用的應(yīng)該放在前面。

　　還有，建立一個明確的type-map文件在性能上優(yōu)于使用"Options MultiViews"，因為所有需要的信息都在一個單獨的文件中，而無須搜索目錄。請參考內(nèi)容協(xié)商文檔以獲得更詳細的協(xié)商方法和創(chuàng)建type-map文件的指導(dǎo)。

　　內(nèi)存映射

　　在Apache2.0需要搜索被發(fā)送文件的內(nèi)容時，比如處理服務(wù)器端包含時，如果操作系統(tǒng)支持某種形式的mmap() ，則會對此文件執(zhí)行內(nèi)存映射。

　　在某些平臺上，內(nèi)存映射可以提高性能，但是在某些情況下，內(nèi)存映射會降低性能甚至影響到httpd的穩(wěn)定性：

　　*

　　在某些操作系統(tǒng)中，如果增加了CPU，mmap還不如read()迅速。比如，在多處理器的Solaris服務(wù)器上，關(guān)閉了mmap ，Apache2.0傳送服務(wù)端解析文件有時候反而更快。

　　*

　　如果你對作為NFS裝載的文件系統(tǒng)中的一個文件進行了內(nèi)存映射，而另一個NFS客戶端的進程刪除或者截斷了這個文件，那么你的進程在下一次訪問已經(jīng)被映射的文件內(nèi)容時，會產(chǎn)生一個總線錯誤。

　　如果有上述情況發(fā)生，則應(yīng)該使用 EnableMMAP off 關(guān)閉對發(fā)送文件的內(nèi)存映射。注意：此指令可以被針對目錄的設(shè)置覆蓋。

　　Sendfile

　　在Apache2.0能夠忽略將要被發(fā)送的文件的內(nèi)容的時候(比如發(fā)送靜態(tài)內(nèi)容)，如果操作系統(tǒng)支持sendfile() ，則Apache將使用內(nèi)核提供的sendfile()來發(fā)送文件。

　　在大多數(shù)平臺上，使用sendfile可以通過免除分離的讀和寫操作來提升性能。然而在某些情況下，使用sendfile會危害到httpd的穩(wěn)定性

　　*

　　一些平臺可能會有Apache編譯系統(tǒng)檢測不到的有缺陷的sendfile支持，特別是將在其他平臺上使用交叉編譯得到的二進制文件運行于當(dāng)前對sendfile支持有缺陷的平臺時。

　　*

　　對于一個掛載了NFS文件系統(tǒng)的內(nèi)核，它可能無法可靠的通過自己的cache服務(wù)于網(wǎng)絡(luò)文件。

　　如果出現(xiàn)以上情況，你應(yīng)當(dāng)使用"EnableSendfile off"來禁用sendfile 。注意，這個指令可以被針對目錄的設(shè)置覆蓋。

　　進程的建立

　　在Apache1.3以前，MinSpareServers, MaxSpareServers, StartServers的設(shè)置對性能都有很大的影響。尤其是為了應(yīng)對負(fù)載而建立足夠的子進程時，Apache需要有一個"漸進"的過程。在最初建立StartServers數(shù)量的子進程后，為了滿足MinSpareServers設(shè)置的需要，每一秒鐘只能建立一個子進程。所以，對一個需要同時處理100個客戶端的服務(wù)器，如果StartServers使用默認(rèn)的設(shè)置5，則為了應(yīng)對負(fù)載而建立足夠多的子進程需要95秒。在實際應(yīng)用中，如果不頻繁重新啟動服務(wù)器，這樣還可以，但是如果僅僅為了提供10分鐘的服務(wù)，這樣就很糟糕了。

　　" 一秒鐘一個"的規(guī)定是為了避免在創(chuàng)建子進程過程中服務(wù)器對請求的響應(yīng)停頓，但是它對服務(wù)器性能的影響太大了，必須予以改變。在Apache1.3中，這個 "一秒鐘一個"的規(guī)定變得寬松了，創(chuàng)建一個進程，等待一秒鐘，繼續(xù)創(chuàng)建第二個，再等待一秒鐘，繼而創(chuàng)建四個，如此按指數(shù)級增加創(chuàng)建的進程數(shù)，最多達到每秒 32個，直到滿足MinSpareServers設(shè)置的值為止。

　　從多數(shù)反映看來，似乎沒有必要調(diào)整MinSpareServers, MaxSpareServers, StartServers 。如果每秒鐘創(chuàng)建的進程數(shù)超過4個，則會在ErrorLog中產(chǎn)生一條消息，如果產(chǎn)生大量此消息，則可以考慮修改這些設(shè)置。可以使用mod_status的輸出作為參考。

　　與進程創(chuàng)建相關(guān)的是由MaxRequestsPerChild引發(fā)的進程的銷毀。其默認(rèn)值是"0"，意味著每個進程所處理的請求數(shù)是不受限制的。如果此值設(shè)置得很小，比如30，則可能需要大幅增加。在SunOS或者Solaris的早期版本上，其最大值為10000以免內(nèi)存泄漏。

　　如果啟用了持久鏈接，子進程將保持忙碌狀態(tài)以等待被打開連接上的新請求。為了最小化其負(fù)面影響，KeepAliveTimeout的默認(rèn)值被設(shè)置為5秒，以謀求網(wǎng)絡(luò)帶寬和服務(wù)器資源之間的平衡。在任何情況下此值都不應(yīng)當(dāng)大于60秒，參見most of the benefits are lost。

　　編譯時的配置

　　選擇一個MPM

　　Apache 2.x 支持插入式并行處理模塊，稱為多路處理模塊(MPM)。在編譯Apache時你必須選擇也只能選擇一個MPM，這里有幾個針對非UNIX系統(tǒng)的MPM：beos, mpm_netware, mpmt_os2, mpm_winnt。對類UNIX系統(tǒng)，有幾個不同的MPM可供選擇，他們都會影響到httpd的速度和可伸縮性：

　　* workerMPM使用多個子進程，每個子進程中又有多個線程。每個線程處理一個請求。該MPM通常對高流量的服務(wù)器是一個不錯的選擇。因為它比preforkMPM需要更少的內(nèi)存且更具有伸縮性。

　　* preforkMPM使用多個子進程，但每個子進程并不包含多線程。每個進程只處理一個鏈接。在許多系統(tǒng)上它的速度和workerMPM一樣快，但是需要更多的內(nèi)存。這種無線程的設(shè)計在某些情況下優(yōu)于workerMPM：它可以應(yīng)用于不具備線程安全的第三方模塊(比如php3/4/5)，且在不支持線程調(diào)試的平臺上易于調(diào)試，而且還具有比workerMPM更高的穩(wěn)定性。

　　關(guān)于MPM的更多內(nèi)容，請參考其文檔。

　　模塊

　　既然內(nèi)存用量是影響性能的重要因素，你就應(yīng)當(dāng)盡量去除你不需要的模塊。如果你將模塊編譯成DSO ，取消不必要的模塊就是一件非常簡單的事情：注釋掉LoadModule指令中不需要的模塊。

　　如果你已經(jīng)將模塊靜態(tài)鏈接進Apache二進制核心，你就必須重新編譯Apache并去掉你不想要的模塊。

　　增減模塊牽涉到的一個問題是：究竟需要哪些模塊、不需要哪些模塊?這取決于服務(wù)器的具體情況。一般說來，至少要包含下列模塊：mod_mime, mod_dir, mod_log_config 。你也可以不要mod_log_config ，但是一般不推薦這樣做。

　　原子操作

　　一些模塊，比如mod_cache和worker使用APR(Apache可移植運行時)的原子API。這些API提供了能夠用于輕量級線程同步的原子操作。

　　默認(rèn)情況下，APR在每個目標(biāo)OS/CPU上使用其最有效的特性執(zhí)行這些操作。比如許多現(xiàn)代CPU的指令集中有一個原子的比較交換(compare-and -swap, CAS)操作指令。在一些老式平臺上，APR默認(rèn)使用一種緩慢的、基于互斥執(zhí)行的原子API以保持對沒有CAS指令的老式CPU的兼容。如果你只打算在新式的CPU上運行Apache，你可以在編譯時使用 --enable-nonportable-atomics 選項：

　　./buildconf

　　./configure --with-mpm=worker --enable-nonportable-atomics=yes

　　--enable-nonportable-atomics 選項只和下列平臺相關(guān)：

　　* SPARC上的Solaris

　　默認(rèn)情況下，APR使用基于互斥執(zhí)行的原子操作。如果你使用 --enable-nonportable-atomics 選項，APR將使用SPARC v8plus操作碼來加快基于硬件的CAS操作。注意，這僅對UltraSPARC CPU有效。

　　* x86上的Linux

　　默認(rèn)情況下，APR在Linux上使用基于互斥執(zhí)行的原子操作。如果你使用 --enable-nonportable-atomics 選項，APR將使用486操作碼來加快基于硬件的CAS操作。注意，這僅對486以上的CPU有效。

　　mod_status 和 "ExtendedStatus On"

　　如果Apache在編譯時包含了mod_status ，而且在運行時設(shè)置了"ExtendedStatus On"，那么Apache會對每個請求調(diào)用兩次gettimeofday()(或者根據(jù)操作系統(tǒng)的不同，調(diào)用times())以及(1.3版之前)幾個額外的time()調(diào)用，使?fàn)顟B(tài)記錄帶有時間標(biāo)志。為了得到最佳性能，可以設(shè)置"ExtendedStatus off"(這也是默認(rèn)值)。

　　多socket情況下的串行accept

　　警告

　　這部分內(nèi)容尚未完全根據(jù)Apache2.0中的變化進行更新 。一些信息依然有效，使用中請注意。

　　這里要說的是 Unix socket API 的一個缺點。假設(shè)web服務(wù)器使用了多個Listen語句監(jiān)聽多個端口或者多個地址，Apache會使用select()以檢測每個socket是否就緒。select()會表明一個socket有零或至少一個連接正等候處理。由于Apache的模型是多子進程的，所有空閑進程會同時檢測新的連接。一個很天真的實現(xiàn)方法是這樣的(這些例子并不是源代碼，只是為了說明問題而已)：

　　for (;;) {

　　for (;;) {

　　fd_set accept_fds;

　　FD_ZERO (&accept_fds);

　　for (i = first_socket; i

　　以上就是關(guān)于Apache HTTP服務(wù)器提高性能的教程，想必都了解了吧，更多相關(guān)內(nèi)容請繼續(xù)關(guān)注愛站技術(shù)頻道。

標(biāo)簽： dns dns查詢 http服務(wù)器 linux swap web服務(wù)器 安全 代碼 服務(wù)器 服務(wù)器端 服務(wù)器管理 服務(wù)器使用 服務(wù)器性能 排名 搜索 網(wǎng)絡(luò) 域名

版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請與原作者聯(lián)系。