LAMP 系統性能調優，第 2 部分: 優化 Apache 和 PHP

是什么降低了 Apache 的速度，如何使 PHP 發揮最大效力

文檔選項 <noscript></noscript> 將此頁作為電子郵件發送 <!--START RESERVED FOR FUTURE USE INCLUDE FILES--><!-- this content will be automatically generated across all content areas --> <!--END RESERVED FOR FUTURE USE INCLUDE FILES-->

級別： 中級

Sean A. Walberg ( sean@ertw.com ), 高級網絡工程師

2007 年 6 月 07 日

如今，使用 LAMP（Linux?、Apache、MySQL 和 PHP/Perl）架構的應用程序不斷被開發和部署。但是，服務器管理員常常對應用程序本身幾乎沒有控制能力，因為應用程序是別人編寫的。這份 共三部分的系列文章 將討論許多服務器配置問題，這些配置會影響應用程序的性能。第二篇文章重點討論可為優化 Apache 和 PHP 而采取的措施。

Linux、Apache、MySQL 和 PHP（或 Perl）是許多 Web 應用程序的 LAMP 架構的基礎。有很多基于 LAMP 組件的開源軟件包可用于解決各種各樣的問題。隨著應用程序負載的增加，底層基礎設施的瓶頸也會越來越明顯，其表現形式就是響應用戶請求的速度變慢。 上一篇文章 展示了調優 Linux 系統的方法，還介紹了 LAMP 和性能度量的基礎知識。本文重點關注 Web 服務器組件：Apache 和 PHP。

調優 Apache

Apache 是一種高度可配置的軟件。它具有大量特性，但每一種都代價高昂。從某種程度上來說，調優 Apache 來說就是以恰當的方式分配資源，還涉及到將配置簡化為僅包含必要內容。

配置 MPM

Apache 是模塊化的，因為可以輕松添加和移除特性。在 Apache 的核心，多處理模塊（Multi-Processing Module，MPM）提供了這種模塊化功能性 —— 管理網絡連接、調度請求。MPM 使您能夠使用線程，甚至能夠將 Apache 遷移到另外一個操作系統。

每次只能有一個 MPM 是活動的，必須使用 --with-mpm= (worker|prefork|event) 靜態編譯。

每個請求使用一個進程的傳統模型稱為 prefork 。較新的線程化模型稱為 worker ，它使用多個進程，每個進程又有多個線程，這樣就能以較低的開銷獲得更好的性能。最新的 event MPM 是一種實驗性的模型，為不同的任務使用單獨的線程池。要確定當前使用的是哪種 MPM，可執行 httpd -l 。

選擇使用何種 MPM 取決于許多因素。在 event MPM 脫離實驗狀態之前，不應考慮這種模型，而是在使用線程和不使用線程之間作出選擇。表面上看來，如果所有底層模塊（包括 PHP 使用的所有庫）都是線程安全的，線程要優于分叉（forking）。而 Prefork 是較為安全的選擇；如果選擇了 worker，則應該謹慎測試。性能收益還取決于您的發布版所附帶的庫及硬件。

無論選擇了哪種 MPM，都必須恰當地配置它。一般而言，配置 MPM 包括告知 Apache 怎樣去控制有多少 worker 正在運行，它們是線程還是進程。prefork MPM 的重要配置選項如清單 1 所示。

                                      StartServers       50MinSpareServers   15MaxSpareServers   30MaxClients       225MaxRequestsPerChild  4000
                    

編譯您自己的軟件 最初使用 UNIX? 時，我堅持為加入系統的一切編譯軟件。最終，維護更新給我帶來了麻煩，所以我學會了如何構建包來簡化這一任務。后來我意識到，大多數時候我都在重復做發布版做過的事情。現在，在很大程度上來說，我會盡可能堅持使用我所選擇的發布版提供的一切，僅在必要的時候使用自己的包。 類似地，您可能會發現，就可維護性而言，使用廠商提供的軟件包要優于使用最新、最棒的代碼。有些時候，性能調優和系統管理的目標會有所沖突。如果使用商業版的 Linux 或依賴于第三方支持，那么可能不得不考慮廠商的支持。 如果您一意孤行，那么請學會如何構建能與您的發布版協同工作的包，請學會如何將其集成到補丁系統之中。這將確保軟件，以及您作出的任何更改得到一致的構建，且能跨多個系統使用。還應訂閱恰當的郵件列表和 RSS 提要來及時獲得軟件更新。

prefork 模型會為每個請求創建一個新進程。多余的進程保持空閑，以處理傳入的請求，這縮短了啟動延遲。只要 Web 服務器出現，預先完成的配置就會立即啟動 50 個進程，并盡力保持 10 到 20 個空閑服務器運行。進程數的硬性限制由 MaxClients 指定。盡管一個進程能夠處理許多相繼的請求，Apache 還是會取消連接數超過 4,000 以后的進程，這降低了內存泄漏的風險。

配置線程化 MPM 與之類似，不同之處只是必須確定使用多少線程和進程。Apache 文檔解釋了所有必要的參數和計算。

要經過幾次嘗試和出錯之后才能選好要使用的值。最重要的值是 MaxClients 。目標在于允許足夠多的 workder 進程或線程運行，同時又不會導致服務器進行過度的交換。如果傳入的請求超出處理能力，那么至少滿足此值的那些請求會得到服務，其他請求被阻塞。

如果 MaxClients 過高，那么所有客戶機都將體驗到糟糕的服務，因為 Web 服務器會試圖換出一個進程，以使另一個進程能夠運行。而設得過低意味著可能會不必要地拒絕服務。查看高負載下運行的進程數量和所有 Apache 進程所導致的內存占用情況對設置這個值很有幫助。如果 MaxClients 的值超過 256，必須將 ServerLimit 也設為同樣的數值，請仔細閱讀 MPM 的文檔，了解相關信息。

根據服務器的角色調優要啟動和保持空閑的服務器數量。如果服務器僅運行 Apache，那么可以使用適中的值，如 清單 1 所示，因為這樣就能充分利用機器。如果系統中還有其他數據庫或服務器，那么就應該限制運行中的空閑服務器的數量。

有效地使用選項和重寫

Apache 處理的每個請求都要履行一套復雜的規則，這些規則指明了 Web 服務器必須遵循的約束或特殊指令。對文件夾的訪問可能按 IP 地址約束為某個特定文件夾，也可配置用戶名和密碼。這些選項還包含處理特定文件，例如，如果提供了一個目錄列表，該如何處理的文件，或輸出結果是否應壓縮。

這些配置以 httpd.conf 中容器的形式出現，例如 <directory>，以便指定所用配置引用的是磁盤上的一個位置；再如 <location>，表示引用是 URL 中的路徑。清單 2 展示了一個實際的 Directory 容器。</location></directory>

                                      <directory></directory>    AllowOverride None    Options FollowSymLinks
                    

在清單 2 中，位于一對 Directory 和 /Directory 標記之間的配置應用于給定目錄和該目錄下的一切內容 —— 在本例中，這個給定目錄是根目錄。此處， AllowOverride 標記指出，用戶不允許重寫任何選項（稍后將進一步介紹）。 FollowSymLinks 選項被啟用，它允許 Apache 查看之前的符號連接來為請求提供服務，即便文件位于包含 Web 文件的目錄之外。這就意味著，如果 Web 目錄中的一個文件是 /etc/passwd 的符號連接，Web 服務器將在請求時順利為該文件提供服務。如果使用了 -FollowSymLinks ，該特性就會被禁用，同樣的請求將致使為客戶機返回錯誤。

最后這個場景正是導致兩方面關注的原因所在。第一個方面與性能有關。如果禁用了 FollowSymLinks ，Apache 就必須檢查使用該文件名的所有組件（目錄和文件本身），以確保它們不是符號連接。這會帶來額外的開銷（磁盤操作）。另外一個稱為 FollowSymLinksIfOwnerMatch 的選項會在文件所有者與連接所有者相同時使用符號連接。為獲得最佳性能，請使用 清單 2 中的選項。

至此，有安全意識的讀者應該有了警惕的感覺。安全性永遠是功能性與風險之間的權衡。在我們的例子中，功能性是速度，而風險是允許對系統上的文件進行未經授權的訪問。緩解風險的措施之一是 LAMP 應用服務器通常專注于一種具體功能，用戶無法創建危險的符號連接。如果有必要啟用符號連接，那么可以將其約束在文件系統的特定區域，如清單 3 所示。

                                      <directory></directory>   Options FollowSymLinks<directory>   Options -FollowSymLinks</directory>
                    

在清單 3 中，一個用戶的主目錄中的任何 public_html 目錄及其所有子目錄都移除了 FollowSymLinks 選項。

如您所見，通過主服務器配置，可為每個目錄單獨配置選項。用戶可以自行重寫這種服務器配置（如果管理員通過 AllowOverrides 語句允許了這種操作），只需將一個 .htaccess 文件放入目錄即可。該文件包含額外的服務器指令，每次請求包含 .htaccess 文件的目錄時將加載并應用這些指令。盡管之前探討過系統沒有用戶的問題，但許多 LAMP 應用程序都利用這種功能性來控制訪問、實現 URL 重寫，因此有必要理解其工作原理。

即便 AllowOverrides 語句能阻止用戶去做您不希望他們做的事，Apache 也必須檢查 .htaccess 文件，看看是否有要完成的工作。父目錄可以指定由來自子目錄的請求處理的指令，這也就表示，Apache 必須搜索所請求文件的目錄樹的所有組件。可想而知，這會使每次請求都導致大量磁盤操作。

最簡單的解決方案是不允許重寫，這能消除 Apache 檢查 .htaccess 的需求。之后的任何特殊配置都將直接放在 httpd.conf 中。清單 4 顯示為對一個用戶的項目目錄進行密碼檢查向 httpd.conf 增加的代碼，而不是將其放入一個 .htaccess 文件并依賴于 AllowOverrides 。

                                      <directory></directory>  AuthUserFile /home/user/.htpasswd  AuthName "uber secret project"  AuthType basic  Require valid-user
                    

如果配置轉移到 httpd.conf 中，且 AllowOverrides 被禁用，磁盤的使用就能減少。一個用戶的項目可能不會吸引許多人來點擊，但設想一下，將這項技術應用于一個忙碌的站點時會有多么強大。

有時不可能徹底消除 .htaccess 文件的使用。例如，在清單 5 中，一個選項被約束到文件系統的特定部分，重寫也可以是有作用域的。

                                      <directory></directory>  AllowOverrides None<directory>  AllowOverrides AuthConfig</directory>
                    

實現清單 5 之后，Apache 會在父目錄中查找 .htaccess 文件，但會在 public_html 目錄處停止，因為文件系統的其余部分禁用了此功能。例如，如果請求的是一個映射到 /home/user/public_html/project/notes.html 的文件，那么僅有 public_html 和 project 目錄被搜索。

關于每目錄單獨配置的最后一個提示就是：要按順序依次進行。任何介紹 Apache 調優的的文章都會告訴您，應通過 HostnameLookups off 指令禁用 DNS 查找，因為試圖反向解析連接到您的服務器的所有 IP 地址無疑是浪費資源。然而，基于主機名的任何約束都會迫使 Web 服務器對客戶機的 IP 地址執行反向查找，對其結果進行正向查找，以驗證該名稱的真實性。因此，避免使用基于客戶主機名的訪問控制，在必須使用時限定其作用域，這些都是明智的做法。

持久連接

一個客戶機連接到 Web 服務器時，允許客戶機通過同一個 TCP 連接發出多個請求，這減少了與多個連接相關的延遲。在一個 Web 頁面引用了多幅圖片時，這就很有用：客戶機可以通過一個連接先請求頁面，再請求所有圖片。其缺點在于服務器上的 worker 進程必須等待客戶機要關閉的會話，之后才能轉到下一個請求。

Apache 使您能夠配置如何處理持久連接（稱為 keepalives ）。httpd.conf 全局級的 KeepAlive 5 允許服務器在連接強制關閉之前處理一個連接上的 5 個請求。將此值設置為 0 將禁用持久連接。同樣位于全局級上的 KeepAliveTimeout 確定在會話關閉之前，Apache 將等待另外一個連接多久。

持久連接的處理并非 “一刀切” 式的配置。對于某些 Web 站點，禁用 keepalives 更合適（ KeepAlive 0 ）；而對于其他一些站點，啟用它會帶來巨大的收益。惟一的解決之道就是嘗試使用這兩種配置，自己觀察哪種更合適。但若啟用了 keepalives，使用較小的超時時間較為明智，例如 2，即 KeepAliveTimeout 2 。這能確保希望發出另外一個請求的客戶機有充足的時間，還能確保 worker 進程不會一直空閑，等待可能永遠不會出現的下一個請求。

壓縮

Web 服務器能夠在將輸出發回給客戶機之前壓縮它。這將使通過 Internet 發送的頁面更小，代價是 Web 服務器上的 CPU 周期。對于那些負擔得起 CPU 開銷的服務器來說，這是提高頁面下載速度的好辦法 —— 頁面壓縮后大小變為原來的三分之一這種事情并不罕見。

圖片通常已經是壓縮過的，因此壓縮應僅限于文本輸出。Apache 通過 mod_deflate 提供壓縮。盡管 mod_deflate 可輕松啟用，但它涉及到太多的復雜性，很多手冊都解釋了這些復雜的內容。本文不會介紹壓縮的配置，但提供了相應文檔的鏈接（參見 參考資料 部分）。

調優 PHP

PHP 是運行應用程序代碼的引擎。應該僅安裝計劃使用的那些模塊，并配置您的 Web 服務器，使之僅為腳本文件（通常是以 .php 結尾的那些文件）使用 PHP，而非所有靜態文件。

操作碼緩存

請求一個 PHP 腳本時，PHP 會讀取該腳本，并將其編譯為 Zend 操作碼 ，這是要執行的代碼的一種二進制表示形式。隨后，此操作碼由 PHP 執行并丟棄。操作碼緩存將保存這個編譯后的操作碼，并在下一次調用該頁面時重用它。這會節省很多時間。有多種緩存可用，我比較常用的是 eAccelerator。

要安裝 eAccelerator，您的計算機上需要有 PHP 開發庫。由于不同的 Linux 發布版存放文件的位置不同，所以最好直接從 eAccelerator 的 Web 站點獲得安裝說明（參見 參考資料 部分獲得鏈接）。您的發布版也有可能已經包含了一個操作碼緩存，只需安裝即可。

無論如何在系統上安裝 eAccelerator，都有一些配置選項需要注意。配置文件通常是 /etc/php.d/eaccelerator.ini。 eaccelerator.shm_size 定義共享高速緩存的大小，編譯后的腳本就存儲在這里。該值的單位是兆字節（MB）。根據您的應用程序確定恰當的大小。eAccelerator 提供了一個腳本來顯示緩存的狀態，其中包含內存占用，64MB 是個不錯的選擇（ eaccelerator.shm_size="64" ）。如果您選擇的值未被接受，那么必須修改內核的最大共享內存的大小。向 /etc/sysctl.conf 添加 kernel.shmmax=67108864 ，運行 sysctl -p 來使設置生效。 kernel.shmmax 值的單位是字節。

如果共享內存的分配超出極限，eAccelerator 必須將舊腳本從內存中清除。默認情況下，這是被禁用的； eaccelerator.shm_ttl = "60" 指定：當 eAccelerator 用完共享內存時，60 秒內未被訪問的所有腳本都將被清除。

另一種流行的 eAccelerator 替代工具是 Alternative PHP Cache（APC）。Zend 的廠商也提供了一種商業操作碼緩存，包括一個進一步提高效率的優化器。

php.ini

PHP 的配置是在 php.ini 中完成的。四個重要的設置控制 PHP 可使用多少系統資源，如表 1 所列。

具體數字主要取決于您的應用程序。如果要從用戶處接收大文件，那么 max_input_time 可能必須增加，可以在 php.ini 中修改，也可以通過代碼重寫它。與之類似，CPU 或內存占用較多的程序也可能需要更大的設置值。目標就是緩解超標程序的影響，因此不建議全局禁用這些設置。關于 max_execution_time ，還有一點需要注意：它表示進程的 CPU 時間，而不是絕對時間。因此一個進行大量 I/O 和少量計算的程序的運行時間可能遠遠超過 max_execution_time 。這也是 max_input_time 可以大于 max_execution_time 的原因所在。

PHP 可執行的日志記錄數是可配置的。在生產環境中，禁用除最重要的日志以外的一切日志記錄能夠減少磁盤寫操作。如果需要使用日志來排除問題，那么可以按需啟用日志記錄。 error_reporting = E_COMPILE_ERROR|E_ERROR|E_CORE_ERROR 將啟用足夠的日志記錄，使您發現問題，同時從腳本中消除大量無用的內容。

回頁首

結束語

分享這篇文章…… 將本文提交到 Digg 發布到 del.icio.us 提交到 Slashdot！

本文重點探討 Web 服務器的調優，包括 Apache 和 PHP。對于 Apache，總體的想法是消除 Web 服務器必須執行的多余檢查，例如處理 .htaccess 文件。還必須調優所用的多處理模塊，以便在使用的系統資源和可供傳入請求使用的空閑 worker 之間找到平衡。對于 PHP，最好的事情就是安裝一個操作碼緩存。密切注意幾個資源設置也能確保腳本不會浪費系統資源，不會減慢系統處理其他任務的速度。

本系列的下一篇也是最后一篇文章將介紹 MySQL 數據庫的調優。請繼續關注！