LAMP系列之httpd.conf詳解及MPM模型介紹

LAMP之httpd.conf詳解及MPM模型介紹

httpd.conf中常用參數介紹

一、連接類參數：
1、MaxKeppAliveRequests            #一個長連接中允許的請求數量。
【說明】
該參數限制了當啓用KeepAlive時，每次連接允許的請求數量。如果將此值設爲0，將不限制請求的數量。這裏建議最好將此值設爲一個比較大的值，以確保最優的服務器性能。
2、KeppAliveTimeOut                #持續作用中服務器在兩次請求之間的等待時間。
【說明】
Apache在關閉本次連接前等待下一次請求的時間，即在這段時間內該連接沒有接收到請求就會關閉此連接。一旦收到一個請求，超時值將會被設置爲KeppAliveTimeOut的值。
注意：對於高負荷的服務器來說，如果把該參數的值設置的較大可能會導致一些性能方面的問題，因爲KeppAliveTimeOut的值會影響釋放空閒進程、線程時間的數量，如果該值大，那麼在一定時間區間內釋放出來的空閒進程、線程的數量會少於該值小的，所以會降低服務器處理請求的能力，從而影響整個系統的吞吐量。
2、Listen                          #服務器監聽IP地址和端口。
【說明】
Listen參數是指Apache服務器在指定的IP地址和端口上進行監聽；默認情況下Apache會在所有IP地址上監聽。Listen是一個必須設置的指令。如果在配置文件中找不到這個指令，服務器將無法啓動。
Listen參數還可以指定服務器在哪個端口或地址和端口的組合上進行監聽請求。如果只指定一個端口，服務器將在所有地址上監聽該端口。如果指定了地址和端口的組合，服務器將按照指定地址和指定的端口進行監聽。
使用多個Listen參數可以指定多個不同的監聽端口和/或地址端口組合。
例如，想要服務器接受80和8080端口上的請求，可以這樣設置：
Listen 80
Listen 8080
爲了讓服務器在兩個確定的地址端口組合上接受請求，可以這樣設置：
Listen 192.168.1.100.1:80
Listen 192.168.1.100.5:8080
注意：多個Listen指令指定了同一個地址和端口的組合後，會導致"Address already in use"錯誤。

二、系統路徑管理類參數：
1、ServerRoot                         #服務器的安裝基礎目錄。
【說明】
該參數設置了服務器所在的目錄。一般來說它將包含conf/和logs/子目錄。其它配置文件的相對路徑都基於此目錄 (比如Include或LoadModule)。
例如：
ServerRoot /etc/httpd
DocumentRoot
組成網絡上可見的主文檔樹的根目錄。
【說明】
此參數設置了httpd服務的目錄。在沒有配置類似Alias這種參數的情況下，服務器會將請求中的URL附加到DocumentRoot後面以構成指向文檔的路徑。比如說：
DocumentRoot /etc/httpd/www/web
於是對http://www.ccb.com.cn/index.html的訪問就會指向/etc/httpd/www/web/index.html。如果參數中不是絕對路徑，則被假定爲是相對於ServerRoot的路徑。
注意：指定DocumentRoot時不應包括最後的"/"。
2、Directory             #可以封裝一組參數，使之僅對文件空間中的某個目錄及其子目錄生效
【語法】
<Directory directory-path> ...</Directory>
【說明】
<Directory>和</Directory>用於封裝一組參數，使其對某個目錄及其子目錄生效。directory-path可以是一個目錄的完整路徑，或是包含了Unix shell匹配語法的通配符字符串，但是通配符都不能匹配"/"字符，例如：<Directory/*/public_html>是無法匹配/home/user/public_html 的，而<Directory/home/*/public_html>卻能夠正確匹配。
directory-path參數必須與被訪問文件所在文件系統的路徑保持一致。如果有多個非正則表達式，<Directory>配置段符合幷包含某文檔的目錄(或其父目錄)，那麼會以短目錄優先的規則進行應用。<Directory />的默認訪問權限爲"Allow fromAll"，這意味着Apache沒有進行訪問控制，通過設置Order，Deny，Allow，AllowOverride這個幾個參數可以對訪問進行控制。
下面簡單介紹一下這4個參數的用法。
1>    Allow
該參數是控制哪些主機纔可以訪問目標。
示例：
Allow from 192.168.188.88
Allow from 192.168.188.89  192.168.188.90
表示IP地址爲192.168.188.88或192.168.188.89或192.168.188.903纔可以訪問目標。
2>    Deny
該參數是控制哪些主機被禁止訪問目標。
示例：
Deny from 192.169.189.89
Deny from 192.169.189.90  192.169.189.91
表示IP地址爲192.169.189.89或192.169.189.90或192.169.189.91則不能訪問目標。
3>              Order
Order參數是控制Allow和Deny參數生效順序的，常用的取值是：Deny,Allow 和Allow,Deny。例如：
Order Deny,Allow
Deny from 192.168.18.66
Allow from 192.168.18.67  192.168.18.68
--------------à表示先考慮Deny條件再考慮Allow條件，該配置的意思是拒絕IP地址爲192.64.18.66的訪問，只允許192.168.18.67和192.168.18.68的訪問。
再看一個例子：
Order Allow,Deny
Allow from all
Deny from 192.168.18.70
表示只拒絕IP地址爲192.168.18.70的訪問。
4>AllowOverride
當服務器發現一個.htaccess文件(由AccessFileName指定)時，它需要知道在這個文件中聲明的哪些指令能覆蓋在此之前指定的配置參數。一般情況下NONE即可。
【Directory參數小結】
最後給出一個完整封裝目錄的配置段：
<Directory "/data/mages">
Options Indexes FollowSymLinks       //對URL映射到的系統目錄產生文件列表
AllowOverride None
Order Deny,Allow
Allow from all
</Directory>
上面的配置對系統中的"/home/data/p_w_picpaths"目錄進行了封裝，而且對訪問不加任何限制。這段配置後面在講如何將靜態文件放置到Apache上還會用到。

三、監控反饋類參數
PidFile
服務器用於記錄父進程(監控進程)PID的文件
【說明】
PidFile指令設置服務器用於記錄
父進程(監控進程)PID的文件。如果指定的不是絕對路徑，那麼將視爲基於ServerRoot的相對路徑。
示例：
PidFile/var/run/apache.pid
這個文件通常用來給服務器父進程發送一個信號，用於關閉或重啓服務器，以便重新打開ErrorLog和TransferLog文件、重新讀取配置文件。
ServerAdmin
服務器返回給客戶端的錯誤信息中所包含的管理員郵件地址。
【說明】
該參數是在所有返回給客戶端的錯誤信息中給出管理員的郵件地址。但也可以是一個URL地址，如果httpd不能將該參數的值識別爲URL，它就會假定它是一個email-address ，並在超連接中用在mailto後面。這裏推薦配置一個Email地址,如果配置的是URL一定要保證指向一個受控制的服務器，否則用戶將無法確保和管理員取得聯繫。
示例：
ServerAdmin [email protected]

四、日誌管理類參數：
LogLevel
控制錯誤日誌的級別
【說明】
LogLevel用於設置服務器按照日誌級別來記錄日誌信息。該參數可以選擇的level有：
Level
描述
例子
emerg
緊急(系統無法使用)
 "Child cannot open lock file.Exiting"
alert
必須立即採取措施
 "getpwuid: couldn't determine user namefrom uid"
crit
致命情況
 "socket: Failed to get a socket, exitingchild"
error
錯誤情況
 "Premature end of script headers"
warn
警告情況
 "child process 1234 did not exit, sendinganother SIGHUP"
notice
一般重要情況
 "httpd: caught SIGBUS, attempting to dumpcore in ..."
info
普通信息
 "Server seems busy, (you may need toincrease StartServers, or Min/MaxSpareServers)..."
debug
調試信息
 "Opening config file ..."
注意：當指定了某個級別後，所有級別高於它的信息也會被同時記錄。建議至少使用crit級別。當錯誤日誌是一個單獨分開的正式文件的時候，notice級別的消息總是會被記錄下來，而不能被屏蔽。
ErrorLog
存放錯誤日誌的位置
【說明】
該參數指定了當服務器遇到錯誤時記錄日誌的文件名。如果該值不是一個以斜槓(/)開頭的絕對路徑，那麼將被認爲是一個相對於ServerRoot的相對路徑。
示例
ErrorLog /etc/var/log/httpd/error_log
如果配置了一個以管道符號(|)開頭的值，那麼會爲它指定一個命令來處理錯誤日誌。
示例
ErrorLog  "/data/logs/httpd_errors"
注意：當在非Unix平臺上輸入文件路徑的時候，路徑分隔符必須統一使用正斜線(/)。
 CustomLog
設置服務器訪問日誌的文件名和格式。
【說明】
該參數用來對服務器的請求進行日誌記錄。第一個參數指定了日誌文件的位置，第二個參數用於設置日誌的格式。
示例：
CustomLog logs/access_log "%h %l%u %t ""%r"" %>s %b"
定製日誌文件格式
LogFormat和CustomLog的格式化參數是一個字符串。這個字符串會在每次請求發生的時候，被記錄到日誌中去。它可以包含將被原樣寫入日誌文本放入字符串以及C風格的控制字符""n"和""t"。文本中的引號和反斜槓應通過"""來轉義。請求本身的情況也將通過在格式字符串中放置各種"%"轉義符的方法來記錄，它們在寫入日誌文件時，根據下表的定義進行轉換：
格式字符串
描述
%%
百分號(Apache2.0.44或更高的版本)
%a
遠端IP地址
%A
本機IP地址
%B
除HTTP頭以外傳送的字節數
%b
以CLF格式顯示的除HTTP頭以外傳送的字節數，也就是當沒有字節傳送時顯示'-'而不是0。
%{Foobar}C
在請求中傳送給服務端的cookieFoobar的內容。
%D
服務器處理本請求所用時間，以微爲單位。
%{FOOBAR}e
環境變量FOOBAR的值
%f
文件名
%h
遠端主機
%H
請求使用的協議
%{Foobar}i
發送到服務器的請求頭Foobar:的內容。
%l
遠端登錄名(由identd而來，如果支持的話)，除非IdentityCheck設爲"On"，否則將得到一個"-"
%m
請求的方法
%{Foobar}n
來自另一個模塊的註解Foobar的內容。
%{Foobar}o
應答頭Foobar:的內容。
%p
服務器服務於該請求的標準端口。
%P
爲本請求提供服務的子進程的PID。
%{format}P
服務於該請求的PID或TID(線程ID)，format的取值範圍爲：pid和tid(2.0.46及以後版本)以及hextid(需要APR1.2.0及以上版本)
%q
查詢字符串(若存在則由一個"?"引導，否則返回空串)
%r
請求的第一行
%s
狀態。對於內部重定向的請求，這個狀態指的是原始請求的狀態，---%>s則指的是最後請求的狀態。
%t
時間，用普通日誌時間格式(標準英語格式)
%{format}t
時間，用strftime(3)指定的格式表示的時間。(默認情況下按本地化格式)
%T
處理完請求所花時間，以秒爲單位。
%u
遠程用戶名(根據驗證信息而來；如果返回status(%s)爲401，可能是假的)
%U
請求的URL路徑，不包含查詢字符串。
%v
對該請求提供服務的標準ServerName。
%V
根據UseCanonicalName指令設定的服務器名稱。
%X
請求完成時的連接狀態：
X=
連接在應答完成前中斷。
+=
應答傳送完後繼續保持連接。
-=
應答傳送完後關閉連接。
(在1.3以後的版本中，這個指令是%c，但這樣就和過去的SSL語法：%{var}c衝突了)
%I
接收的字節數，包括請求頭的數據，並且不能爲零。要使用這個指令你必須啓用mod_logio模塊。
%O
發送的字節數，包括請求頭的數據，並且不能爲零。要使用這個配置你必須啓用mod_logio模塊。
修飾符
可以緊跟在"%"後面加上一個逗號分隔的狀態碼列表來限制記錄的條目。例如，"%400,501{User-agent}i"只記錄狀態碼400和501發生時的User-agent頭內容；不滿足條件時用"-"代替。狀態碼前還可以加上"!"前綴表示否定，"%!200,304,302{Referer}i"記錄所有不同於200,304,302的狀態碼發生時的Referer頭內容。"<"和">"修飾符可以用來指定對於已被內部重定向的請求是選擇原始的請求還是選擇最終的請求。默認情況下，%s, %U, %T, %D, %r 使用原始請求，而所有其他格式串則選擇最終請求。例如，%>s 可以用於記錄請求的最終狀態，而 %<u 則記錄一個已經被內部重定向到非認證資源的請求的原始認證用戶。
官方的一些說明
出於安全考慮，從2.0.46版本開始，%r, %i, %o 中的特殊字符，除了雙引號(")和反斜線(")分別用 "" 和 "" 進行轉義、空白字符用C風格("n, "t 等)進行轉義以外，非打印字符和其它特殊字符使用 "xhh 格式進行轉義(hh是該字符的16進制編碼)。在2.0.46以前的版本中，這些內容會被完整的按原樣記錄。這種做法將導致客戶端可以在日誌中插入控制字符，所以在處理這些日誌文件的時候要特別小心。在2.0版本中(不同於1.3)，%b 和 %B 格式字符串並不表示發送到客戶端的字節數，而只是簡單的表示HTTP應答字節數(在連接中斷或使用SSL時與前者有所不同)。mod_logio提供的 %O 格式字符串將會記錄發送的實際字節數。
示例
一些常見的格式串：
通用日誌格式(CLF)
"%h %l %u %t""%r"" %>s %b"
帶虛擬主機的通用日誌格式
"%v %h %l %u %t""%r"" %>s %b"
NCSA擴展/組合日誌格式
"%h %l %u %t""%r"" %>s %b ""%{Referer}i""""%{User-agent}i"""
Referer日誌格式
"%{Referer}i -> %U"
Agent(Browser)日誌格式
"%{User-agent}i"
URL映射類參數
Alias
將URL映射到文件系統的特定區域。
【說明】
語法：Alias URL-pathfile-path|directory-path
Alias參數使文件可以被存儲在DocumentRoot以外的本地文件系統中。以(%已解碼的)url-path路徑開頭的URL可以被映射到以directory-path開頭的本地文件中。
示例：
Alias /p_w_picpath /etc/var/www/p_w_picpaths
將不會被匹配。
對"http://www.ccb.com/p_w_picpath/foo.gif"的請求，服務器將返回"/etc/var/www/p_w_picpaths/foo.gif"文件。由於該參數是匹配完整路徑，所以請求是"http:// www.ccb.com/p_w_picpathfoo.gif"
注意：如果url-path中有後綴"/"，則服務器要求有後綴"/"以擴展此別名。也就是說"Alias /icons//usr/local/apache/icons/"並不能對"/icons"實現別名.
注意，可能需要額外指定一個<Directory>段來覆蓋別名的最終對象。由於只有出現在<Directory>段之前的別名纔會被檢測，所以它只對最終對象生效。如果對在DocumentRoot之外的某個目錄建立了一個Alias ，則可能需要明確的對目標目錄設定訪問權限。
示例：
Alias /p_w_picpath /ftp/pub/p_w_picpath
<Directory /ftp/pub/p_w_picpath>
Order allow,deny
Allow from all
</Directory>

五、Apache工作模型簡介及彼此間切換
多路處理模塊的配置說明--prefork.c模塊(一個非線程型的、預派生的MPM)、worker.c模塊(支持混合的多線程多進程的多路處理模塊)
Apache HTTP服務器是一個強大的、靈活的能夠在多種平臺、不同環境下運行的Web服務器。由於不同的平臺和不同的環境經常產生不同的需求，爲了達到同樣的最佳效果則需要採取不同的實現方法， Apache的模塊化設計就可以很好的適應大量不同的環境。使得網站管理員能夠在編譯和運行時憑藉載入不同的模塊來決定服務器的附加功能。Apache的多路處理模塊(MPM)就是用於選擇處理網絡端口綁定、接受請求並指派子進程處理來自客戶端的請求。
默認的MPM
下表列出了不同操作系統上默認的MPM。如果編譯時沒有進行選擇，這將是默認選擇的MPM。
操作系統名稱
 MPM名稱
BeOS
 beos
Netware
 mpm_netware
OS/2
 mpmt_os2
Unix
 prefork
Windows
 mpm_winnt
1、prefork.c模塊(一個非線程型的、預派生的MPM)
 prefork.c模塊是由一個單獨的控制進程(父進程)負責產生子進程，這些子進程用於監聽請求並作出應答。Apache設置了一些備用的(spare)或者是空閒的子進程來處理即將接收的請求，這樣可以避免服務器接收到請求後在創建子進程。在Unix系統中，父進程通常以root身份運行以便邦定80端口，而 Apache產生的子進程通常以一個低特權的用戶運行。User和Group參數就是用於設置子進程的低特權用戶。運行子進程的用戶必須要對它所服務的內容有讀取的權限，但是對服務內容之外的其他資源最好擁有儘可能少的權限。
【配置示例】
<IfModule prefork.c>
StartServers             8
MinSpareServers         5
MaxSpareServers        20
ServerLimit            400
MaxClients            256
MaxRequestsPerChild 4000
</IfModule>
【參數說明】
1.ServerLimit
默認的MaxClient最大是256個線程,如果想設置更大的值，就需要修改ServerLimit這個參數。例子中的400是ServerLimit這個參數的最大值。如果需要更大，則必須編譯apache,此前都是不需要重新編譯Apache。
2．StartServers
指定服務器啓動時建立的子進程數量，因爲子進程的數量動態的取決於負載的輕重，所以一般沒有必要調整這個參數，prefork模式默認爲5。
3．MinSpareServers
指定空閒子進程的最小數量，所謂空閒子進程是指沒有正在處理請求的子進程。默認爲5。如果當前空閒子進程數少於MinSpareServers ，那麼Apache將以最大每秒一個的速度產生新的子進程，只有機器在非常繁忙的情況下才需要調整這個參數。
4．MaxSpareServers
設置空閒子進程的最大數量。默認爲10。如果當前有超過MaxSpareServers數量的空閒子進程，那麼父進程將殺死多餘的子進程。如果該參數的值設置比MinSpareServers小，Apache則會自動將其修改成"MinSpareServers+1"。
5．MaxClients
指可以服務於客戶端請求的最大子進程數量，即限定同一時間客戶端最大接入請求的數量，默認值爲256。任何超過MaxClients限制的請求都將進入等候隊列,一旦一個連接被釋放，隊列中的請求將得到服務。
6．MaxRequestsPerChild
每個子進程在其生存期內允許處理的最大請求數，默認爲10000.到達MaxRequestsPerChild的限制後，子進程將會結束。如果MaxRequestsPerChild爲"0"，子進程將永遠不會結束。這個參數也可以理解成控***務器殺死舊進程產生新進程的頻率。
注意：
從系統穩定性來考慮將MaxRequestsPerChild設置成非零有兩個好處：
1.可以防止(偶然的)內存泄漏無限進行，從而耗盡內存。
2.給進程一個有限壽命，從而有助於當服務器負載減輕的時候減少活動進程的數量。
【工作原理介紹】
首先服務啓動後會創建以StartServers個數的進程，然後等待來自客戶端的請求。我們這裏先假設從客戶端來了大量的請求，這時Apache服務器會根據自身的負載情況自動創建新進程，如果服務器一直沒有空閒進程那麼它就會一直創建新進程，直到滿足MaxClients和ServerLimit設置的最大值。如果來自客戶端的負載沒有那麼大，Apache服務器將會根據MinSpareServers、MaxSpareServers和MaxRequestsPerChild設置的值來殺掉多餘的進程。其中每個進程在某個確定的時間只能維持一個連接。
【小結】
上面敘述的這些參數中，對系統性能影響較大的有兩個：MaxClients 和ServerLimit。這個兩個參數主要影響Web服務器處理客戶端請求的能力，它們決定着服務器創建用來處理請求的進程的最大值。如果來自客戶端的請求總數已經達到系統創建進程的最大值（可通過ps -ef|grep http|wc –l來確認），那麼後面來的請求就要排隊，直到某個已處理請求完成。這就是應用系統資源還很富餘而HTTP訪問卻很慢的主要原因。如何找出這個兩個參數的最佳值需要綜合很多因素，但一般情況下可以參考系統性能測試結果和Web服務器的系統資源。
注意：prefork模式下創建較多的進程將會佔去大量系統內存，如果MaxClients和ServerLimit設置過大時可能會造成Web服務器崩潰。
2、worker.c模塊(支持混合的多線程多進程的多路處理模塊)
    worker 模塊使用多個子進程，每個子進程有多個線程。每個線程在某個確定的時間只能維持一個連接。通常來說，在一個高流量的HTTP服務器上，worker 模式是個比較好的選擇，因爲它的內存使用比prefork要低得多。但worker模式也有不完善的地方，如果一個線程崩潰，整個進程就會連同其所有線程一起"死掉"。由於線程共享內存空間，所以一個進程在運行時必須被系統識別爲"每個線程都是安全的"。
【配置示例】
<IfModule worker.c>
StartServers           2
MaxClients          400
ServerLimit          12
MinSpareThreads     25
MaxSpareThreads     75
ThreadsPerChild      25
ThreadLimit          75
MaxRequestsPerChild 0
</IfModule>
【參數說明】
1.ServerLimit
服務器允許配置的進程數上限。這個參數和ThreadLimit結合使用便決定了MaxClients所能設置的最大值。任何在重啓期間對這個參數的改變都將被忽略，但對MaxClients的修改卻會生效。
2.ThreadLimit
每個子進程可設置的線程數上限，這個參數決定了每個子進程可創建線程的數，即ThreadsPerChild的上限。任何在重啓期間對這個參數的改變都將被忽略，但對ThreadsPerChild的修改卻會生效。默認值是"64".
3.StartServers
服務器啓動時建立的子進程數，默認值是"3"。
4.MinSpareThreads
最小空閒線程數,默認值是75。MPM將基於整個服務器監視空閒線程數。如果服務器中總的空閒線程數太少，子進程將產生新的空閒線程。
5.MaxSpareThreads
設置最大空閒線程數。默認值是250。MPM將基於整個服務器監視空閒線程數。如果服務器中總的空閒線程數太多，子進程將殺死多餘的空閒線程。MaxSpareThreads的取值範圍是有限制的，在Apache的 worker模式下是要求大於等於 MinSpareThreads與ThreadsPerChild之和來自動修正你設置的值。
6.MaxClients
允許同時接收客戶端最大請求的數量(最大線程數量)。任何超過MaxClients限制的請求都將進入等候隊列。默認值是400,即16 (ServerLimit)乘以25(ThreadsPerChild)。因此需要增加MaxClients的時候，你必須同時增加 ServerLimit的值。
7.ThreadsPerChild
每個子進程建立常駐的執行線程數。默認值是25。子進程在啓動時建立這些線程後就不再建立新的線程了。
8.MaxRequestsPerChild
設置每個子進程在其生存期內允許提供服務的最大請求數量。到達MaxRequestsPerChild的限制後，子進程將會結束。如果MaxRequestsPerChild爲"0"，子進程將永遠不會結束。
將MaxRequestsPerChild設置成非零值有兩個好處：
1.可以防止(偶然的)內存泄漏無限進行，從而耗盡內存。
2.給進程一個有限壽命，從而有助於當服務器負載減輕的時候減少活動進程的數量。
注意
對於KeepAlive鏈接，只有第一個請求會被計數。事實上，它改變了每個子進程限制最大鏈接數量的行爲。
【工作原理介紹】：
worker的工作原理是：先由主控制進程創建“StartServers”個子進程，每個子進程中含有“ThreadsPerChild”個線程，各個線程獨立地處理來自客戶端的請求。同Prefork一樣，爲了不在請求到來時在去創建線程，MinSpareThreads和MaxSpareThreads決定了最少和最多空閒線程數；隨着負載逐漸增大，而現有子進程中的線程不能滿足負載時，主控進程將按照“ServerLimit”和“MaxClients”的限制去創建新進程，如果“ServerLimit”達到上限而ServerLimit*ThreadsPerChild <MaxClients時，那麼主控進程將參考“ThreadLimit”的值去嘗試增加某個進程的線程，前提是ThreadLimit> ThreadsPerChild。如果“ServerLimit”未達到上限而“MaxClients”達到上限，那麼服務器將不採取任何行動。倘若負載逐漸減小，那麼Apache服務器將根據實際情況去消減線程或進程。
【小結】
在worker模式下MinSpareThreads和MaxSpareThreads的最大缺省值分別是75和250。這兩個參數對Apache的性能影響並不大，可以按照實際情況做相應調節。而ThreadsPerChild參數是最影響性能的一個，因爲worker模式下所能同時處理的請求總數是由子進程總數與ThreadsPerChild之積來決定的。它的最大缺省值是64，如果負載較大，64也是不夠的。這時要顯式使用ThreadLimit指令，它的最大缺省值是20000。。注意，不要把這兩個值設得太高，如果超過系統的處理能力，會使系統很不穩定，這個值最好參考性能測試的結果來設，同時子進程總數與ThreadsPerChild之積應該略大於MaxClinets。
三、配置靜態文件
目前基於B/S結構的Web頁面有動態和靜態兩種形式，其中動態頁面需由服務器的解析器進行解析，通常還需連接數據庫，進行數據庫存取操作，最後形成HTML語言信息包反饋給瀏覽者；而靜態頁面，則無須解析，無須連接數據庫，直接反饋給客戶端就可以。　　
這裏說的靜態文件就是指在服務器端無需進行任何處理，就可以直接反饋給瀏覽器的文件，例如：HTML、JS，CSS、JPG、BMP等等。
將應用系統中的靜態文件配置到Apache服務器上有幾大好處，首先從客戶角度來看Web頁面的響應時間提高了，其次從系統資源來看應用服務器能專心處理動態文件，所以充分發揮了它的效能，再次從系統穩定性來看Apache服務器屏蔽了所有靜態文件的請求，減輕了應用服務器的壓力從而降低了由大訪問量帶來宕機的風險。
【配置示例1】
Alias /p_w_picpaths/ "/home/data/p_w_picpaths/"
<Directory "/home/data/p_w_picpaths">
Options Indexes FollowSymLinks
AllowOverride None
Order allow,deny
Allow from all
</Directory>
#配置圖片請求映射，與CSS,JS的配置類似。
<VirtualHost 192.64.108.2:8022>
<IfModule mod_weblogic.c>
    WebLogicCluster 192.64.96.18:8018,192.64.96.11:8011
    MatchExpression /file/*
    MatchExpression *.jsp
    MatchExpression *.jsf
    MatchExpression *.rtf
    MatchExpression *.xls
    MatchExpression *.doc
   MatchExpression /console*
</IfModule>
</VirtualHost>
#配置Webloig模塊中的參數。
【關鍵參數說明】
 VirtualHost
虛擬主機。
【說明】
在這個參數內可以模仿一個Web服務配置衆多參數，即在<VirtualHost>和</VirtualHost>中配置一組僅作用於特定虛擬主機的參數。
示例
<VirtualHost 192.64.182.53:8020>
ServerAdmin   [email protected]
DocumentRoot  /home/hrdc
ServerName    hrdc.ccb.cn
ErrorLog logs/host.foo.com-error_log
TransferLoglogs/host.foo.com-access_log
</VirtualHost>
注意：每個虛擬主機必須對應不同的IP地址、端口或是不同的主機名。
<VirtualHost>中定義的監聽地址只代表虛擬主機並不是指定Apache服務的監聽地址。指定Apache監聽地址的參數則是Listen。
 IfModule
根據指定的模塊是否啓用爲條件來決定是否進行處理。
【語法】
<IfModule [!]module-file|module-identifier>... </IfModule>
【說明】
在該參數中配置的表達式爲真的時候才進行處理。如果爲假，所有其包含的參數都將被忽略。
<IfModule>段中的表達式可以爲以下兩種方式之一來表達：
·         module
·         !module
第一種情況表示，在<IfModule >和</IfModule>之間的配置參數僅當module被載入後才被執行。此模塊可以是編譯時靜態鏈接的核心模塊或是使用LoadModule指令動態載入的模塊。第二種情況則表示，僅當module沒有載入時才執行參數內的配置處理。
module可以是模塊的標識符或者是編譯模塊時的文件名。在上面的例子中，mod_weblogic.c就是編譯模塊時的文件名。
注意：<IfModule>配置段是可以嵌套的，從而可以實現簡單的多模塊測試。

小結：MPM: Multi Path Modules 多道處理模塊就是定義Apache在響應多個用戶請求時所做的模型。

        (1)mpm_winnt模型   windows上使用，不做過多介紹

        (2)prefork模型 (一個請求用一個進程響應，穩定可靠，任何進程崩潰了，不會影響另外一個進程，尤其併發量很大時對資源消耗比較大，尤其涉及到大量的進程切換)

        (3)worker模型 (一個請求用一個線程響應,首先默認會生成兩個進程，線程是進程的子單位，因此線程一定是處於多個進程之中的線程；所以在worker模型下WEB服務器會生成多個進程，多個進程又會生成多個線程，用一個線程來響應一個用戶請求 (啓動多個進程，每個進程生成多個線程，對於thread由於多個線程共享同一個進程資源，所以某個線程打開某一個文件並進行了訪問的話，那麼第二個線程就不用再打開了，直接訪問就可以了；這樣效率會高一些；但是多個線程在工作時寫一個資源的話會導致資源爭用，所以爲了避免資源競爭，必須要加鎖，因此不能良好的解決鎖競爭的話，事實上線程是不是比進程的效率更高，這個很難說，尤其是Linux並不是原生態支持線程的，這也是爲什麼默認使用prefork而不使用worker的原因吧！))

        (4)event模型   (一個進程直接處理多個請求)