效能測試的目的就評估當前系統效能的指標，分析定位解決效能瓶頸，預防規避效能風險。
效能分析是為了確定導致效能瓶頸的原因，而調優就是用來解決效能瓶頸。
通過某些手段讓系統效能得到提高，是效能調優的主要目的。
效能分析主要有兩種方法：
1.將測試結果與使用者需求做比較，如果達到使用者需求，則測試通過。
*系統滿足10萬註冊使用者（其中1萬為活躍使用者）的訪問
*系統處理能力，20個註冊/秒，45個併發瀏覽/秒，35個登入操作/秒。
*伺服器資源利用率在滿負荷的情況下，忙時峰值cpu負載不超過75%，記憶體占用不超過80%。
例如：需要賽前對乙個要參加100公尺跑的選手進行效能測試，為了確保冠軍，那麼首先就要明確，第一名所需要達到的指標。（100公尺跑的總時間），對其進行效能測試，當發現測試結果能夠達到冠軍指標後，效能測試即結束。
2.最優化分析法
通過分析並消除系統效能瓶頸，使系統的處理能力達到最大化，系統資源得到充分利用。
效能調優也分為兩種方法
1.應用程式診斷
應用程式診斷是效能測試的最初目的。通過模擬多使用者操作形成負載。檢驗應用程式是否能夠滿足使用者效能需求。
如果不滿足，則定位應用瓶頸，並尋找解決該瓶頸的方案。確保系統在修正後能夠滿足使用者需求。對於乙個專案來說，一般以應用診斷為主。
2。效能調優
在效能調優中，最基本的目標是滿足使用者，而進一步的目標是超越自己，此時要做的就是要讓系統比以前更加優秀的執行，通過生成負載，對測試結果進行分析，並且準備大量的軟硬體環境進行迭代測試，找出影響效能的要素，最終提公升效能。
一般產品都用採用系統調優的方式來逐步完善系統效能。
1）硬體上的瓶頸
一般指的是cpu \ram的問題，分為伺服器硬體瓶頸、網路瓶頸（對區域網可以不考慮）、伺服器作業系統瓶頸（引數配置）、中介軟體瓶頸（引數配置、資料庫、web伺服器等），應用瓶頸（資料庫設計、sql語句、業務邏輯、演算法等）
例如：確定了在伺服器資料庫上需要6個cpu、12gb記憶體，但是在測試時發現，cpu的持續利用率超過95%，這時可以認為在硬體上出現了效能瓶頸。
2）應用軟體上的瓶頸
一般指的是應用伺服器、web伺服器等應用軟體，還包括資料庫系統。
例如：在weblogic平台上配置了jdbc連線池的引數，最大連線數為50，最小連線數為5，增加量為10。測試時發現，當負載增加時，現有的連線數不足，系統會動態生成10個新的連線，導致交易處理的響應時間大大增加。這時可以認為在應用軟體上出現了效能瓶頸。
3）應用程式上的效能瓶頸
一般指的是開發人員新開發出來的應用程式。
例如：程式設計師開發了乙個繳費處理程式，在測試時發現，這個繳費處理程式在處理使用者併發繳費請求時，只能序列處理，無法並行處理，導致繳費處理響應時間非常長，這個可以認為在應用程式上出現了效能瓶頸。
4）作業系統上的效能瓶頸
一般指的是linux windows unix等作業系統
例如：在windows上對某軟體進行效能測試，出現物理記憶體不足時，如果虛擬記憶體設定也不合理，虛擬記憶體的交換效率就會大大降低，從而導致行為的響應時間大大增加。這時可以認為在作業系統上出現了效能瓶頸。
5）網路裝置上的效能瓶頸
一般指的是防火牆、動態負載生成器、交換機等裝置。
例如：在動態負載均衡器上設定了動態分發負載的機制，當發現某個應用伺服器上的硬體資源已經達到極限時，動態負載均衡器將後續的交易請求分發到其他負載較輕的應用伺服器上，在測試時發現，動態負載均衡機制沒有起到相應的作用，這時可以認為在網路裝置上出現了效能瓶頸。
效能出現的原因及其定位是十分複雜的，這裡只是簡單的介紹幾種常見的效能瓶頸型別及特徵，而效能測試所需要做的就是根據各種情況因素進行綜合考慮，然後協助開發人員一起定位效能瓶頸。
一般效能調優的步驟：
1.確定問題
*應用程式**：很多情況下，很多程式的效能問題都是寫出來的。因此，對於發現瓶頸的模組，首先應該檢查一下**。
*資料庫配置：經常引起整個系統執行緩慢，一些諸如oracle的大型資料庫都是需要dba進行正確的引數調整
才能投產的。
*作業系統配置：不合理就可能引起系統瓶頸。
*硬體設定：硬碟速度、記憶體大小等都是容易引起瓶頸的原因，因此這也是分析的重點原因
*網路：網路負載過重會引起網路衝突和網路延遲。
確定原因：
當確定了問題之後，我們要明確這個問題影響的是響應時間吞吐量還是其他的問題。是多數使用者還是少數使用者遇到這個問題。如果是少數使用者，這幾個使用者的操作與其他人有什麼不同。系統資源監控的結果是否正常？cpu的使用是否達到極限？i/o情況如何？問題是否集中在某一類模組中？是客戶端還是伺服器出現問題？系統硬體配置是否夠用？實際負載是否超過了系統的負載能力？是否未對系統進行優化？
通過這些分析及與系統相關的問題，可以對系統瓶頸有更深入的了解，進而分析出真正的原因。
3.確定調整目標和解決方案
提高系統吞吐量，縮短響應時間，更好的支援併發。
4.測試解決方案
對通過解決方案調優後的系統進行基準測試。
5.分析調優結果
系統調優是否達到或者超出了預定目標？系統是整體效能得到了改善還是以犧牲某部分效能來解決其他問題？調優是否結束了？
最後，如果達到了預期目標，調優工作就基本上可以結束了。
例如：在資料庫查詢中經常出現查詢響應時間較長的問題，解決這種sql查詢響應時間長的問題通常以使用索引來解決問題。
什麼是索引？
比如，你有很多的小抽屜，每個抽屜內都有一些雜物，假如你要找東西，最原始的方法就是乙個抽屜乙個抽屜的翻，這就是沒有索引的情況。
聰明一點，給每個抽屜乙個編號（唯一鍵），把哪個號碼有什麼東西都記錄在紙上。找東西先看看這張紙，這就是普通索引。加入你要知道哪個抽屜有什麼，你可以在紙上迅速的找到抽屜號碼，（大家都知道這種使用查詢樹），
然後得到相關的資訊。這種情況普通索引是很快的。但是要找到特定的東西哪些抽屜有，就需要將整張紙遍歷一遍，這就是like查詢。假如你要找哪些抽屜同時有兩種甚至更多種東西，like就更加繁瑣了。假如乙個表有上千萬的記錄，大家可以想象查詢的代價。
在索引中又分為聚集索引和非聚集索引兩種模式。
聚集索引：
表中儲存的資料按照索引的順序儲存，檢索效率比普通索引高，索引占用硬碟儲存空間小（1%左右），但對資料的新增/修改/刪除的速度影響比較大。
如下：*無索引，資料無序
*有索引，資料與索引同序
*資料會根據索引的順序重新排列資料。
*乙個表只能有乙個索引。
*葉節點指標指向的資料也在同一位置儲存。
tsql語法：
create clustered index idxempid on emp(empid)
2)非聚集索引
不影響表中的資料儲存順序，檢索效率比聚集索引低，索引占用硬碟儲存空間大（30%~40%），對資料新增/修改/刪除的影響很少。特點如下：
*乙個表可以最多建立249個非聚集索引。
*先建聚集索引才能建立非聚集索引
*非聚集索引資料與索引不同序
*資料與非聚集索引在不同位置
*非聚集索引在葉節點上儲存，在葉節點上有乙個『指標』直接指向要查詢的資料區域。
*資料不會根據非聚集索引鍵的順序重新排列資料。
tsql語法：create nonclustered index idximpid on emp(empid)
對於索引有一些錯誤的觀點，具體如下：
*主鍵就是聚集索引
*只要建立索引就能顯著提高查詢速度
*把所有需要提高查詢速度的字段都加進聚集索引，以提高查詢速度。
一般來說以下規則是正確的：
*用聚集索引比引用非聚集索引的主鍵速度快
*用聚集索引比用一般的主鍵做order by時速度快，特別是在小資料量情況下。
*使用聚集索引內的時間段，搜尋時間會按資料佔整個資料表的百分比成比例減少，而無論聚集索引使用了多少個
*『水可載舟，亦可覆舟』，索引也一樣，不要過度使用索引。
對於sql語句優化的額基本原則如下。
*使用索引更快地遍歷表。預設情況下建立的索引是非聚集索引，但有時它並不是最佳的。在非聚集索引下，資料在物理機上隨機存放在資料頁上。合理的索引設計要建立在對個彙總查詢的分析和**上，一般來說：
》有大量重複值且經常有範圍查詢（between,>,<,>=,<=)和order by、group by 發生的列，可考慮建立聚集索引。
》經常同時訪問多列，且每列都要包含有重複值可考慮建立組合索引
》組合索引要盡量使用關鍵查詢形成索引覆蓋，其前導列一定是使用最頻繁的列。
MySQL效能測試調優
作業系統 基本操作 檢視磁碟分割槽mount選項 mount 永久修改分割槽mount選項 系統重啟後生效 修改檔案 etc fstab 中對應分割槽的mount options列的值 sudo t ext4 o remount,noatime,errors remount or 檔案系統優化 ex...
調優 Nginx效能調優
一.nginx優化配置 1.主配置檔案優化 注 部分配置詳解 worker processes 8 nginx程序數，建議按照cpu數目來指定，一般為它的倍數。worker cpu affinity 00000001 00000010 00000100 00001000 00010000 00100...
效能測試之Nginx效能調優課程
效能測試之nginx效能調優 課程出自 學途無憂網 課程從介紹nginx開始，包括nginx的安裝 配置 監控 調優等方方面面，可以全面深入淺出的學習nginx。課時1 nginx為什麼這麼牛b 課時2 linux下快速安裝nginx 課時3 nginx監控分析神器 課時4 nginx關鍵引數分析 ...