系統壓力測試(一) - IT閱讀

怎麼看壓測報告，一份報告都有哪些重點 ... JMiter壓測軟體：一款通過不斷提高對系統壓力，用於測試系統性能，如負載，功能，效能，迴歸等；的有簡潔 ... 系統壓力測試(一) 首頁 最新 HTML CSS JavaScript jQuery Python3 Python2 Java C C++ Go SQL 首頁 最新 Search 系統壓力測試(一) 2019-01-01254 《目錄》 -------->認知，瞭解壓測的一些引數，瞭解什麼是正向的壓測結果 -------->壓測需求一般包含的東西與及步驟 -------->JMeter壓測軟體的介紹，壓測計劃中常用模組的用途 -------->瞭解怎麼給出壓測人員出一份壓測指標，計算自己系統的合理吞吐量 -------->怎麼看壓測報告，一份報告都有哪些重點 一、認知 首先明確一點，壓測的目的是為了觀察當前系統的負載能!壓測的結果一般情況可以通過吞吐量與併發數的比例來觀察，吞吐量與併發數呈正相關關係，在一定併發數的情況下，吞吐量越高，說明系統性能越好! 開發的原因需要對吞吐量（TPS）、QPS、併發數、響應時間（RT）幾個概念做下了解： 1.響應時間(RT)  　　響應時間是指系統對請求作出響應的時間。

直觀上看，這個指標與人對軟體效能的主觀感受是非常一致的，因為它完整地記錄了整個計算機系統處理請求的時間。

由於一個系統通常會提供許多功能，而不同功能的處理邏輯也千差萬別，因而不同功能的響應時間也不盡相同，甚至同一功能在不同輸入資料的情況下響應時間也不相同。

所以，在討論一個系統的響應時間時，人們通常是指該系統所有功能的平均時間或者所有功能的最大響應時間。

當然，往往也需要對每個或每組功能討論其平均響應時間和最大響應時間。

  　　對於單機的沒有併發操作的應用系統而言，人們普遍認為響應時間是一個合理且準確的效能指標。

需要指出的是，響應時間的絕對值並不能直接反映軟體的效能的高低，軟體效能的高低實際上取決於使用者對該響應時間的接受程度。

對於一個遊戲軟體來說，響應時間小於100毫秒應該是不錯的，響應時間在1秒左右可能屬於勉強可以接受，如果響應時間達到3秒就完全難以接受了。

而對於編譯系統來說，完整編譯一個較大規模軟體的原始碼可能需要幾十分鐘甚至更長時間，但這些響應時間對於使用者來說都是可以接受的。

  2.吞吐量(Throughput)       吞吐量是指系統在單位時間內處理請求的數量。

對於無併發的應用系統而言，吞吐量與響應時間成嚴格的反比關係，實際上此時吞吐量就是響應時間的倒數。

前面已經說過，對於單使用者的系統，響應時間（或者系統響應時間和應用延遲時間）可以很好地度量系統的效能，但對於併發系統，通常需要用吞吐量作為效能指標。

  　　對於一個多使用者的系統，如果只有一個使用者使用時系統的平均響應時間是t，當有你n個使用者使用時，每個使用者看到的響應時間通常並不是n×t，而往往比n×t小很多（當然，在某些特殊情況下也可能比n×t大，甚至大很多）。

這是因為處理每個請求需要用到很多資源，由於每個請求的處理過程中有許多不走難以併發執行，這導致在具體的一個時間點，所佔資源往往並不多。

也就是說在處理單個請求時，在每個時間點都可能有許多資源被閒置，當處理多個請求時，如果資源配置合理，每個使用者看到的平均響應時間並不隨使用者數的增加而線性增加。

實際上，不同系統的平均響應時間隨使用者數增加而增長的速度也不大相同，這也是採用吞吐量來度量併發系統的效能的主要原因。

一般而言，吞吐量是一個比較通用的指標，兩個具有不同使用者數和使用者使用模式的系統，如果其最大吞吐量基本一致，則可以判斷兩個系統的處理能力基本一致。

  3.併發使用者數  　　併發使用者數是指系統可以同時承載的正常使用系統功能的使用者的數量。

與吞吐量相比，併發使用者數是一個更直觀但也更籠統的效能指標。

實際上，併發使用者數是一個非常不準確的指標，因為使用者不同的使用模式會導致不同使用者在單位時間發出不同數量的請求。

一網站系統為例，假設使用者只有註冊後才能使用，但註冊使用者並不是每時每刻都在使用該網站，因此具體一個時刻只有部分註冊使用者同時線上，線上使用者就在瀏覽網站時會花很多時間閱讀網站上的資訊，因而具體一個時刻只有部分線上使用者同時向系統發出請求。

這樣，對於網站系統我們會有三個關於使用者數的統計數字：註冊使用者數、線上使用者數和同時發請求使用者數。

由於註冊使用者可能長時間不登陸網站，使用註冊使用者數作為效能指標會造成很大的誤差。

而線上使用者數和同事發請求使用者數都可以作為效能指標。

相比而言，以線上使用者作為效能指標更直觀些，而以同時發請求使用者數作為效能指標更準確些。

  4.QPS每秒查詢率(QueryPerSecond)  　　每秒查詢率QPS是對一個特定的查詢伺服器在規定時間內所處理流量多少的衡量標準，在因特網上，作為域名系統伺服器的機器的效能經常用每秒查詢率來衡量。

對應fetches/sec，即每秒的響應請求數，也即是最大吞吐能力。

（類似於TPS，只是應用於特定場景的吞吐量）  二、如何做一個壓測需求? 步驟1：壓力測試分兩種場景： 一種是單場景只壓一個介面的；第二種是混合場景，多個有關聯的介面。

壓測時間，一般場景都執行10-15分鐘。

如果是疲勞測試，可以壓一天或一週，根據實際情況來定。

步驟2：壓測前要明確壓測功能和壓測指標，一般需要確定的幾個問題： 固定介面引數進行壓測還是進行介面引數隨機化壓測？ 要求支援多少併發數？單介面多少，關聯介面多少 TPS（每秒鐘處理事務數）目標多少？響應時間要達到多少？ 被壓的伺服器名稱或者被壓的伺服器IP，一般都是壓測指定的伺服器 步驟3：進行壓測(詳細見下面應用分析) 步驟4：壓測分析與調整 有錯誤率同開發確認，確定是否允許錯誤的發生或者錯誤率允許在多大的範圍內； Throughput吞吐量每秒請求的數大於併發數，則可以慢慢的往上面增加；若在壓測的機器效能很好的情況下，出現吞吐量小於併發數(執行緒數)，說明併發數不能再增加了，可以慢慢的往下減，找到最佳的併發數； 壓測結束，·登陸相應的web伺服器檢視CPU等效能指標，進行資料的分析; 最大的tps:不斷的增加併發數，加到tps達到一定值開始出現下降，那麼那個值就是最大的tps。

最大的併發數：最大的併發數和最大的tps是不同的概率，一般不斷增加併發數，達到一個值後，伺服器出現請求超時，則可認為該值為最大的併發數。

壓測過程出現效能瓶頸，若壓力機工作管理員檢視到的cpu、網路和cpu都正常，未達到90%以上，則可以說明伺服器有問題，壓力機沒有問題。

影響效能考慮點包括：資料庫(重點)、應用程式、中介軟體（tomact、Nginx）、網路和作業系統等方面。

步驟5：出壓測--->聚合報告  本次壓測的要求指標，效能要求 本次壓測的機器效能 本次壓測的各項各項指標 本次壓測的報告結果分析 壓測報告建議 壓測報告等級 三、介紹及入門 JMiter壓測軟體：一款通過不斷提高對系統壓力，用於測試系統性能，如負載，功能，效能，迴歸等；的有簡潔明瞭的圖形介面軟體! JMeter原理：向伺服器提交請求並從伺服器取回請求返回的結果  一般有如下一整個流程: 在JMeter中，一個完整的測試計劃將包括一個或多個元素，如執行緒組，邏輯控制器，樣品產生控制器，監聽器，定時器，斷言和配置元素。

測試計劃必須至少有一個執行緒組。

一般分五個步驟:（1）新增執行緒組（2）新增http請求（3）在http請求中寫入接入url、路徑、請求方式和引數（4）新增檢視結果樹（5）呼叫介面、檢視返回值。

其作用和各自的功能如下： 1、測試計劃：測試的起點，其他配置原件的容器 2、執行緒組：代表一定數量的併發使用者，它可以用來模擬併發使用者傳送請求 3、取樣器Spamler：代表了各種各樣的請求 4、監聽器：負責收集測試結果，同時也被告知了結果顯示的方式。

功能是對取樣器的請求結果顯示、統計一些資料（吞吐量、KB/S……）等 5、斷言：用於來判斷請求響應的結果是否如使用者所期望，是否正確。

它可以用來隔離問題域，即在確保功能 正確的前提下執行壓力測試。

這個限制對於有效的測試是非常有用的。

6、定時器：負責定義請求（執行緒）之間的延遲間隔，模擬對伺服器的連續請求。

7、邏輯控制器：允許自定義JMeter傳送請求的行為邏輯，它與Sampler結合使用可以模擬複雜的請求序列。

8、配置元件維護Sampler需要的配置資訊，並根據實際的需要會修改請求的內容。

9、前置處理器和後置處理器負責在生成請求之前和之後完成工作。

前置處理器常常用來修改請求的設定，後置處理器則常常用來處理響應的資料。

三、應用與分析 1. 看效能分報告，一般一個JMeter有如下引數可以參考 2.  介面指標 5.聚合報告怎麼看? 行業經驗：對於遊戲行業而言，對於效能的要求是非常高的，響應和延遲是其中最為重要的指標。

其效能底線往往是要求90%使用者的響應時間是在1秒內，對於2-3秒的使用者響應只有一些非常小點選率的請求時才會適當允許!  對於一般的商業系統，效能不錯的在1~2秒作用，3~5秒則稍微難以接受。

這個效能指標是指90%的使用者響應秒數。

TPS：吞吐量——預設情況下表示每秒完成的請求數（RequestperSecond)，當使用了TransactionController時，也可以表示類似LoadRunner的TransactionperSecond數! tps越高說明伺服器處理能力越好 Min：最小響應時間 Max：最大響應時間 90%Line：90%請求的響應時間 Average：每個請求的平均響應時間 Median：中值，即50%請求的平均響應時間 Samples：各個測試的樣本總數，也即是說執行緒數*迴圈次數， Error%：本次測試中出現錯誤的請求的數量/請求的總數 KB/Sec：每秒從伺服器端接收到的資料量，相當於LoadRunner中的Throughput/Sec QPS：每秒查詢率QPS是對一個特定的查詢伺服器在規定時間內所處理流量多少的衡量標準 注意：如果初步設計壓測的聚合報告，對很多引數不甚明瞭，那麼可以重點關注TPS，MIN與MAX，Error%，以及90%Line這幾個引數。

它可以讓你初步得到如下結論： 當併發在多少（執行緒數）的時候，每秒的TPS是多少，每秒的查詢率QPS是多少QPS；當前系統90%Line使用者的響應時間是多少，最長的響應時間是多少Max，最快的響應時間是多少MIN。

壓測中出現多少錯誤率Error，與目標允許的容錯率xxxx不符合/符合，請開發解決! --------------------------------------------------------------------------------------------------------------------------------------------------------------------- 文章的一些資訊採納自部分網路部落格，僅做學習使用 相關文章 系統壓力測試(一) 網站系統壓力測試Jmeter+Badboy 使用AB壓力測試工具進行系統壓力測試 mysql之sysbench1.0.3安裝與系統壓力測試 AndroidAPP壓力測試(一)之Monkey工具介紹 AndroidAPP壓力測試(一)之Monkey工具介紹 LoadRunner11實操壓力測試-一步一步慢慢來 mysql+mycat壓力測試一例 壓力測試和系統優化tips 系統技術非業餘研究»Tsung壓力測試工具介紹PPT java程序在經過壓力測試後，系統記憶體佔用比居高不下 [搬運工系列]-JMeter（二十一）壓力測試-測試Java請求 效能、負載、壓力測試——從效能測試角度理解系統開發 一次壓力測試Bug排查-epoll使用避坑指南 [Springcloud一步步實現廣告系統]20.系統執行測試 分類導航 HTML/CSS HTML教程 HTML5教程 CSS教程 CSS3教程 JavaScript JavaScript教程 jQuery教程 Node.js教程 服務端 Python教程 Python3教程 Linux教程 Docker教程 Ruby教程 Java教程 JSP教程 C教程 C++教程 Perl教程 Go教程 PHP教程 正則表達式 資料庫 SQL教程 MySQL教程 PostgreSQL教程 SQLite教程 MongoDB教程 Redis教程 Memcached教程 行動端 IOS教程 Swift教程 Advertisement 三度辭典 Copyright©2016-2021IT閱讀  Itread01.comAllRightsReserved. 0.001291036605835