性能測試的目的就評估當前系統性能的指標，分析定位解決性能瓶頸，預防規避性能風險。
性能分析是爲了確定導致性能瓶頸的原因，而調優就是用來解決性能瓶頸。
通過某些手段讓系統性能得到提高，是性能調優的主要目的。
性能分析主要有兩種方法：
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 發生的列，可考慮建立聚集索引。
》經常同時存取多列，且每列都要包含有重複值可考慮建立組合索引
》組合索引要儘量使用關鍵查詢形成索引覆蓋，其前導列一定是使用最頻繁的列。
* IS NULL 與IS NOT NULL 不能用NULL作爲索引，任何包含NULL值得列都將不會被包含在索引中。