性能閑談

寫在前面

在軟件系統日益復雜的今天，性能已經成為軟件質量重要的衡量標準之一，這一點尤其體現在和Web相關的系統上。對Web應用來說，一般以用戶感受到的響應時間來描述系統的性能。

介紹性能測試過程中的一些相關術語：響應時間、并發用戶數、事務響應時間、吞吐量、吞吐率、TPS（每秒事務響應數）、性能計數器等。

1.1?性能測試相關術語

1.1.1?并發用戶數

關于并發用戶的數量，有兩種常見的錯誤觀點：一是把并發用戶數量理解為使用系統的全部用戶的數量，理由是這些用戶可能同時使用系統；二是把用戶在線數量理解為并發用戶數量。實際上，在線用戶不一定是并發用戶，原因是在線用戶不一定就與系統進行了數據交互，例如正在瀏覽網頁信息的用戶，對服務器是沒有任何影響的。但是，用戶在線數量是統計并發用戶數量的主要依據之一。

并發主要針對服務器而言，是否并發的關鍵是看用戶的操作是否對服務器產生了影響。因此，并發用戶數量的正確理解是，在同一時刻與服務器進行交互的在線用戶數量。

并發用戶數量的統計方法目前還沒有準確的公式，因為不同的系統會有不同的并發特點。例常見的管理系統的并發用戶數一般是在線用戶的5%-20%左右，所以并發用戶數很大程度上是根據經驗和行業的一些標準來計算的。

1.1.2?響應時間

響應時間是指應用系統從發出請求開始到客戶端接收到所有數據所消耗的時間。頁面響應時間可以分解為“網絡響應時間”和“應用程序與系統響應時間”之和

1.1.3?事務響應時間

事務可能由一系列請求組成，事務的響應時間主要針對用戶而言，是為了向用戶說明業務響應時間而提出的。例如：跨行取款事務的響應時間就是由一系列的請求組成的。

1.1.4?吞吐量

吞吐量是指單位時間內服務器處理客戶請求的數量，吞吐量通常使用請求數/秒來衡量，其直接體現服務器的承載能力。

1.1.5?吞吐率（Throughput )

通常用來指單位時間內網絡上傳輸的數據量，也可以指單位時間內處理的客戶端請求數量。它是衡量網絡性能的重要指標。但是從用戶或業務角度來看，吞吐率也可以用“請求數／秒”或“頁面數／秒”、“業務數／小時或天”、“訪問人數／天”、“頁面訪問量／天”來衡量。

1.1.6 TPS ( Transaction Per Second )

每秒系統能夠處理的交易或事務的數量。它是衡量系統處理能力的重要指標。TPS 是LoadRtumer 中重要的性能參數指標。

1.1.7?點擊率（Hit per second )

每秒用戶向從Web 服務器提交的HTTP 請求數。這個指標是Web應用特有的一個指標：從Web應用是“請求一響應”模式，用戶發出一次申請，服務器就要處理一次，所以“點擊”是Web應用能夠處理交易的最小單位。如果把每次點擊定義為一次交易，點擊率和TPS 就是一個概念。不難看出，點擊率越大，對服務器的壓力也越大。點擊率只是一個性能參考指標，重要的是分析點擊時產生的影響。

需要注意的是，這里的點擊不是指鼠標的一次“單擊”操作，因為在一次“單擊”操作中，客戶端可能向服務器發出多個HTTP 請求。

1.1.8?資源利用率

資源利用率指的是對不同系統資源的使用程度，例如服務器的CPU利用率、磁盤利用率、內存利用率、網絡等。資源利用率是分析系統性能指標進而改善性能的主要依據，通過比較配置調優前后系統資源的利用率來判斷調優的效果。

1.1.9?思考時間（Think Time）

思考時間是指用戶在進行操作是，每個請求之間的時間間隔。對于交互系統來說，用戶不肯能持續不斷的發生請求，一般情況下，用戶在向服務器端發生一個請求后，會等待一段時間再發送下一個請求。在實際的測試過程中，如何設置思考時間是性能測試工程

1.2?性能測試劃分

性能測試的方法主要包括以下幾種：

4?負載測試（Load Testing）

4?壓力測試（Stress Testing）

4?配置測試（Configuration Testing）

4?并發測試（Concurrency Testing）

4?可靠性測試（Reliability Testing）

2.1? ?執行策略

主要內容：根據當前版本約束和環境限制，說明性能測試的約束和計劃，表明測試的目的，預期達到的效果。

當前性能測試主要從以下幾個方面開展：

1.???模擬現網環境。

真實交付的現網環境相似的性能測試環境，所有性能測試的服務器都放置在同一個機房，屬于同一個網段，服務器與服務器之間的網絡交互通過交換機進行，在這里性能測試既要結合場景評估網絡可能帶來的性能瓶頸，同時也要在自己的組網中注意規避可能出現的網絡性能瓶頸

2.???性能測試數據分為基礎數據和業務數據兩部分。

性能測試數據庫和功能測試環境相互獨立。性能測試數據分為基礎數據和業務數據兩部分。基礎數據，指為了使表中的數據達到一定的數量級而填充的數據，目的是測試出數據庫索引是否足夠優化、表空間、索引空間是否足夠；業務數據，指為了使被測系統能夠按業務邏輯運行起來的數據，簡單地說，就是功能測試所使用的數據，目的是測試出SQL語句是否足夠優化、代碼是否足夠優化等。從另一個角度看，一個指的是配置類規格，一個是能力類規格

3.???屏蔽緩存，模擬最壞的情況。

緩存，是頁面性能優化的手段之一。對于非頻繁變化的數據，可以在容器中緩存起來，提高讀的性能，同時減輕數據庫壓力。另外，緩存失效后需要重啟緩存，即在系統剛發布、重新緩存過程中，用戶訪問速度會變慢、數據庫壓力也會加大。

為了避免類似系統剛上線，系統就受到Load過高的場景。在性能測試過程中，我們需要模擬沒有緩存的場景。 一切測試的出發點均是指合理的場景內最壞的情況

4.???先單場景，后混合場景，確保每個性能瓶頸都得到調優。

性能測試過程中，選擇先執行單場景，后執行混合場景的策略。

單場景執行，可以詳細測試到某個頁面、某個功能點等單點的性能，這種方式有利于定位性能瓶頸，優化代碼。混合場景，在單場景都優化完成后，按照一定的比例對各種場景進行組合，測試整個應用系統的總體性能表現。

5.???拆分，隔離分析，定位性能瓶頸。

性能測試過程中出現的小概率事件，往往隱藏著大的性能瓶頸。為了精確定位到瓶頸，需要將各個功能，或者一個功能的各個步驟進行拆分分析，然后在可能有問題的部分進行再排查，直到瓶頸定位到為止。

6.???根據性能測試通過標準，來判斷被測性能點通過與否。

性能測試將結合性能基線，以及互聯網的一些業界標準，來評估判斷被測試點是否通過

2.2? ?執行評估

制定性能測試策略之后，在實施性能測試之前，需要對被測系統做相應的評估。實施前的評估，主要目的是明確是否需要做性能測試和確立性能點。性能測試一般要求系統要支撐至少半小時的測試壓力，我們要對系統在測試前后狀態，以及測試期間各項能力的表現作出分析和評估。

1.??關鍵業務。

2.??可能的PV量。

3.??邏輯復雜度。

關鍵業務

首要維度，是確定被測項目是否屬于關鍵業務，有哪些主要的業務邏輯點，特別是跟客戶息息相關的功能點。云業務批量購買，批量實施，服務目錄展示，性能告警等等

如果項目（或功能點）不屬于關鍵業務（或關鍵業務點），則可轉入第二、三個維度進行評估。

日PV量

第二個維度，是界定被測項目各功能點的PV量。如果PV量很高，系統壓力很大，而且又是關鍵業務，該項目需要做性能測試；而且其關鍵業務點，可以被確定為性能點。例如，上述例子中的批量購買、批量實施。

如果PV量不高，系統壓力不大，但卻是關鍵業務點，則依據第三個維度來判斷。

邏輯復雜度

第三個維度，是判定被測項目各功能點的邏輯復雜度。如果一個主要業務的PV量不高，但是邏輯很復雜，則也需要通過性能測試。原因是，當某一個環節響應較慢，就會影響到其它環節，造成連帶效應。

其它

以上3個評估維護，是相輔相成、環環相扣的。在實際測試中，應該具體問題具體分析。例如，當一個功能點不滿足以上3個維度，但又屬于內存高消耗、CPU高消耗時，也可列入性能測試點行列，這就需要我們結合系統在測試中不斷完善我們的性能測試策略。

2.3? ?測試模型

業務模型

當前方案根據個人理解設計各個業務的客戶端請求模型，后期可以根據實際商用情況進行調整。

根據請求的動態變化情況，常見的為四種類型——固定式請求模型、浪涌式請求模型、振蕩式請求模型和動態式請求模型。以固定式為主進行性能測試。

依照場景和實際商用需求確定業務組合測試模型（未完待續）

軟件開發

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。