簡介
Wikipedia、Facebook 和 Yahoo! 等主要 web 屬性使用 LAMP 架構來為每天數百萬的請求提供服務，而 Wordpress、Joomla、Drupal 和 SugarCRM 等 web 應用程序軟件使用其架構來讓組織輕松部署基於 web 的應用程序。
該架構的優勢在於其簡單性。而 .NET 這樣的堆棧和 Java™ 技術可能使用大量硬件、昂貴的軟件棧和復雜的性能調優，LAMP 堆棧可以運行於商品硬件之上，使用開源軟件棧。由於軟件棧是一個松散的組件集，而非一個整體堆棧，性能調優是一大挑戰，因為需要分析和調優每個組件。
然而，這有幾個個簡單性能任務會對任何規模的網站的性能產生巨大的影響。在本文中，我們將探討旨在優化 LAMP 應用程序性能的 5 個這樣的任務。這些項目應當很少需要對您的應用程序進行架構更改，使其成為最大化您的 web 應用程序所需的響應能力和硬件需求的安全、便捷的選擇。
使用操作碼緩存
提高任何 PHP 應用程序（當然是 LAMP 中的 “P”）的性能的最簡單方式是利用一個操作碼緩存。對於我使用的任何網站，它是我確保存在的一項內容，因為性能影響很大（很多時候有了操作碼緩存，響應時間可減少一半）。但是對 PHP 不熟悉的大部分人的一個很大的疑問是，為何改進會如此之大。答案在於 PHP 如何處理 web 請求。圖 1 概覽了 PHP 請求的流程。
圖 1. PHP 請求
由於 PHP 是一種解釋語言，而非 C 或 Java 等編譯語言，對每個請求執行了 “解析-編譯-執行” 的整個步驟。您可以看到為何這會耗時、耗資源，特別是當腳本在請求之間很少變化時。解析和編譯腳本之後，腳本作為一系列操作碼處於機器可解析狀態。這是操作碼緩存發揮效用的地方。它作為一系列操作碼緩存這些編譯腳本，以避免為解析和編譯每個請求步驟。您將在圖 2 中看到這樣的工作流是如何運作的。
圖 2. PHP 請求使用操作碼緩存
因此當 PHP 腳本的緩存操作碼存在時，我們可以跳過 PHP 請求流程的解析和編譯步驟，直接執行緩存操作碼並輸出結果。檢查算法負責處理您可能對腳本文件進行了更改的情況，因此在已變更腳本的第一個請求後，會為隨後的請求自動重新編譯和緩存操作碼，替換緩存的腳本。
操作碼緩存對於 PHP 流行已久，其中早期的一些要追溯到 PHP V4 的全盛期。目前有一些流行選項正在積極開發和使用中：
毫無疑問，一個操作碼緩存是通過在每次請求後消除解析和編譯腳本的需要來加速 PHP 的第一步。完成第一步之後，您應當看到響應時間和服務器負載方面的改進。但是優化 PHP 可以做的不止這些，我們接下來將加以討論。
優化您的 PHP 設置
雖然實現操作碼緩存是性能改進的一大創舉，不過也有大量其他優化選項可供您基於 php.ini 文件中的設置優化您的 PHP 設置。這些設置更適合於生產實例；在開發或測試實例上，您可能不希望做這些變更，因為它會使得應用程序問題的調試變得更難。
讓我們看一下對於性能提升很重要的一些項目。
應當禁用的選項
有若干 php.ini 設置應當予以禁用，因為它們常用作向後兼容性：
register_globals — 在 PHP V4.2 之前該功能常常是默認值，其中傳入的請求變量被自動賦給普通 PHP 變量。這樣做除了引起重大安全問題之外（使未過濾的傳入請求數據與普通 PHP 變量內容相混），對每一個請求這樣做還會產生開銷。因此禁用這一設置使您的應用程序更安全且能提高性能。
magic_quotes_* — 這是 PHP V4 的另一遺留項，其中傳入的數據會自動避開有風險的表單數據。它旨在作為一個安全特性，在將傳入的數據發送到數據庫之前對其進行整理，但不是很有效，因為它不能幫助用戶預防常見的 SQL 注入攻擊。由於大部分數據庫層支持能更好地處理該風險的准備語句，禁用該設置會再次消除這個煩人的性能問題。
always_populate_raw_post_data — 這僅當您出於某些原因需要查看傳入的未過濾 POST 數據的整個負載時才需要。否則，它僅在內存中存儲 POST 數據的一個副本，而這沒有必要。 然而，在遺留代碼上禁用這些選項會有風險，因為它們可能取決於其設置來實現正確執行。不應當基於被設置的這些選項來開發任何新代碼，而且可能的話，您應當尋求方法來重構您的現有代碼，避免使用它們。
應當禁用或調整設置的選項
您可以啟用 php.ini 文件的一些優秀性能選項，來提升您的腳本速度：
output_buffering — 您應當確保啟用該選項，因為它會以塊為單位將輸出刷回到浏覽器，而非以每個 echo 或 print 語句為單位，而後者會大大減緩您的請求響應時間。
variables_order — 這個指令控制傳入請求的 EGPCS（Environment、Get、Post、Cookie 和 Server）變量解析順序。如果您沒有使用某種超全局變量（比如環境變量），您可以安全地刪除它們來獲得一點加速，從而避免在每一個請求上解析它們。
date.timezone — 這是在 PHP V5.1 中添加的一個指令，用於設置默認時區，然後用於後面將要介紹的 DateTime 函數。如果您不在 php.ini 文件中設置該選項，PHP 會執行大量系統請求來弄清它是什麼，且在 PHP V5.3 中，對每一個請求會發出一個警告。 就以應當在您的生產實例上配置的設置而言，這些被看作是 “唾手可得”。就 PHP 而言，還有一件事需要考慮。這就是您的應用程序中 require() 和 include()（以及其同級 require_once() 和 include_once()）的使用。這些函數優化您的 PHP 配置和代碼，以防止對每個請求進行不必要的文件狀態檢查，從而減少響應時間。
管理您的 require() 和 include()
從性能來看，文件狀態調用（即為檢查一個文件是否存在而對底層文件系統進行的調用）相當昂貴。文件狀態的最大元凶之一以 require() 和 include() 語句的形式出現，這兩個語句用於將代碼帶到腳本中。require_once() 和 include_once() 的同級調用更成問題，因為它們不僅需要驗證文件是否存在，而且它之前沒有包含在內。
那麼解決這個問題的最好方式是什麼？您可以做一些事來加快解決。
require() 和 include() 調用使用絕對路徑。這將使 PHP 更清楚您希望包含的確切文件，因此無需為您的文件檢查整個 include_path。
include_path 中的條目數較低。這在很難為每個 require() 和 include() 調用提供絕對路徑的情況（通常在大型遺留應用程序中會出現這種情況）下很有用，方法就是不檢查您包含的文件不在的位置。 APC 和 Wincache 還有用於緩存 PHP 進行的文件狀態檢查結果的機制，因此無需進行反復的文件系統檢查。當您將 include 文件名保留為靜態而非變量驅動的時，它們最有效，因此盡可能嘗試這樣做很有用。
優化您的數據庫
數據庫優化很快會成為一個前沿話題，我幾乎沒有空間在這裡完全公正地做這個話題。但是如果您在尋求優化您的數據庫的速度，首先應當采取一些步驟，這應當對常見問題有所幫助。
將數據庫放在自己的機器上
數據庫查詢自身可以變得相當激烈，通常在對大小合理的數據集執行簡單的 SELECT 語句時限定在 100% 的 CPU。如果您的 web 服務器和數據庫服務器都在竟用單一機器上的 CPU 時間，這無疑將減慢您的請求速度。因此我想第一步最好是將 web 服務器和數據庫服務器放在單獨的機器上，確保您的數據庫服務器是兩者中更強健的（數據庫服務器喜歡大量內存和多個 CPU）。
合理設計和編制表索引
數據庫性能的最大問題可能源自於不良數據庫設計和缺失索引。SELECT 語句通常是運行在典型 web 應用程序中的最常見的查詢類型。它們也是在數據庫服務器上運行的最耗時的查詢。此外，這些類型的 SQL 語句對適當的索引和數據庫設計最敏感，因此查看以下指示，獲取實現最優性能的技巧。
NULL 值字段浪費磁盤空間。文本或 blob 等可變大小字段也是如此，其中表大小的增長可以遠超過需求。在這種情況下，您應當考慮將其他欄分成不同的表，在記錄的主鍵上將其聯合起來。 分析在服務器上運行的查詢
改進數據庫性能的最佳方法是分析在您的數據庫服務器上運行什麼查詢，且運行它們需要多長時間。幾乎每個數據庫都有具有這種功能的工具。對於 MySQL，您可以利用慢查詢日志來查找有問題的查詢。要使用它，在 MySQL 配置文件中將 slow_query_log 設置為 1，然後將 log_output 設置為 FILE，將它們記錄到文件 hostname-slow.log 中。您可以設置 long_query_time 阈值，確定查詢必須運行多少秒才被看作是 “慢查詢”。我想建議將該阈值首先設置為 5 秒，隨著時間的推移將其縮減為 1 秒，具體取決於您的數據集。如果您探究該文件，您會看到類似於清單 1 的詳細查詢。
清單 1. MySQL 慢查詢日志
/usr/local/mysql/bin/mysqld, Version: 5.1.49-log, started with: Tcp port: 3306 Unix socket: /tmp/mysql.sock Time Id Command Argument # Time: 030207 15:03:33 # User@Host: user[user] @ localhost.localdomain [127.0.0.1] # Query_time: 13 Lock_time: 0 Rows_sent: 117 Rows_examined: 234 use sugarcrm; select * from accounts inner join leads on accounts.id = leads.account_id;
我們想要考慮的關鍵對象是 Query_time，顯示查詢需要的時間。另一項要考慮的是 Rows_sent 和 Rows_examined 的數量，因為這些可指這樣的情況：其中如果一個查詢察看太多行或返回太多行，就會被錯誤地書寫。您可以更深入地鑽研如何寫查詢，即在查詢開始處加上 EXPLAIN，它會返回查詢計劃，而非結果集，如清單 2 所示。
清單 2. MySQL EXPLAIN 結果
mysql> explain select * from accounts inner join leads on accounts.id = leads.account_id; +----+-------------+----------+--------+--------------------------+---------+--- | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+----------+--------+--------------------------+---------+-------- | 1 | SIMPLE | leads | ALL | idx_leads_acct_del | NULL | NULL | NULL | 200 | | | 1 | SIMPLE | accounts | eq_ref | PRIMARY,idx_accnt_id_del | PRIMARY | 108 | sugarcrm.leads.account_id | 1 | | +----+-------------+----------+--------+--------------------------+---------+--------- 2 rows in set (0.00 sec)
MySQL 手冊更深入探究 EXPLAIN 輸出的主題（參見 參考資料），但是我考慮的一項重要內容是 ‘type' 列為 ‘ALL' 的地方，因為這需要 MySQL 做一個全表掃描，且不需要鍵來執行查詢。這些幫助您在添加索引時會大幅提高查詢速度。
有效緩存數據
正如我們在上一節看到的，數據庫往往容易成為您 web 應用程序性能的最大痛點。但是如果您要查詢的數據不經常改變怎麼辦？在這種情況下，一個好的選擇就是在本地存儲這些結果，而非針對每個請求調用查詢。
我們之前探究的兩個操作碼緩存 APC 和 Wincache 具有實現上述操作的工具，其中您可以將 PHP 數據直接存儲到一個共享內存段中，便於快速查詢。清單 3 提供了具體示例。
清單 3. 使用 APC 緩存數據庫結果的示例
<?php
function getListOfUsers()
{
$list = apc_fetch('getListOfUsers');
if ( empty($list) ) {
$conn = new PDO('mysql:dbname=testdb;host=127.0.0.1', 'dbuser', 'dbpass');
$sql = 'SELECT id, name FROM users ORDER BY name';
foreach ($conn->query($sql) as $row) {
$list[] = $row;
}
apc_store('getListOfUsers',$list);
}
return $list;
}
我們僅需一次執行查詢。之後，我們將結果推送到 getListOfUsers 鍵下的 APC 緩存中。從這裡開始，直到緩存到期，您就能夠直接從緩存中獲取結果數組，跳過 SQL 查詢。
APC 和 Wincache 並非一個用戶緩存的惟一選擇；memcache 和 Redis 是不需要您在與 Web 服務器相同的服務器上運行用戶緩存的其他流行選擇。這就提高了性能和靈活性，特別是當您的 web 應用程序跨多個 Web 服務器向外擴展時。
在本文中，我們探究了調優您的 LAMP 性能的 5 種簡單方法。我們不僅通過利用一個操作碼緩存和優化 PHP 配置探究了 PHP 級別的技術，而且探究了如何優化您的數據庫設計來實現合理的索引編制。我們還探討了如何利用一個用戶緩存（以 APC 為例）來展示如何在數據不經常改變時避免重復的數據庫調用。
