第 1 部分: 理解 lamp 架構
linux、apache、mysql 和 php（或 perl）是許多 web 應用程式的基礎 —— 從 to-do 列表到 blog，再到電子商務站點。wordpress 和 pligg 是兩個支援大容量 web 站點的常用軟體包。這種架構簡稱為 lamp。
幾乎每個 linux 發布版都包含 apache、mysql、php 和 perl，所以安裝 lamp 軟體是非常容易的。
安裝的簡便性使人誤以為這些軟體會自行順利地執行，但是實際情況並非如此。最終，應用程式的負載會超出後端伺服器自帶設定的處理能力，應用程式的效能會降低。lamp 安裝需要不斷監控、調優和評估。
系統調優對於不同的人有不同的含義。本系列主要關注 lamp 元件（linux、apache、mysql 和 php）的調優。對應用程式本身進行調優是另乙個複雜的問題。
應用程式和後端伺服器之間存在一種共生關係：未能適當調優的伺服器甚至會使最好的應用程式在負載之下崩潰，而借助充分的調優，完全可以避免編寫得很糟糕的應用程式使伺服器緩慢如牛。幸運的是，正確的系統調優和監視可以指出應用程式中的問題。
lamp 架構
對任何系統進行調優的第一步都是了解它的工作原理。按照最簡單的形式，基於 lamp 的應用程式是用 php 這樣的指令碼語言編寫的，它們作為 linux 主機上執行的 apache web 伺服器的一部分執行。
php 應用程式通過請求的 url、所有表單資料和已捕獲的任意會話資訊從客戶機獲得資訊，從而確定應該執行什麼操作。如有必要，伺服器會從 mysql 資料庫（也在 linux 上執行）獲得資訊，將這些資訊與一些 hypertext markup language（html）模板組合在一起，並將結果返回給客戶機。當使用者在應用程式中導航時，這個過程重複進行；當多個使用者訪問系統時，這個過程會併發進行。
但是，資料流不是單向的，因為可以用來自使用者的資訊更新資料庫，包括會話資料、統計資料（包括投票）和使用者提交的內容（比如評論或站點更新）。除了動態元素之外，還有靜態元素，比如影象、j**ascript **和層疊樣式表（css）。
lamp 的變體
lamp 最初是指 linux、apache、mysql 和 php（或 perl）。但是，如果管理員不擅長 linux，那麼可以在 microsoft windows 上執行 apache、mysql 和 php，這並非一種少見的情況。同樣，也可以將 apache 換成別的系統，比如 lighttpd，產生的仍然是 lamp 風格的系統，但是首字母縮寫不再是 lamp 了。
也可以改用另一種開放原始碼資料庫（比如 postgresql 或 sqlite）、商業資料庫（比如 ibm db2）或者免費的商業引擎（比如 ibm db2 express-c）。
本文主要關注傳統的 lamp 架構，因為這種架構是最常見的，而且它的元件都是開放原始碼的。
在研究 lamp 系統中的請求流之後，就來看看可能出現效能瓶頸的地方。資料庫提供許多動態資訊，所以資料庫對查詢的響應延遲都會反映在客戶機中。web 伺服器必須能夠快速地執行指令碼，還要能夠處理多個併發請求。
最後，底層作業系統必須處於良好的狀態才能支援應用程式。通過網路在不同伺服器之間共享檔案的其他設定也可能成為瓶頸。
度量效能
持續地對效能進行度量在兩個方面有幫助。首先，度量可以幫助了解效能趨勢，包括好壞兩方面的趨勢。作為乙個簡單的方法，檢視一下 web 伺服器上的**處理單元（cpu）使用率，就可以了解 cpu 是否負載過重。
同樣，檢視過去使用的總頻寬並推斷未來的變化，可以幫助判斷什麼時候需要進行網路公升級。這些度量最好與其他度量和觀測結合考慮。例如，當使用者抱怨應用程式太慢時，可以檢查磁碟操作是否達到了最大容量。
效能度量的第二個用途是，判斷調優是對系統效能有幫助，還是使它更糟糕了。方法是比較修改之前和之後的度量結果。但是，為了進行有效的比較，每次應該只修改乙個設定，然後對適當的指標進行比較以判斷修改的效果。
每次只修改乙個設定的原因應該是很明顯的：同時做出的兩個修改很可能會相互影響。選擇用來進行比較的指標比較微妙。
選擇的指標必須能夠反映應用程式使用者感覺到的響應。如果一項修改的目標是減少資料庫的記憶體佔用量，那麼取消各種緩衝區肯定會有幫助，但是這會犧牲查詢速度和應用程式效能。所以，應該選擇應用程式響應時間這樣的指標，這會使調優向著正確的方向發展，而不僅僅是針對資料庫記憶體使用量。
可以以許多方式度量應用程式響應時間。最簡單的方法可能是使用curl命令，見清單 1。
清單 1. 使用 curl 度量 web 站點的響應時間
清單 1 給出對乙個流行的新聞站點執行curl命令的情況。輸出通常是 html **，通過-o引數傳送到/dev/null。-s引數去掉所有狀態資訊。
-w引數讓curl寫出表 1 列出的計時器的狀態資訊：
表 使用的計時器
這些計時器都相對於事務的起始時間，甚至要先於 domain name service（dns）查詢。因此，在發出請求之後，web 伺服器處理請求並開始發回資料所用的時間是 0.272 - 0.
081 = 0.191 秒。客戶機從伺服器**資料所用的時間是 0.
779 - 0.272 = 0.507 秒。
通過觀察curl資料及其隨時間變化的趨勢，可以很好地了解站點對使用者的響應性。
當然，web 站點不僅僅由頁面組成。它還有影象、j**ascript **、css 和 cookie 要處理。curl很適合了解單一元素的響應時間，但是有時候需要了解整個頁面的裝載速度。
用於 firefox 瀏覽器的 tamper data 擴充套件（參見參考資料一節中的鏈結）可以在日誌中記錄 web 瀏覽器發出的每個請求，並顯示每個請求所用的**時間。使用這個擴充套件的方法是，選擇tools > tamper data來開啟 ongoing requests 視窗。裝載要考察的頁面，然後就會看到瀏覽器發出的每個請求的狀態和裝載每個元素所用的時間。
圖 1 給出裝載 developerworks 主頁的結果。
圖 1. 用於裝載 developerworks 主頁的請求細目
每一行描述乙個元素的裝載情況。顯示的資料報括發出請求的時間、裝載所用的時間、大小和結果。duration 欄列出裝載元素本身所用的時間，total duration 欄列出所有子元素所用的時間。
在圖 1 中，裝載主要頁面所用的時間是 516 毫秒（ms），但是裝載所有東西並顯示整個頁面所用的時間是 5101 ms。
tamper data 擴充套件有一種有用的模式，將頁面裝載資料的輸出繪製成圖形。右擊 ongoing requests 視窗上半部分的任何地方，並選擇graph all。圖 2 顯示圖 1 中資料的圖形化檢視。
圖 2. 用於裝載 developerworks 主頁的請求的圖形化檢視
在圖 2 中，每個請求的持續時間顯示為深藍色，並相對於頁面裝載的啟始時間顯示。所以，可以看出哪些請求使整個頁面的裝載變慢了。
LR 系統效能調優
效能測試分析人員經過對結果的分析以後，有可能提出系統存在效能瓶頸。這時相關開發人員 資料庫管理員 系統管理員 網路管理員等就需要根據效能測試分析人員提出的意見同效能分析人員共同分析確定更細節的內容，相關人員對系統進行調整以後，效能測試人員繼續進行第二輪 第三輪 的測試，與以前的測試結果進行對比，從而...
效能調優總結
深圳割接效能調優總結 bss測試部 鄒家勇 hsc從一開始對訂購關係與三戶資料同步介面進行壓測時，不能滿足性要求到最後效能壓測結果達到要求的10倍效能以上，經過了以下幾個關鍵的優化步驟。在壓測時首先要排除的是高消耗sql 經過awr報告分析後hsc沒有出現高消耗sql 本次sz割接壓測經過以下幾個關...
提公升系統效能
登錄檔是windows程式設計師建造的乙個複雜的資訊資料庫，它是多層次式的。在不同系統上登錄檔的基本結構相同。其中的複雜資料會在不同方式上結合，從而產生出乙個絕對唯一的登錄檔。為此,通過更改登錄檔可以產生很多不同的作用,今天為大家講解的是利用登錄檔提公升系統效能.儘管修改登錄檔對系統影響不像想象中恐...