浅谈性能测试分析
性能測試工程師基本上都能夠掌握利用測試工具來作負載、壓力測試，但多數人對怎樣去分析工具收集到的測試結果感到無從下手，下面我就把個人工作中的體會和收集到的有關資料整理出來，希望能對大家分析測試結果有所幫助。?分析原則：
1.?具體問題具體分析（這是由于不同的應用系統，不同的測試目的，不同的性能關注點）
2.?查找瓶頸時按以下順序，由易到難。
????服務器硬件瓶頸-〉網絡瓶頸（對局域網，可以不考慮）-〉服務器操作系統瓶頸（參數配置）-〉中間件瓶頸（參數配置，數據庫，web服務器等）-〉應用瓶頸（SQL語句、數據庫設計、業務邏輯、算法等）
????注：以上過程并不是每個分析中都需要的，要根據測試目的和要求來確定分析的深度。對一些要求低的，我們分析到應用系統在將來大的負載壓力（并發用戶數、數據量）下，系統的硬件瓶頸在哪兒就夠了。
3?分段排除法?很有效
分析的信息來源：
1?根據場景運行過程中的錯誤提示信息
2?根據測試結果收集到的監控指標數據
一．錯誤提示分析
分析實例：
1 Error: Failed to connect to server “10.10.10.30:8080″: [10060] Connection
? Error: timed out Error: Server “10.10.10.30″ has shut down the connection prematurely
分析：
?A、應用服務死掉。
（小用戶時：程序上的問題。程序上處理數據庫的問題）
?B、應用服務沒有死
（應用服務參數設置問題）
????例：在許多客戶端連接Weblogic應用服務器被拒絕，而在服務器端沒有錯誤顯示，則有可能是Weblogic中的server元素的AcceptBacklog屬性值設得過低。如果連接時收到connection refused消息，說明應提高該值，每次增加25％
?C、數據庫的連接
(1、在應用服務的性能參數可能太小了?2、數據庫啟動的最大連接數（跟硬件的內存有關）)
2 Error: Page download timeout (120 seconds) has expired
分析：可能是以下原因造成
?A、應用服務參數設置太大導致服務器的瓶頸
?B、頁面中圖片太多
?C、在程序處理表的時候檢查字段太大多
二．監控指標數據分析
1．最大并發用戶數：
應用系統在當前環境（硬件環境、網絡環境、軟件環境（參數配置））下能承受的最大并發用戶數。
????在方案運行中，如果出現了大于3個用
戶的業務操作失敗，或出現了服務器shutdown的情況，則說明在當前環境下，系統承受不了當前并發用戶的負載壓力，那么最大并發用戶數就是前一個沒有出現這種現象的并發用戶數。
????如果測得的最大并發用戶數到達了性能要求，且各服務器資源情況良好，業務操作響應時間也達到了用戶要求，那么OK。否則，再根據各服務器的資源情況和業務操作響應時間進一步分析原因所在。
2．業務操作響應時間：
?????分析方案運行情況應從平均事務響應時間圖和事務性能摘要圖開始。使用“事務性能摘要”圖，可以確定在方案執行期間響應時間過長的事務。
????細分事務并分析每個頁面組件的性能。查看過長的事務響應時間是由哪些頁面組件引起的？問題是否與網絡或服務器有關？
??如果服務器耗時過長，請使用相應的服務器圖確定有問題的服務器度量并查明服務器性能下降的原因。如果網絡耗時過長，請使用“網絡監視器”圖確定導致性能瓶頸的網絡問題
3．服務器資源監控指標：
內存：
1 UNIX資源監控中指標內存頁交換速率（Paging rate），如果該值偶爾走高，表明當時有線程競爭內存。如果持續很高，則內存可能是瓶頸。也可能是內存訪問命中率低。
2?Windows資源監控中，如果Process/Private Bytes計數器和Process/Working Set計數器的值在長時間內持續升高，同時Memory/Available bytes計數器的值持續降低，則很可能存在內存泄漏。
內存資源成為系統性能的瓶頸的征兆:
很高的換頁率(high pageout rate);
進程進入不活動狀態;
交換區所有磁盤的活動次數可高;
可高的全局系統CPU利用率;?
內存不夠出錯(out of memory errors)
處理器：
1 UNIX資源監控（Windows操作系統同理）中指標CPU占用率（CPU utilization），如果該值持續超過95%，表明瓶頸是CPU。可以考慮增加一個處理器或換一個更快的處理器。如果服務器專用于SQL Server,可接受的最大上限是80-85%?
合理使用的范圍在60%至70%。
2 Windows資源監控中，如果System/Processor Queue Length大于2，而處理器利用率（Processor Time）一直很低，則存在著處理器阻塞。
CPU資源成為系統性能的瓶頸的征兆:?
很慢的響應時間(slow response time)?
CPU空閑時間為零(zero percent idle CPU)?
過高的用戶占用CPU時間(high percent user CPU)?
過高的系統占用CPU時間(high percent system CPU)?
長時間的有很長的運行進程隊列(large run queue size sustained over time)
磁盤I/O：
1 UNIX資源監控（Windows操作系統同理）中指標磁盤交換率（Disk rate），如果該參數值一直很高，表明I/O有問題。可考慮更換更快的硬盤系統。
2 Windows資源監控中，如果?Disk Time和Avg.Disk Queue Length的值很高，而Page Reads/sec頁面讀取操作速率很低，則可能存在磁盤瓶徑。
I/O資源成為系統性能的瓶頸的征兆?:
過高的磁盤利用率(high disk utilization)?
太長的磁盤等待隊列(large disk queue length)?
等待磁盤I/O的時間所占的百分率太高(large percentage of time waiting for disk I/O)?
太高的物理I/O速率:large physical I/O rate(not sufficient in itself)?
過低的緩存命中率(low buffer cache hit ratio(not sufficient in itself))?
太長的運行進程隊列，但CPU卻空閑(large run queue with idle CPU)
4．數據庫服務器：
SQL Server數據庫：
1 SQLServer資源監控中指標緩存點擊率（Cache Hit Ratio），該值越高越好。如果持續低于80%，應考慮增加內存。
2?如果Full Scans/sec（全表掃描/秒）計數器顯示的值比1或2高，則應分析你的查詢以確定是否確實需要全表掃描，以及SQL查詢是否可以被優化。?
3 Number of Deadlocks/sec(死鎖的數量/秒)：死鎖對應用程序的可伸縮性非常有害，并且會導致惡劣的用戶體驗。該計數器的值必須為0。
4 Lock Requests/sec(鎖請求/秒)，通過優化查詢來減少讀取次數，可以減少該計數器的值。
Oracle數據庫：
1?如果自由內存接近于0而且庫快存或數據字典快存的命中率小于0.90，那么需要增加SHARED_POOL_SIZE的大小。
快存（共享SQL區）和數據字典快存的命中率：?
select(sum(pins-reloads))/sum(pins) from v$librarycache;?
select(sum(gets-getmisses))/sum(gets) from v$rowcache;?
自由內存：?select * from v$sgastat where name=’free memory’;?
2?如果數據的緩存命中率小于0.90，那么需要加大DB_BLOCK_BUFFERS參數的值（單位：塊）。
緩沖區高速緩存命中率：
select name,value from v$sysstat where name in (’db block gets’,
‘consistent gets’,'physical reads’) ;
Hit Ratio = 1-(physical reads / ( db block gets + consistent gets))
3?如果日志緩沖區申請的值較大，則應加大LOG_BUFFER參數的值。
日志緩沖區的申請情況?：
select name,value from v$sysstat where name = ‘redo log space requests’ ;
4?如果內存排序命中率小于0.95，則應加大SORT_AREA_SIZE以避免磁盤排序?。
內存排序命中率?：
select round((100*b.value)/decode((a.value+b.value), 0, 1, (a.value+b.value)), 2)from v$sysstat a, v$sysstat b where a.name=’sorts (disk)’ and b.name=’sorts (memory)’
注：上述SQL Server和Oracle數據庫分析，只是一些簡單、基本的分析，特別是Oracle數據庫的分析和優化，是一門專門的技術，進一步的分析可查相關資料。
?
?
?性能測試的結果分析是性能測試的重中之重。在實際工作中，由于測試的結果分析比較復
雜、需要具備很多相關的專業知識，因此常常會感覺拿到數據不知從何下手。這也是我學習性能
測試過程中感覺比較尷尬和棘手的事，為此我在研讀了《WEB性能測試實戰》后特作了以下筆
記，這里只是書中第4章WEB應用程序性能分析的一
部分，貼出來希望和大家共同討論：
?
一：性能分析的基礎知識：
1.幾個重要的性能指標：相應時間、吞吐量、吞吐率、TPS（每秒鐘處理的交易數）、點
擊率等。
?
2.系統的瓶頸分為兩類：網絡的和服務器的。服務器瓶頸主要涉及：應用程序、WEB服務
器、數據庫服務器、操作系統四個方面。
?
3.常規、粗略的性能分析方法：
???當增大系統的壓力（或增加并發用戶數）時，吞吐率和TPS的變化曲線呈大體一致，則系統
基本穩定；若壓力增大時，吞吐率的曲線增加到一定程度后出現變化緩慢，甚至平坦，很可能是
網絡出現帶寬瓶頸，同理若點擊率/TPS曲線出現變化緩慢或者平坦，說明服務器開始出現頸。
?
4.作者提出了如下的性能分析基本原則，此原則本人十分贊同：
??????????? ——由外而內、由表及里、層層深入
????應用此原則，分析步驟具體可以分為以下三步：
???第一步：將得到的響應時間和用戶對性能的期望值比較確定是否存在瓶頸；
???第二步：比較Tn（網絡響應時間）和Ts（服務器響應時間）可以確定瓶頸發生在網絡還是服
務器；
???第三步：進一步分析，確定更細組件的響應時間，直到找出發生性能瓶頸的根本原因。
?
二：以WEB應用程序為例來看下具體的分析方法：
1.用戶事務分析：
?
a.事務綜述圖(Transaction Summary ):以柱狀圖的形式表現了用戶事務執行的成功與
失敗。通過分析成功與失敗的數據可以直接判斷出系統是否運行正常。若失敗的事務非常多，則
說明系統發生了瓶頸或者程序在執行過程中發生了問題。
?
b.事務平均響應時間分析圖（Average Transaction Response Time）:?該圖顯示在
測試場景運行期間的每一秒內事務執行所用的平均時間，還顯示了測試場景運行時間內各個事務
的最大值、最小值和平均值。通過它可以分析系統的性能走向。若所有事務響應時間基本成一條
曲線，則說明系統性能基本穩定；否則如果平均事務響應時間逐漸變慢，說明性能有下降趨勢，
造成性能下降的原因有可能是由于內存泄漏導致。
?
c.每秒通過事務數分析圖（Transaction per Second即TPS）:顯示在場景運行的每一
秒中，每個事?務通過、失敗以及停止的數量。通過它可以確定系統在任何給定時刻的實際事務
負載。若隨著測試的進展，應用系統在單位時間內通過的事務數目在減少，則說明服務器出現瓶
頸。
?
d.每秒通過事務總數分析圖（Total Transactions per Second）:顯示場景運行的
每一秒中，通過、失敗以及停止的事務總數。若在同等壓力下，曲線接近直線，則性能基本趨于
穩定；若在單位時間內通過的事務總量越來越少，即整體性能下降。原因可能是內存泄漏或者程
序中的缺陷。
?
e.事務性能摘要圖（Transaction Performance Summary）:顯示方案中所有事務的
最小、最大平均執行時間，可以直接判斷響應時間是否符合客戶要求（重點關注事務平均、最大
執行時間）。
?
f.事務響應時間與負載分析圖（Transaction Response Time Under load）:通過
該圖可以看出在任一時間點事務響應時間與用戶數目的關系，從而掌握系統在用戶并發方面的性
能數據。
?
g.事務響應時間（百分比）圖（Transaction Response Time(percentile)）:該
圖是根據測試結果進行分析而得到的綜合分析圖。分析該圖應從整體出發，若可能事務的最大響
應時間很長，但如果大多數事務具有可接受的響應時間，則系統的性能是符合。
?
h.事務響應時間分布情況圖（Transaction Response Time (Distribution)）:該
圖顯示了測試過程中不同響應時間的事務數量。若系統預先定義了相關事務可以接受的最小和最
大事務響應時間，則可以使用此圖確定系統性能是否在接受范圍內。
??????分析到這一步，只能大概判斷出瓶頸可能會出在那，要具體定位瓶頸還需要更深入
的分析。沒有貼圖，看起來有點費勁，如果你對這些圖都比較了解，應該是比較簡單的.
轉載于:https://www.cnblogs.com/Darrenblog/p/winterwinner.html
創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎總結
- 上一篇： 以客户的名义，宏杉科技“存储七项式”律己
- 下一篇： 毕设项目 - 大数据+爬虫 疫情分析可视