性能方案
性能目標：
1、最大並發數
2、Quality of Service 服務的質量，在軟件系統方面我們認為主要表現在請求的出錯率，系統的load等。
3、最長響應時間
對於任何請求所能承受的最大響應時間。
4、TPS
每秒需要支持的最大事務數，最典型的指標是：“某頁面最高需要支撐每秒7000次的訪問次數”。
Throughput吞吐量： 吞吐率=吞吐量/測試時間
Hits per second點擊量：點擊率=點擊量/測試時間
OA系統，總用戶數10000人，希望並發用戶達到200人，我應該如何設置壓力場景測試？
測試壓力估算時采用原則如下：
系統在線用戶並發數取在線用戶數的30%，即：200*30%=60
此次性能測試用戶數分三個檔次：50並發，100並發，150並發,200並發。
並分別對三種情況進行性能測試記錄測試結果
並對測試結果進行分析，特別關注150並發時系統的性能。
系統響應時間判斷原則（2-5-10原則）如下：
系統業務響應時間小於2秒，判為優秀，用戶對系統感覺很好；
系統業務響應時間在2-5秒之間，判為良好，用戶對系統感覺良好；
系統業務響應時間在5-10秒之間，判為及格，用戶對系統可以接受；
系統業務響應時間超過10秒，判斷為不及格，用戶不能接受系統的響應速度；
設計思想：大量用戶同時使用某個功能和長時間反復運行，以檢查系統並發性能和長期運行的穩定性。
測試內容： 取幾個普通用戶日常辦公中經常使用到的操作或場景，錄制為一個腳本。
測試步驟： 使用性能測試工具Loadrunner運行負載測試，添加錄制好的某一個場景腳本和分別加載50/100/150/200個虛擬用戶進行並發測試。
場景類型：手動場景，通過制定要運行的虛擬用戶數來管理負載測試
場景計划名：默認計划
模式：場景計划
場景持續時間：直到完成
加載行為：同時加載所有Vuser
用戶加載並發數量：50/100/150
負載生成器：localhost
思考時間：按錄制參數
預期結果：
(1)測試過程中服務器資源占用CPU（均值小於70%），內存（均值小於80%，或者使用期間沒有內存泄漏和錯誤產生），IO-Wait（均值小於10%）（資源占用可根據需要進行調整，或者沒有預期，只是測試一個結果，如果測試結果較好就繼續加壓，測試結果不好就考慮進行優化）
(2)業務成功率目標100%（成功90%，失敗10%，各種返回比例滿足事先的預期設計比例值）
(3)其他業務需求
OK,還需要一些測試安排計划和測試風險的評估，補充到測試方案里面。一個基本的測試方案基本就可以算是完成了。
並發數
【經典案例1】上班簽到系統，早上8點上班，7點半到8點的30分鍾的時間里用戶會登錄簽到系統進行簽到。公司員工為1000人，平均每個員上登錄簽到系統的時長為5分鍾。可以用下面的方法計算。
C=1000/30*5=166.7
C表示平均並發用戶數，那么對這個簽到系統每分鍾的平均在線用戶數為166
系統吞度量要素
一個系統的吞度量（承壓能力）與request對CPU的消耗、外部接口、IO等等緊密關聯。單個reqeust 對CPU消耗越高，外部系統接口、IO影響速度越慢，系統吞吐能力越低，反之越高。
系統吞吐量幾個重要參數：QPS（TPS）、並發數、響應時間
QPS（TPS）：每秒鍾request/事務 數量
並發數： 系統同時處理的request/事務數
響應時間： 一般取平均響應時間
（很多人經常會把並發數和TPS理解混淆）
理解了上面三個要素的意義之后，就能推算出它們之間的關系：
QPS（TPS）= 並發數/平均響應時間 或者 並發數 = QPS*平均響應時間
LoadRunner圖表分析
Mercury Loadrunner Analysis中最常用的5種資源
1. Vuser
2. Transactions
3. Web Resources
4. Web Page Breakdown
5. System Resources
在Analysis中選擇“Add graph”或“New graph”就可以看到這幾個資源了.還有其他沒有數據的資源,我們沒有讓它顯示.
如果想查看更多的資源,可以將左下角的display only graphs containing data置為不選.然后選中相應的點“open graph”即可.
打開Analysis首先是Summary Report.顯示了測試的分析摘要.下面介紹一下含義：
Duration(持續時間)：了解該測試過程持續時間.測試人員本身要對這個時期內系統一共做了多少的事有大致的熟悉了解.以確定下次增加更多的任務條件下測試的持續時間。
Statistics Summary(統計摘要)：只是大概了解一下測試數據,對我們具體分析沒有太大的作用.
Transaction Summary(事務摘要)：了解平均響應時間Average單位為秒. 其余的看不看都可以.都不是很重要.
Analysis summary （場景摘要）
Secenario name 場景名稱
Results in session 場景運行的結果目錄
Duration 場景運行時間
Statistics summary（場景狀態的統計說明）
Maximum running vusers（場景最大用戶數）
Total throughput （bytes）（總帶寬流量）
Average throughput （bytes/second）（平均每秒寬帶流量）
Total hit （總點擊數）
Average hits per second （平均每秒點擊數）
單擊View HTTP Responses summary 選項可以切換到報告最下方HTTP請求的統計
（5worst transaction）5大失敗事務的統計
Transaction name （事務名）
Failure ratio[%] （exceeded time/transaction duration）失敗率（超標次數/事務持續時間）。該值反映了在所有事務中有百分之多少的事務是無法達到SLA基准值的
Failure value[%](response time /SLA) 失敗率（響應時間/SLA） 該值反映了在整個場景運行下，SLA的定義標准值與實際事務值超標的平均百分比，也就是說平均算下來真實的響應時間和定義的閾值誤差百分比 最下方列出了平均誤差和最大誤差
scenario behavior over time（場景行為綜述）
在場景中定義的事務在各個時間點上的SLA情況，背景中的X表示在這個時間點上事務沒有達到SLA的指標，而上面的application under test error顯示了在每個時間段上的錯誤
transaction summary（事務摘要）
Total passed （事務總通過數）
Total failed （事務的總失敗數）
Total stopped （事務的總停止數）
Average response time 可以打開事務平均響應時間圖表
Transaction name （事務名）
SLA status （SLA狀態）：在SLA的指標測試中最終結果圖是通過還是失敗
Minimum（事務最小時間）
Average （事務平均時間）
Maximum （事務最大時間）
Std.deviation（標准方差）
90percent（用戶感受百分比）這個值說明，采樣數據中，有90%的數據比它大，10%的數據比它小（舉例，假設有組數據（13465782910）按從小到大的排列后就是（12345678910），在這10個數中第9大的數字是9所以90percent的結果就是9），90percent是可以調整的，在（analysis-View-summary files –transaction percentile）
Service level agreement legend（SLA圖標說明）
http responses summary（http響應摘要）
Total http請求返回次數 Per second 每秒請求數
hits per second（每秒點擊數）
每秒點擊數每一次點擊相當於對服務器發出一次請求，一般點擊數會隨着負載的增加而增加，該數據越大越好。
throughput（帶寬使用）
該數據越小說明系統的寬帶依賴越小
網絡帶寬是否足夠?
“Throughput”圖顯示在場景運行期間的每一秒鍾，從Web Server 上接受到的數據量的值。 拿這個值和網絡帶寬比較，可以確定目前的網絡帶寬是否是瓶頸。
如果該圖的曲線隨着用戶數的增加，沒有隨着增加，而是呈比較平的直線，說明目前的 網絡速度不能夠滿足目前的系統流量。
transaction summary（事務概要說明）
通過事務數越多說明系統的處理能力越強，失敗的事務越少，說明系統越可靠
average transaction response time（每秒事務數）
時間越小說明處理的速度越快，如果和前面的用戶負載生成圖合並在一起看，就可以發現用戶負載增加對系統事務響應時間的影響規律（事務的響應時間也不應該超過用戶的最大接受范圍，否則會出現系統響應過慢的問題）
Average transaction response time（平均事務響應時間）
TPS也是一個關鍵的數據，該數據反映了系統在同一時間內能處理業務的最大能力，這個數據越高，說明系統處理能力越強，但是這里的最高值並不一定代表系統的最大處理能力，TPS會受到負載的影響，也會隨着負載的增加而逐漸增加，當系統進入繁忙期后，TPS會有所下降
transaction performance summary（事務性能概要）
這里給出了事務的平均時間、最大時間、最小時間，柱狀圖的落差越小說明響應時間的波動較小，如果落差很大，那么說明系統夠穩定
transaction response time under load（在用戶負載下事務響應時間）
負載用戶增長的過程中響應時間的變化情況，其實這張圖也是將uers和average transaction response圖做了一個correlate Merge 得到的，該圖的線條越平越穩，說明系統越穩定
transaction response time （percentile）（事務響應時間的百分比）
不同百分比下的事務響應時間范圍，通過這個圖可以了解有多少比例的事務發生在某個時間內，也可以發現響應時間的分布規律，數據月平穩說明響應時間編號越小
Transaction response time （distribution）（每個時間段上的事務數）
該圖給出的是每個時間段上的事務數，響應時間較小的分類下的事務數越多越好
看 Transaction Response Time 圖，可以判斷每個事務完成用的時間，從而可以判斷出那個事 務用的時間最長，那些事務用的時間超出預定的可接受時間。
下圖可以看出，隨着用戶數的不斷增加，login 事務的響應時間增長的最快！
分析事務的響應時間
第一步，看“Transaction Performance Summary”圖，確認那個事務的響應時間比較大， 超出了我們的標准。看下圖，login 事務的平均響應時間最長。
然后我們再看“Average Transaction Response Time”，觀察login 在整個場景運行中每一 秒的情況。從圖中可以看出，login 事務的響應時間並不是一直都比較高，只是隨着用戶數 的增加，響應時間才明顯增加的。
為了定位問題，明白為什么login 事務的響應時間比較長，現在我們要分解login 事務， 分析該頁面上每一個元素的性能。在上圖中，選擇要分解的事務曲線，然后點鼠標右鍵，選 擇“Web Page Breakdown for login”
1. 瀏覽器向 Web Server 發送請求，一般情況下，該請求首先發送到DNS Server 把DNS 名字解析成IP 地址。解析的過程的時間就是。這個度量時間可以
確定DNS 服務器或者DNS 服務器的配置是否有問題。如果DNS Server 運行情況 比較好，該值會比較小。
2. 解析出 Web Server 的IP 地址后，請求被送到了Web Server，然后瀏覽器和Web Server 之間需要建立一個初始化連接，建立該連接的過程就是。這個
度量時間可以簡單的判斷網絡情況，也可以判斷Web Server 是否能夠響應這個請 求。如果正常，該值會比較小。
3. 建立連接后，從Web Server 發出第一個數據包，經過網絡傳輸到客戶端，瀏覽器 成功接受到第一字節的時間就是。這個度量時間不僅可以表示Web Server 的延遲時間，還可以表示出網絡的反應時間。
4. 從瀏覽器接受到第一個字節起，直到成功收到最后一個字節，下載完成止，這段時 間就是。這個度量時間可以判斷網絡的質量（可以用size/time 比來計算 接受速率）
其他的時間還有 SSL Handshaking（SSL 握手協議，用到該協議的頁面比較少）、Client Time（請求在客戶端瀏覽器延遲的時間，可能是由於客戶端瀏覽器的think time 或者客戶端 其他方面引起的延遲）、Error Time（從發送了一個HTTP 請求，到Web Server 發送回一個HTTP 錯誤信息，需要的時間）。
熟悉了以上各個時間的含義后，我們開始看分解頁面的圖形。
首先看“Downlaod Time Breakdown”，可以看出login 事務分解的各個組件的大小，以 及各個組件的下載時間。
從下圖可以看出，login 頁面有5 個組件組成，其中next.gif 下載用的時間最長，並且幾 乎所有的時間都用在了First Buffer 上，而其大小為1.256KB，並不是很大。
上圖提供的組件大小的信息比較簡單，更詳細的信息參考“Download Component Size Graph”。利用該圖可以看出該頁面各種組件的大小所占的比例關系。
同樣，要看各個組件下載時間的更詳細的信息，可以參考“Page Component Breakdown”。 利用該圖可以看出該頁面各種組件下載時間的比例關系。
選擇“Component Breakdown（Over Time）”，可以以圖形曲線的形式看出各個組件在場景運行中的每秒鍾的下載時間，比較具體。要看到具體的值，可以參考Page Component Breakdown （Over Time）
然后再選擇“Download Time BreakDown（Over Time）”，從中可以看出在場景運行中的每一秒鍾，組件用在傳輸的各部分的時間。要看到具體的值，可以參考Page Download Time Breakdown（Over Time）
為了確認問題緣由到底是服務器還是網絡，選擇“Time to First Buffer Breakdown”，可以看 出Server 時間比network 時間要高的多，從而確定問題是服務器引起的。然后我們就可以參 考Web Server 的相關圖表，來確定問題是由服務器的哪個部分引起。遵從這樣的步驟，可 以一步步的接近問題源；如果問題由網絡引起，可以參考NetWork 相關的圖表，確定什么 樣的網絡問題是性能的瓶頸。同時可以參考“Time To First Buffer BreakDown(Over Time)”
確定WebServer 的問題
網站的性能問題可能是由多種因素引起的，其中大約有一半的性能問題最終歸結到Web Server、Web 應用程序和數據庫服務器上。采用編程語言（ASP、JSP、ASP.NET 等）的網 站非常依賴於數據庫操作，這些都可能是引起性能問題的因素。
最常見的數據庫問題是效率比較低的索引設計，數據碎片太多，過時的統計表以及不完 善的應用程序設計。
在 20%的壓力測試中，發現Web Server 和Web 應用程序是性能的瓶頸。這些瓶頸主要 是由於服務器配置不當和資源不足。比如，編程比較差的代碼以及形成的DLL 能夠使用所 有的計算機處理器資源，導致了CPU 的瓶頸。同樣，對內存的操作不當和管理不善也很容 易造成內存的瓶頸，所以我們建議在排除其他可能的因素外，首先檢查CPU 和物理內存。
比較每次運行的結果
一般情況下，我們進行性能測試的步驟是這樣：
1 首先進行一次性能測試，記錄下結果，然后分析結果，提出改進的建議
2 開發人員根據建議對代碼或者服務器的配置進行修改
3 測試人員在相同的條件下進行第二輪測試
4 測試人員對兩輪測試結果比較，確定開發人員修改的結果是否有效 那么在 Analysis 中怎樣進行對兩輪結果進行比較呢？ 可以采用菜單操作：
然后出現對話框，需要選擇需要比較的結果文件(lrr),選擇多個
對圖表進行組合合並
Analysis 默認的圖表都是以時間作為橫坐標，然而在分析結果的過程中，我們可能需要以“運 行的用戶數”作為橫坐標，來比較結果。
假如我們要畫出 Windows Resources ——VUsers 的圖表，可以這樣操作。
首先打開 Windows Resources 圖表，然后在圖表上點鼠標右鍵，選擇Merge Graphs
出現 Merge Graphs 對話框
選擇第一項“Overlay”，出現以下的圖表，這樣是把兩個圖表進行了合並，兩條曲線的縱軸共用一個原點，橫軸還是時間軸。
選擇第二項“Title”，出現以下的圖表，這樣是把兩個圖表進行了合並，兩條曲線的縱軸不 再共用一個原點，VUsers 的原點在Windows Resouces 的上面，橫軸還是時間軸。
選擇第三項“Correlate”，LoadRunner 提示信息
我們應該這樣，打開Running VUsers 圖表，在圖表上執行前面提到的操作，不過選擇第三 項“Correlate”，即可，顯示圖表如下圖
服務器硬件瓶頸-〉網絡瓶頸（對局域網，可以不考慮）-〉服務器操作系統瓶頸（參數配置）-〉中間件瓶頸（參數配置，數據庫，web服務器等）-〉應用瓶頸（SQL語句、數據庫設計、業務邏輯、算法等） 注：以上過程並不是每個分析中都需要的，要根據測試目的和要求來確定分析的深度。對一些要求低的，我們分析到應用系統在將來大的負載壓力（並發用戶數、數據量）下，系統的硬件瓶頸在哪兒就夠了。
分析集合點
在錄制腳本中通常我們會使用到集合點,那么既然我們用到了集合點,我們就需要知道Vuser是在什么時候集合在這個點上,又是怎樣的一個被釋放的過程.這個時候就需要觀察Vuser-Rendezvous圖.
圖1
可以看到大概在3分50的地方30個用戶才全部集中到start集合點,持續了3分多,在7分30的位置開始釋放用戶,9分30還有18個用戶,11分10還有5個用戶,整個過程持續了12分.
圖2
上面圖2是集合點與平均事務響應時間的比較圖.
注:在打開analysis之后系統LR默認這兩個曲線是不在同一張圖中的.這就需要自行設置了.具體步驟如下:
點擊圖上.右鍵選擇merge graphs.然后在select graph to merge with 中選擇即將用來進行比較的graph.如圖3:
圖3
圖2中較深顏色的是平均響應時間,淺色的為集合點,當Vuser在集合點持續了1分后平均響應時間呈現最大值,可見用戶的並發對系統的性能是一個很大的考驗. 接下來看一下與事務有關的參數分析.下看一張圖.
圖4
這張圖包括Average Transaction Response Time和Running Vuser兩個數據圖.從圖中可以看到Vuser_init_Transaction(系統登錄)對系統無任何的影響,Vuser達到15個的時候平均事務響應時間才有明顯的升高,也就是說系統達到最優性能的時候允許14個用戶同時處理事務,Vuser達到30后1分,系統響應時間最大,那么這個最大響應時間是要推遲1分鍾才出現的,在系統穩定之后事務響應時間開始下降說明這個時候有些用戶已經執行完了操作.同時也可以看出要想將事務響應時間控制在10S內.Vuser數量最多不能超過2個.看來是很難滿足用戶的需求了.
做一件事有時候上級會問你這件事辦得怎么樣了.你會說做完一半了.那么這個一半的事情你花了多少時間呢?所以我們要想知道在給定時間的范圍內完成事務的百分比就要靠下面這個圖(Transaction Response Time(Percentile)
圖中畫圈的地方表示10%的事務的響應時間是在80S左右.80S對於用戶來說不是一個很小的數字,而且只有10%的事務,汗.你覺得這個系統性能會好么!
實際工作中遇到的事情不是每一件事都能夠在很短的時間內完成的,對於那些需要時間的事情我們就要分配適當的時間處理,時間分配的不均勻就會出現有些事情消耗的時間長一些,有些事情消耗的短一些,但我們自己清楚.LR同樣也為我們提供了這樣的功能,使我們可以了解大部分的事務響應時間是多少?以確定這個系統我們還要付出多少的代價來提高它.
Transaction Response Time(Distribution)-事務響應時間(分布)
顯示在方案中執行事務所用時間的分布.如果定義了可以接受的最小和最大事務性能時間,可以通過此圖確定服務器性能是否在可接受范圍內.
很明顯大多數事務的響應時間在60-140S.在我測試過的項目中多數客戶所能接受的最大響應時間也要在20S左右.140S的時間!很少有人會去花這么多的時間去等待頁面的出現吧!
通過觀察以上的數據表.我們不難看到此系統在這種環境下並不理想.世間事有果就有因,那么是什么原因導致得系統性能這樣差呢?讓我們一步一步的分析.
系統性能不好的原因多方面,我們先從應用程序看.有的時候我不得不承認LR的功能真的很強大,這也是我喜歡它的原因.先看一張頁面細分圖.
很明顯大多數事務的響應時間在60-140S.在我測試過的項目中多數客戶所能接受的最大響應時間也要在20S左右.140S的時間!很少有人會去花這么多的時間去等待頁面的出現吧!
通過觀察以上的數據表.我們不難看到此系統在這種環境下並不理想.世間事有果就有因,那么是什么原因導致得系統性能這樣差呢?讓我們一步一步的分析.
系統性能不好的原因多方面,我們先從應用程序看.有的時候我不得不承認LR的功能真的很強大,這也是我喜歡它的原因.先看一張頁面細分圖.
一個應用程序是由很多個組件組成的,整個系統性能不好那我們就把它徹底的剖析一下.圖片中顯示了整個測試過程中涉及到的所有web頁.web page breakdown中顯示的是每個頁面的下載時間.點選左下角web page breakdown展開,可以看到每個頁中包括的css樣式表,js腳本,jsp頁面等所有的屬性. 在select page to breakdown中選擇頁面. 見圖.
在Select Page To Breakdown 中選擇http://192.168.0.135:8888/usertasks后,在下方看到屬於它的兩個組件,第一行中Connection和First Buffer占據了整個的時間,那么它的消耗時間點就在這里,我們解決問題就要從這里下手.
也有可能你的程序中client的時間最長.或者其他的,這些就要根據你自己的測試結果來分析了
CPU,內存.硬盤的瓶頸分析方法
System（系統）
%Total Processor Time
系統中所有處理器都處於繁忙狀態的時間百分比，對於多處理器系統來說，該值可以反映所有處理器的平均繁忙狀態，該值為100%，如果有一半的處理器為繁忙狀態，該值為50%服務器。器消耗的處理器時間數量.如果服務器專用於sql server 可接受的最大上限是80% -85 %.也就是常見的CPU 使用率.
File Data Operations/sec
計算機對文件系統進行讀取和寫入操作的頻率，但是不包括文件控制操作
Process Queue Length
線程在等待分配CPU資源所排隊列的長度，此長度不包括正在占有CPU資源的線程。如果該隊列的長度大於處理器個數+1，就表示處理器有可能處於阻塞狀態（參考值：<=處理器個數+1）
Processor（處理器）
%Processor Time
CPU利用率，可以查看處理器是否處於飽和狀態，此值的最佳范圍為75%-95%，如果在性能監控過程中此值過低，表示CPU尚未充分利用，還 需要更大的負載壓力，如果該值持續超過95%，就表示當前系統的瓶頸為CPU，此時可以考慮增加一個處理器或換一個性能更好的處理器。
%Priviliaged Time
指處理線程執行代碼所花時間的百分比。如果該參數值和“physical disk”值一直很高，表明I/O有問題，可考慮采用更快的硬盤系統。
%User Time
指處理器處於用戶模式的時間百分比，也就是非內核操作用戶進程所耗費的CPU時間。其值可以表示為CPU的數據庫操作 （如查找、排序等活動）耗費的時間，如果該值很高，可以考慮增加索引、使用簡單的表連接、水平分割大表格等方法來降低該值。
計算機處理器有用戶模式和特權模式兩種工作方式，用戶模式是為應用程序、環境分系統和整數分系統設計的有限處理模式；特權模式是為操作系統組 件設計的，允許其直接訪問硬件和所有內存。操作系統將應用程序線程轉換成特權模式以訪問操作系統服務器。
%DPC Time
指在實例間隔期間，處理器用在延緩程序調用（DPC）接收和提供服務的時間百分比，就是消耗在網絡處理上的時間，該值越低越好。由於DPC是以特權模式執行的，DPC時間的百分比為特權時間百分比的一部分。
ProcessorQueue Length
簡述：判斷CPU瓶頸,如果processor queue length顯示的隊列長度保持不變(>=2)並且處理器的利用率%Processor time超過90%,那么很可能存在處理器瓶頸.如果發現processor queue length顯示的隊列長度超過2,而處理器的利用率卻一直很低,或許更應該去解決處理器阻塞問題,這里處理器一般不是瓶頸.
參考值：
interrupt/sec
簡述：指處理器接收並維護硬件中斷的平均值，單位是事件數/秒，這 個值說明了能夠產生中斷的設備（如系統時鍾、鼠標、磁盤驅動器、網卡和其他外部設備）的活動情況，這些可以產生中斷 的設備通常在完成了一項任務時中斷處理器。
%interrupte time
簡述：處理器在實例間隔期間接受和服務硬件中斷的時間。此 值間接表示了產生中斷的設備的活動，如系統時鍾、鼠標、磁盤驅動器、網卡和其他外部設備，這些設備通常會中斷處理器。
Queue Length
簡述:指跟蹤服務器工作隊列當前長度的計數器，該數值會顯示出處理器瓶頸。隊列長度持續大於2則表示可能出現處 理器擁塞。
Memory（內存）
Page Faults/sec
當處理器在內存中讀取某一頁出現錯誤時，就會產生缺頁中斷，也就是 page Fault。如果這個頁位於內存的其他位置，這種錯誤稱為軟錯誤，用Transition Fault/sec 來衡量；如果這個頁位於硬盤上，必須從硬盤重新讀取，這個錯誤成為硬錯誤。硬錯誤會使系統的運行效率很快將下來。Page Faults/sec這個計數器就表示每秒鍾處理的錯誤頁數，包括硬錯誤和軟錯誤。
Page Input/sec
簡述：為了解決硬錯誤頁，從磁盤上讀取的頁數。（參考值：>=Page Reads/sec）
Page Reads/sec
簡述：為了解決硬錯誤頁，從磁盤上讀取的次數。解析對內存的引用，必須讀取頁文件的次數。閾值為>5.越低越好。大數值表示磁盤讀而不是緩存讀。
Page/sec
表示為了解決硬錯誤而從硬盤上讀取或寫入硬盤的頁數（參考值：00~20）
一般如果Page/sec持續高於幾百，那么您應該進一步研究頁交換活動。有可能需要增加內存，以減少換頁的需求（你可以把這個數字乘以4k就得到由此引起的硬盤數據流量）。Pages/sec的值很大不一定表明內存有問題，而可能是運行使用內存映射文件的程序所致。
參考值：
Page Fault
簡述：處理器每秒處理的錯誤頁（包括軟/硬錯誤）。當處理器向內存指定的位置請求一頁（可能是數據或代碼）出現錯誤時，這就構成一個Page Fault。如果該頁在內存的其他位置，該錯誤被稱為軟錯誤（用Transition Fault/sec記數器衡量）；如果該頁必須從硬盤上重新讀取時，被稱為硬錯誤。許多處理器可以在有大量軟錯誤的情況下繼續操作。但是，硬錯誤可以導致明顯的拖延。
參考值：
Pages per second
每秒鍾檢索的頁數。該數字應少於每秒一頁Working set:理線程最近使用的內存頁，反映了每一個進程使用的內存頁的數量。如果服務器有足夠的空閑內存，頁就會被留在工作集中，當自由內存少於一個特定的閾值時，頁就會被清除出工作集。
Available Mbytes
剩余的可用物理內存，單位是兆字節（參考值：>=10%）用物理內存數. 如果Available Mbytes的值很小(4 MB 或更小)，則說明計算機上總的內存可能不足，或某程序沒有釋放內存。
參考值：4 MB或更小，至少要有10%的物理內存值
Cathe Bytes
文件系統的緩存（默認為50%的可用物理內存）如IIS5.0運行內存不夠時，它會自動整理緩存。需要關注該計數器的趨勢變化。該指標只顯示最后一次觀察的值，它不是一個平均值。
pool paged bytes
簡述: 指在分頁池中的字節 數，分頁池是系統內存中可供對象使用的一個區域。
pool nonpaged bytes
簡述:指非分頁池中的 字節數，非分頁池中的字節數如果持續增加表示可能存在內存泄漏問題，需要進一步結合其他指標，來判斷是否存在嚴重的內存泄漏還是其他原因引起的非分頁池增加。
Process（進程）
private Bytes
進程無法與其他進程共享的字節數量。該計數器的值較大時，有可能是內存泄露的信號
Work set
最近處理線程使用的內存頁
Page Faults/sec
簡述：將進程產生的頁故障與系統產生的相比較，以判斷這個進程對系統頁故障產生的影響。指每秒鍾出錯頁面的平均數量。
參考值：
Private Bytes
簡述：此進程所分配的無法與其它進程共享的當前字節數量。如果系統性能隨着時間而降低，則此計數器可以是內存泄漏的最佳指示器。
參考值：
Work set
簡述：處理線程最近使用的內存頁，反映了每一個進程使用的內存頁的數量。如果服務器有足夠的空閑內存，頁就會被留在工作集中，當自由內存少於一個特定的閾值時，頁就會被清除出工作集。
參考值：
PhysicalDisk（磁盤）
%Disk Time
表示磁盤驅動器為讀取或寫入請求提供服務所用的時間百分比，如果只有%Disk Time比較大，硬盤有可能是瓶頸。指所選磁盤驅動器忙於為讀或寫入請求提供服務所用的時間的百分比。如果三個計數器都比較大，那么硬盤不是瓶頸。如果只有%Disk Time比較大，另外兩個都比較適中，硬盤可能會是瓶頸。在記錄該計數器之前，請在Windows 2000 的命令行窗口中運行diskperf -yD。若數值持續超過80%，則可能是內存泄漏。應當總小於90%
Average Disk Queue Length
表示磁盤讀取和寫入請求提供服務所用的時間百分比，可以通過增加磁盤構造磁盤陣列來提高性能（<=磁盤數的2倍）讀取和寫入請求(為所選磁盤在實例間隔中列隊的)的平均數。該值應不超過磁盤數的1.5~2 倍。要提高性能，可增加磁盤。注意：一個Raid Disk實際有多個磁盤。不應當超過物理磁盤數量的2倍,正常值<0.5
Average Disk Read Queue Length
表示磁盤讀取請求的平均數
Average Disk write Queue Length
表示磁盤寫入請求的平均數
Average Disk sec/Read
磁盤中讀取數據的平均時間，單位是秒
Average Disk sec/Transer
磁盤中寫入數據的平均時間，單位是秒，一般來說，定義該值小於15ms最為優異，介於15-30ms之間為良好，30-60ms之間為可以接受，超過60ms則需要考慮更換硬盤或硬盤的RAID方式了
%Disk reads/sec(physicaldisk_total)
每秒讀硬盤字節數. 該指標應總小於磁盤I/O子系統的容量
%Disk write/sec(physicaldisk_total)
每秒寫硬盤字節數. 該指標應當總小於硬盤I/O子系統的容量
Disk Bytes/sec
指在進行寫入或讀取操作時從磁盤上傳送或傳出的字節速率。
此值取決於硬盤的速度
Disk Transfers/sec
指在此盤上讀取/寫入操作速率。
正常值<(Disk Bytes/sec)/3，此值過大表示系統要求的IO速度已接近硬盤的最大速度，要更換更快的硬盤 D
CurrentDiskQueueLength
簡述：讀取和寫入請求(為所選磁盤在實例間隔中列隊的)的平均數。(磁盤數1.5-2倍)
Network Interface（網絡）
Byte Total/sec
表示網絡中接受和發送字節的速度，可以用該計數器來判斷網絡是否存在瓶頸（參考值：該計數器和網絡帶寬相除，<50%）。以b為單位轉化為M需要除以1024再除1024.
LoadRunner分析資源占用率
1. 平均事務響應時間 Average Transation Response Time 優秀：<2s 良好：2-5s 及格：6-10s 不及格：>10s
2. 每秒點擊率 Hits per Second
當增大系統的壓力(或增加並發用戶數)時，吞吐率和TPS的變化曲線呈大體一致，則系統基本穩定若壓力增大時，吞吐率的曲線增加到一定程度后出現變化緩慢，甚至平坦，很可能是網絡出現帶寬瓶頸.同理若點擊率/TPS曲線出現變化緩慢或者平坦,說明服務器開始出現.
3. 請求響應時間 Time to Last Byte
4. 每秒系統處理事務數 Transaction per second
5. 吞吐量 Throughout
6. CPU利用率
Processor / %Processor Time 好：70% 壞：85% 很差：90%+
7. 數據庫操作消耗的CPU時間
Processor / %User Time 如果該值較大，可以考慮是否能通過友好算法等方法降低這個值。如果該服務器是數據庫服務器， Processor\%User Time 值大的原因很可能是數據庫的排序或是函數操作消耗了過多的CPU時間，此時可以考慮對數據庫系統進行優化。
8. 核心態CPU平均利用率
Processor /%Privileged Time 如果該參數值和"Physical Disk"參數值一直很高，表明I/O有問題。可考慮更換更快的硬盤系統
9. 處理列隊中的線程數
Processor / Processor Queue Length 如果該值保持不變(>=2)個並
且%Processor Time 超過90%，那么可能存在處理器瓶頸。如果發現超過2，而處理器的利用率卻一直很低，那么或許更應該去解決處理器阻塞問題，這里處理器一般不是瓶頸。
10. 文件系統緩存 Memory / Cache Bytes 50%的可用物理內存
11. 剩余的可用內存 Memory / Avaiable Mbytes 至少要有10% 的物理內存值
12. 每秒下載頁數 Memory / pages/sec 好：無頁交換 壞：CPU每秒10個頁交換 很差：更多的頁交換
13. 頁面讀取操作速率 Memory / page read/sec 如果頁面讀取操作速率很低，同時 % Disk Time 和 Avg.Disk Queue Length的值很高，則可能有磁盤瓶徑。但是，如果隊列長度增加的同時頁面讀取速率並未降低，則內存不足。
14. 物理磁盤利用率 Physical Disk / %Disk Time 好：<30% 壞：<40% 很差：<50%+
15. 物理磁盤平均磁盤I/O隊列長度
Physical Disk / Avg.Disk Queue Length 該值應不超過磁盤數的1.5~2 倍。要提高性能，可增加磁盤
16. 網絡吞吐量 Network Interface / Bytes Total/sec 判斷網絡連接速度是否是瓶頸，可以用該計數器的值和目前網絡的帶寬，結果應該小於50%
17. 數據高速緩存區命中率 命中率應大於0.90最好
18. 共享區庫緩存區命中率 命中率應大於0.99
19. 監控 SGA 中字典緩沖區的命中率 命中率應大於0.85
20. 檢測回滾段的爭用 小於1%
21. 監控 SGA 中重做日志緩存區的命中率 應該小於1%
22. 監控內存和硬盤的排序比率 最好使它小於 10%
性能問題分析
- 1、網絡瓶頸，如帶寬，流量等形成的網絡環境
- 2、應用服務瓶頸，如中間件的基本配置，CACHE等
- 3、系統瓶頸，這個比較常用：應用服務器，數據庫服務器以及客戶機的CPU，內存，硬盤等配置
- 4、數據庫瓶頸，以ORACLE為例，SYS中默認的一些參數設置
- 5、應用程序本身瓶頸，
針對網絡瓶頸，現在冒似很少，不過也不是沒有，首先想一下如果有網絡的阻塞，斷網，帶寬被其他資源占用，限速等情況，應用程序或系統會是什么情況，針對WEB，無非是超時，HTTP400，500之類的錯，針對一些客戶端程序，可能也是超時，掉線，服務器下發的，需要服務器返回的信息獲取不到還有一種更明顯的情況，應該就是事務提交慢，如果封裝事務的代碼再不完善，一般造成的錯誤，無非就是數據提交不完整，或者因為網終原因+代碼缺陷造成重復性提交。如此綜合下來，肯定是考慮網絡有瓶頸，然后考慮網絡有問題時，怎樣去優化，是需要優化交互的一些代碼，還是接口之類的。
應用服務的瓶頸的定位，比較復雜，學習中，不過網上有很多資料可以參考的。一般像tomcat，weblogic之類的，有默認的設置，也有經過架構和維護人員進行試驗調試的一些值，這些值一般可以滿足程序發布的需要，不必進行太多的設置，可能我們認識的最基本的就是JAVA_OPTS的設置，maxThreads，time_out之類的參數我們做借助LR，Jemeter或webload之類的工具，執行性能測試，尤其是對應用服務造成了壓力，如果應用服務有瓶頸，一般我們設置的log4j.properties，日志都會記錄下來。然后根據日志，去進一步確定應用服務的問題
系統瓶頸，這個定位雖說比較復雜，但是有很多前輩的經驗值參考，不作說明，相信用LR的同行，也可以從性能記數器中得出一些指標值，加上nagios，cacti，可以很明顯的看出系統哪些資源夠用，哪些資源明顯不夠用。不過，一般系統瓶頸的造成，是因為應用程序本身造成的。關於這點兒的分析和定位，就需要歸入應用程序本身瓶頸分析和定位了。
現在基本所有的東東，都離不開數據庫這個后台，數據庫的瓶頸實在是不知道是什么概念，數據庫管理員的工作，數據庫管理員日常做的工作，可能就是有瓶頸定位的工作，比如：查詢一下V$sys_event，V$sysstat，v$syssql之類的表，比對一下日常正常情況下的監控數據，看一下有沒有異常等。其他方面，我也不是太了解。
應用程序瓶頸，這個是測試過程中最需要去關注的，需要測試人員和開發人員配合執行，然后定位，我這兒做的大都是執行性的，比如會有腳本去運行，開發人員會結合jprofiler之類的工具，去看一下堆遍歷，線程剖析的情況確定哪兒有問題。大致是這樣，沒有實際操作過
逐步細化分析，先可以監控一些常見衡量CPU，內存，磁盤的性能指標，進行綜合分析，然后根據所測系統具體情況，進行初步問題定位，然后確定更詳細的監控指標來分析。
懷疑內存不足時
方法1：
【監控指標】：Memory Available MBytes ，Memory的Pages/sec， page read/sec， Page Faults/sec
【參考值】：
如果 Page Reads/Sec 比率持續保持為 5，表示可能內存不足。
Page/sec 推薦00-20（如果服務器沒有足夠的內存處理其工作負荷，此數值將一直很高。如果大於80，表示有問題）。
方法2：根據Physical Disk 值分析性能瓶頸
【監控指標】：Memory Available MBytes ，Pages read/sec，%Disk Time 和 Avg.Disk Queue Length
【參考值】：%Disk Time建議閾值90%
當內存不足時，有點進程會轉移到硬盤上去運行，造成性能急劇下降，而且一個缺少內存的系統常常表現出很高的CPU利用率，因為它需要不斷的掃描內存，將內存中的頁面移到硬盤上。
懷疑內存泄漏時
【監控指標】：Memory Available MBytes ，Process\Private Bytes和Process\Working Set，PhysicalDisk/%Disk Time
【說明】：
Windows資源監控中，如果Process\Private Bytes計數器和Process\Working Set計數器的值在長時間內持續升高，同時Memory\Available bytes計數器的值持續降低，則很可能存在內存泄漏。內存泄漏應該通過一個長時間的，用來研究分析當所有內存都耗盡時，應用程序反應情況的測試來檢驗。
CPU分析
【監控指標】：
System %Processor Time CPU，Processor %Processor Time CPU
Processor%user time 和Processor%Privileged Time
system\Processor Queue Length
Context Switches/sec 和%Privileged Time
【參考值】：
System\%Total processor time不持續超過90%，如果服務器專用於SQL Server，可接受的最大上限是80-85% ，合理使用的范圍在60%至70%。
Processor %Processor Time小於75%
system\Processor Queue Length值，小於CPU數量的總數+1
CPU瓶頸問題
1、System\%Total processor time如果該值持續超過90%，且processor queue length顯示的隊列長度保持不變(>=2)，則說明整個系統面臨着處理器方面的瓶頸.
注：在某些多CPU系統中，該數據雖然本身並不大，但CPU之間的負載狀況極不均衡，此時也應該視作系統產生了處理器方面的瓶頸.
2、排除內存因素，如果Processor %Processor Time計數器的值比較大，而同時網卡和硬盤的值比較低，那么可以確定CPU 瓶頸。（內存不足時，有點進程會轉移到硬盤上去運行，造成性能急劇下降，而且一個缺少內存的系統常常表現出很高的CPU利用率，因為它需要不斷的掃描內存，將內存中的頁面移到硬盤上。）
造成高CPU使用率的原因：
頻繁執行程序，復雜運算操作，消耗CPU嚴重
數據庫查詢語句復雜，大量的 where 子句，order by， group by 排序等，CPU容易出現瓶頸
內存不足，IO磁盤問題使得CPU的開銷增加
磁盤I/O分析
【監控指標】：PhysicalDisk/%Disk time，PhysicalDisk/%Idle Time，Physical Disk\ Avg.Disk Queue Length， Disk sec/Transfer
【參考值】：%Disk Time建議閾值90%
Windows資源監控中，如果% Disk Time和Avg.Disk Queue Length的值很高，而Page Reads/sec頁面讀取操作速率很低，則可能存在磁盤瓶徑。
Processor%Privileged Time該參數值一直很高，且如果在 Physical Disk 計數器中，只有%Disk time 比較大，其他值都比較適中，硬盤可能會是瓶頸。若幾個值都比較大， 那么硬盤不是瓶頸。若數值持續超過80%，則可能是內存泄露。如果 Physical Disk 計數器的值很高時該計數器的值（Processor%Privileged Time）也一直很高， 則考慮使用速度更快或效率更高的磁盤子系統。
Disk sec/Transfer 一般來說，該數值小於15ms為最好，介於15-30ms之間為良好，30-60ms之間為可以接受，超過60ms則需要考慮更換硬盤或是硬盤的RAID方式了.
Average Transaciton Response Time（事務平均響應時間）隨着測試時間的變化，系統處理事務的速度開始逐漸變慢，這說明應用系統隨着投產時間的變化，整體性能將會有下降的趨勢
Transactions per Second（每秒通過事務數/TPS）當壓力加大時，點擊率/TPS曲線如果變化緩慢或者有平坦的趨勢，很有可能是服務器開始出現瓶頸
Hits per Second（每秒點擊次數）通過對查看“每秒點擊次數”，可以判斷系統是否穩定。系統點擊率下降通常表明服務器的響應速度在變慢，需進一步分析，發現系統瓶頸所在。
Throughput（吞吐率）可以依據服務器的吞吐量來評估虛擬用戶產生的負載量，以及看出服務器在流量方面的處理能力以及是否存在瓶頸。
Connections（連接數）當連接數到達穩定狀態而事務響應時間迅速增大時，添加連接可以使性能得到極大提高（事務響應時間將降低）
Time to First Buffer Breakdown（Over Time）（第一次緩沖時間細分（隨時間變化））可以使用該圖確定場景或會話步驟運行期間服務器或網絡出現問題的時間。
硬件問題
請觀察 Processor\ Interrupts/sec 計數器的值，該計數器測量來自輸入/輸出 (I/O) 設備的服務請求的速度。如果此計數器的值明顯增加，而系統活動沒有相應增加，則表明存在硬件問題。
判斷應用程序的問題
如果系統由於應用程序代碼效率低下或者系統結構設計有缺陷而導致大量的上下文切換(context switches/sec顯示的上下文切換次數太高)那么就會占用大量的系統資源,如果系統的吞吐量降低並且CPU的使用率很高,並且此現象發生時切換水平在15000以上,那么意味着上下文切換次數過高。
從圖的整體看.context switches/sec變化不大,throughout曲線的斜率較高,並且此時的context switches/sec已經超過了15000.程序還是需要進一步優化。
I/O資源成為系統性能的瓶頸的征兆
IO Data Bytes/sec(處理從I/O操作讀取/寫入字節的速度。這個計數器為所有由本處理產生的包括文件、網絡和設備I/O的活動計數。)
IO Data Operations/sec
IO Other Bytes/sec
IO Other Operations/sec
IO Read Bytes/sec(每秒IO讀取字節數)
IO Read Operations/sec
IO Write Bytes/sec(每秒IO寫出字節數)
IO Write Operations/sec
過高的磁盤利用率(high disk utilization)
太長的磁盤等待隊列(Physical Disk\ Current Disk Queue Length,正在等待磁盤訪問的系統請求數量)
等待磁盤I/O的時間所占的百分率太高(Average Disk Queue Length)
太高的物理I/O速率:large physical I/O rate(not sufficient in itself)
過低的緩存命中率(low buffer cache hit ratio(not sufficient in itself))
太長的運行進程隊列，但CPU卻空閑(Process Queue Length)
在運行中，如果出現了大於3個用戶的業務操作失敗，或出現了服務器shutdown的情況，則說明在當前環境下，系統承受不了當前並發用戶的負載壓力，那么最大並發用戶數就是前一個沒有出現這種現象的並發用戶數
監視磁盤的使用情況
監視磁盤活動涉及兩個主要方面：
監視磁盤 I/O 及檢測過度換頁
隔離 SQL Server 產生的磁盤活動
監視磁盤 I/O 及檢測過度換頁
可以對下面兩個計數器進行監視以確定磁盤活動：
PhysicalDisk: % Disk Time
PhysicalDisk: Avg. Disk Queue Length
在系統監視器中，PhysicalDisk: % Disk Time 計數器監視磁盤忙於讀/寫活動所用時間的百分比。如果 PhysicalDisk: % Disk Time 計數器的值較高（大於 90%），請檢查PhysicalDisk: Current Disk Queue Length 計數器了解等待進行磁盤訪問的系統請求數量。等待 I/O 請求的數量應該保持在不超過組成物理磁盤的軸數的 1.5 到 2 倍。大多數磁盤只有一個軸，但獨立磁盤冗余陣列 (RAID) 設備通常有多個軸。硬件 RAID 設備在系統監視器中顯示為一個物理磁盤。通過軟件創建的多個RAID 設備在系統監視器中顯示為多個實例。
可以使用 Current Disk Queue Length 和 % Disk Time 計數器的值檢測磁盤子系統中的瓶頸。如果 Current Disk Queue Length 和 % Disk Time 計數器的值一直很高，則考慮下列事項：
使用速度更快的磁盤驅動器。
將某些文件移至其他磁盤或服務器。
如果正在使用一個 RAID 陣列，則在該陣列中添加磁盤。
如果使用 RAID 設備，% Disk Time 計數器會指示大於 100% 的值。如果出現這種情況，則使用 PhysicalDisk: Avg.Disk Queue Length 計數器來確定等待進行磁盤訪問的平均系統請求數量。
I/O 依賴的應用程序或系統可能會使磁盤持續處於活動狀態。
監視 Memory: Page Faults/sec 計數器可以確保磁盤活動不是由分頁導致的。在 Windows 中，換頁的原因包括：
配置進程占用了過多內存。
文件系統活動。
如果在同一硬盤上有多個邏輯分區，請使用 Logical Disk 計數器而非 Physical Disk 計數器。查看邏輯磁盤計數器有助於確定哪些文件被頻繁訪問。當發現磁盤有大量讀/寫活動時，請查看讀寫專用計數器以確定導致每個邏輯卷負荷增加的磁盤活動類型，例如，Logical Disk: Disk Write Bytes/sec。
判斷磁盤瓶頸
%Disk Time和Avg.Disk Queue Length的值 (應不大於組成物理磁盤的主軸數的 1.5 到2倍) 很高，而Page Reads/sec頁面讀取操作速率很低，則可能存在磁盤瓶徑。
Physical Disk\ Disk Reads/sec and Disk Writes/sec 大於20 ms,則有可能磁盤瓶頸
Physical Disk\ Current Disk Queue Length
Physical Disk\ % Disk Time
LogicalDisk\ % Free Space
測試磁盤性能時，將性能數據記錄到另一個磁盤或計算機，以便這些數據不會干擾您正在測試的磁盤。
可能需要觀察的附加計數器包括 Physical Disk\ Avg.Disk sec/Transfer 、Avg.DiskBytes/Transfer，和Disk Bytes/sec。
Avg.Disk sec/Transfer 計數器反映磁盤完成請求所用的時間。較高的值表明磁盤控制器由於失敗而不斷重試該磁盤。這些故障會增加平均磁盤傳送時間。對於大多數磁盤，較高的磁盤平均傳送時間是大於 0.3 秒。盤中寫入數據的平均時間，單位是秒，一般來說，定義該值小於15ms最為優異，介於15-30ms之間為良好，30-60ms之間為可以接受，超過60ms則需要考慮更換硬盤或硬盤的RAID方式了。
也可以查看 Avg.Disk Bytes/Transfer 的值。值大於 20 KB 表示該磁盤驅動器通常運行良好;如果應用程序正在訪問磁盤，則會產生較低的值。例如，隨機訪問磁盤的應用程序會增加平均 Disk sec/Transfer 時間，因為隨機傳送需要增加搜索時間。
Disk Transfers/sec 指在此盤上讀取/寫入操作速率。正常值<(Disk Bytes/sec)/3，此值過大表示系統要求的IO速度已接近硬盤的最大速度，要更換更快的硬盤。
備注：如果使用 RAID 設備，% Disk Time 計數器會指示大於 100% 的值。
Disk Bytes/sec 提供磁盤系統的吞吐率
決定工作負載的平衡要平衡網絡服務器上的負載，需要了解服務器磁盤驅動器的繁忙程度。使用 Physical Disk\ %Disk Time 計數器，該計數器顯示驅動器活動時間的百分比。如果 % Disk Time 較高(超過90%)，請檢查 Physical Disk\ Current Disk Queue Length 計數器以查看正在等待磁盤訪問的系統請求數量。等待 I/O 請求的數量應當保持在不大於組成物理磁盤的主軸數的 1.5 到2倍。
盡管廉價磁盤冗余陣列 (RAID) 設備通常有多個主軸，大多數磁盤有一個主軸。硬件 RAID設備在“系統監視器”中顯示為一個物理磁盤;通過軟件創建的 RAID 設備顯示為多個驅動器(實例)。可以監視每個物理驅動器(而不是 RAID)的 Physical Disk 計數器，也可以使用 _Total 實例來監視所有計算機驅動器的數據。
使用 Current Disk Queue Length 和 % Disk Time 計數器來檢測磁盤子系統的瓶頸。如果Current Disk Queue Length 和 % Disk Time 的值始終較高，可以考慮升級磁盤驅動器或將某些文件移動到其他磁盤或服務器。
判斷磁盤瓶頸的方法通過以下公式來計算：
每磁盤的I/O數=[讀次數+（4*寫次數）]/磁盤個數
如果計算出的每磁盤的I/O數大於磁盤的處理能力，那么磁盤存在瓶頸。
碰到過的性能問題
- 1. 在高並發的情況下，產生的處理失敗（比如：數據庫連接池過低，服務器連接數超過上限，數據庫鎖控制考慮不足等）
- 2. 內存泄露（比如：在長時間運行下，內存沒有正常釋放，發生宕機等）
- 3. CPU使用偏離（比如：高並發導致CPU使用率過高）
- 4. 日志打印過多，服務器無硬盤空間
如何定位這些性能問題
1. 查看系統日志，日志是定位問題的不二法寶，如果日志記錄的全面，很容易通過日志發現問題。
比如，系統宕機時，系統日志打印了某方法執行時拋出out of memory的錯誤，我們就可以順藤摸瓜，很快定位到導致內存溢出的問題在哪里。
2. 利用性能監控工具，比如：JAVA開發B/S結構的項目，可以通過JDK自帶的Jconsole，或者JProfiler，來監控服務器性能，Jconsole可以遠程監控服務器的CPU，內存，線程等狀態，並繪制變化曲線圖。
利用Spotlight可以監控數據庫使用情況。
我們需要關注的性能點有：CPU負載，內存使用率，網絡I/O等
3. 工具和日志只是手段，除此之外，還需要設計合理的性能測試場景
具體場景有：性能測試，負載測試，壓力測試，穩定性測試，浪涌測試等
好的測試場景，能更加快速的發現瓶頸，定位瓶頸
4. 了解系統參數配置，可以進行后期的性能調優
5. 請求無響應，瀏覽器始終處於等待狀態。
定位方法：kill -3或者jstack先分析線程堆棧，找到當前block的線程。
常見於：外部接口調用無返回或者網絡IO阻塞無響應；死鎖；死循環；……。
6. 宕機，進程掛掉。
定位方法（這一類問題普遍比較難定位）：
（1）尋找hs_err_pidxxx.log這樣的JVM日志
（2）使用JVM參數在JVM crash時寫入到dump文件中
（3）catalina.out中尋找最后的日志
（4）宕機前環境數據采集
常見於：JDK bug（數次遇到過JIT引起的這一類問題）；調用dll的問題；……
7.請求響應時間長。
定位方法：kill -3或者jstack先分析線程堆棧，看線程大都停留在什么操作上面，再細化分析。
常見於： 內存不足，可見到連續的Full GC；網絡擁塞；LoadRunner等壓力客戶端瓶頸；數據庫瓶頸，可進一步分析DB快照；……
8. TPS低；TPS逐漸降低；TPS振盪幅度過大。
定位方法（這一類問題最常見，定位的方法也最復雜）：
首先觀察在壓力增大時，CPU使用率能否上去，如果不能上去，尋找其他瓶頸：網絡/內存/磁盤/……；CPU
使用率上去了，觀察在無壓力時，是否有背景CPU使用（例如有后台定時任務線程消耗了大量CPU資源），如果沒有，那可以嘗試JProfiler等工具結合線程分析、業務分析，尋找熱點。
常見於：其他業務線程干擾；內存泄露；連接句柄用完；緩存命中率低下……
線程分析
kill -3 pid獲取到目前jvm的線程堆棧信息，特別需要關注的是wait for monitor這樣的線程，這種線程是指在等待鎖的線程，等待一兩分鍾后再次kill -3 pid，看看這些wait for monitor的線程的變化情況，對於分析線程中是否存在不合理的競爭過高的鎖的分析是非常重要的。