后臺性能測試規范

參考資料

• ISO25010
• IEEE 829
• 29119
• 書籍

《Performance Testing An ISTQB Certified Tester Foundation Level Specialist Certification Review.epub》

目前市面上介紹性能測試的最佳書。

Performance Testing An ISTQB Certified Tester Foundation Level Specialist Certification Review.epub: https://url97.ctfile.com/f/18113597-842033877-7092c2 (訪問密碼: 公眾號pythontesting 輸入 "密碼" 獲取)

• 軟件測試精品書籍文檔下載持續更新 https://github.com/china-testing/python-testing-examples 請點贊，謝謝！
• 本文持續更新 http://www.rzrgm.cn/testing-/p/17409169.html
• 本文涉及的python測試開發庫 謝謝點贊！ https://github.com/china-testing/python_cn_resouce
• python精品書籍下載 https://github.com/china-testing/python_cn_resouce/blob/main/python_good_books.md
• 英文原版下載：Software Testing Foundations, 5th - 2021.pdf (訪問密碼: 訂閱號pythontesting 發送 密碼) https://url97.ctfile.com/f/18113597-853966551-6ed72c

目的

規范云平臺性能測試，包括測試指標、測試過程、性能分析等。

測試指標

本指標適用于使用性能測試進行性能測試項目技術質量評價依據，規范技術測試結果評價，統一性能測試技術測試質量度量。應用系統技術質量度量指標范圍廣泛，本文難以涵蓋全部，僅供實際測試參考定制使用。 預期讀者為測試管理人員、測試實施人員、技術支持人員、項目管理人員等系統技術質量相關人員。

系統性能指標

• 響應時間 Response Time: RT

響應時間指用戶從客戶端發起請求開始，到客戶端接收到從服務器端返回的響應結束，整個過程所耗費的時間。在性能檢測中一般以壓力發起端至被壓測服務器返回處理結果的時間為計量，單位一般為秒或毫秒。平均響應時間指系統穩定運行時間段內，同一交易的平均響應時間。一般而言，交易響應時間均指平均響應時間。 平均響應時間指標值應根據不同的交易分別設定，一般情況下，分為復雜交易響應時間、簡單交易響應時間、特殊交易響應時間。其中，特殊交易響應時間的設定必須明確該交易在響應時間方面的特殊性。

1秒以下為佳，部分復雜業務3秒以下。

• 吞吐量（系統處理能力）

系統處理能力是指系統在利用系統硬件平臺和軟件平臺進行信息處理的能力。 系統處理能力通過系統每秒鐘能夠處理的交易數量來評價，交易有兩種理解：一是業務人員角度的一筆業務過程；二是系統角度的一次交易申請和響應過程。前者稱為業務交易過程，后者稱為事務。兩種交易指標都可以評價應用系統的處理能力。一般的建議與系統交易日志保持一致，以便于統計業務量或者交易量。系統處理能力指標是技術測試活動中重要指標。

一般情況下，用以下指標來度量：
HPS（Hits Per Second） ：每秒點擊次數，單位是次/秒。
TPS（Transaction per Second）：系統每秒處理交易數，單位是筆/秒。
QPS（Query per Second）：系統每秒處理查詢次數，單位是次/秒。

無論TPS、QPS、HPS，此指標是衡量系統處理能力非常重要的指標，越大越好，根據經驗，一般情況下：1000 TPS~50000 TPS

• 并發用戶 Virtual User：VU

并發用戶數指在同一時刻內，登錄系統并進行業務操作的用戶數量。 并發用戶數對于長連接系統來說最大并發用戶數即是系統的并發接入能力。對于短連接系統而言最大并發用戶數并不等于系統的并發接入能力，而是與系統架構、系統處理能力等各種情況相關。例如系統吞吐能力很強，加上短連接一般都有連接復用，往往并發用戶數大于系統的并發接入連接數。

一般情況下，性能測試是將系統處理能力容量測出來，而不是測試并發用戶數，除了服務器長連接可能影響并發用戶數外，系統處理能力不受并發用戶數影響，可以用最小的用戶數將系統處理能力容量測試出來，也可以用更多的用戶將系統處理能力容量測試出來。

• 錯誤率 Virtual Failure Ratio：FR: VU

錯誤率指系統在負載情況下，失敗交易的概率。錯誤率＝（失敗交易數/交易總數）×100%。穩定性較好的系統，其錯誤率應該由超時引起，即為超時率。

不同系統對錯誤率的要求不同，但一般不超出千分之六，即成功率不低于99.4%。

資源指標

• CPU Central Processing Unit：CPU

中央處理器是一塊超大規模的集成電路，是計算機的運算核心（Core）和控制核心（ Control Unit）。它的功能主要是解釋計算機指令以及處理計算機軟件中的數據。CPU Load：系統正在干活的多少的度量，隊列長度。系統平均負載。

CPU指標主要指的CPU使用率、利用率，包括用戶態（user）、系統態（sys）、等待態（wait）、空閑態（idle）。CPU使用率、利用率要低于業界警戒值范圍之內，即小于或者等于75%、CPU sys%小于或者等于30%，CPU wait%小于或者等于5%。單核CPU也需遵循上述指標要求。CPU Load要小于CPU核數。

• 內存 Memory

內存是計算機中重要的部件之一，它是與CPU進行溝通的橋梁。計算機中所有程序的運行都是在內存中進行的，因此內存的性能對計算機的影響非常大。

現代的操作系統為了最大利用內存，在內存中存放了緩存，因此內存利用率100%并不代表內存有瓶頸，衡量系統內有瓶頸主要靠SWAP（與虛擬內存交換）交換空間利用率，一般情況下，SWAP交換空間利用率要低于70%，太多的交換將會引起系統性能低下。

• 磁盤吞吐量 Disk Throughput

磁盤指標主要有每秒讀寫多少兆，磁盤繁忙率，磁盤隊列數，平均服務時間，平均等待時間，空間利用率。其中磁盤繁忙率是直接反映磁盤是否有瓶頸的重要依據，一般情況下，磁盤繁忙率要低于70%。

• 網絡吞吐量 Network Throughput

網絡吞吐量是指在無網絡故障的情況下單位時間內通過的網絡的數據數量。單位為Byte/s。網絡吞吐量指標用于衡量系統對于網絡設備或鏈路傳輸能力的需求。當網絡吞吐量指標接近網絡設備或鏈路最大傳輸能力時，則需要考慮升級網絡設備。

網絡吞吐量指標主要有每秒有多少兆流量進出，一般情況下不能超過設備或鏈路最大傳輸能力的70%。

• 內核參數

操作系統內核參數主要包括信號量、進程、文件句柄，一般不要超過設置的參數值即可，具體如下：

中間件指標

常用的中間件例如Tomcat、Weblogic等指標主要包括JVM、ThreadPool、JDBC，具體如下：

當前正在運行的線程數不能超過設定的最大值。一般情況下系統性能較好的情況下，線程數最小值設置50和最大值設置200比較合適。

當前運行的JDBC連接數不能超過設定的最大值。一般情況下系統性能較好的情況下，JDBC最小值設置50和最大值設置200比較合適。

GC頻率不能頻繁，特別是FULL GC更不能頻繁，一般情況下系統性能較好的情況下，JVM最小堆大小和最大堆大小分別設置1024 M比較合適。

數據庫指標

常用的數據庫例如ＭySQL指標主要包括SQL、吞吐量、緩存命中率、連接數等，具體如下：

SQL耗時越小越好，一般情況下微秒級別。
命中率越高越好，一般情況下不能低于95%。
鎖等待次數越低越好，等待時間越短越好。

穩定性指標

最短穩定時間：系統按照最大容量的80%或標準壓力（系統的預期日常壓力）情況下運行，能夠穩定運行的最短時間。 一般來說，對于正常工作日（8小時）運行的系統，至少應該能保證系統穩定運行８小時以上。對于7×24運行的系統，至少應該能夠保證系統穩定運行24小時以上。 如果系統不能穩定的運行，上線后，隨著業務量的增長和長時間運行，將會出現性能下降甚至崩潰的風險。

TPS曲線穩定，沒有大幅度的波動。
各項資源指標沒有泄露或異常情況。

批量處理指標

指批量處理程序單位時間內處理的數據數量。一般用每秒處理的數據量來衡量。處理效率是估算批量處理時間窗口最重要的計算指標。 關于批量處理時間窗口，不同系統的批量處理時間窗口在起止時間上可以部分重疊。另外，同一系統內部，也可能存在多個批量處理過程同時進行，其時間窗口相互疊加。 長時間批量處理將會對聯機在線實時交易產生重大的性能影響。

在數據量很大的情況下，批處理時間窗口時間越短越好。
不能影響實時交易系統性能。

可擴展性指標

指應用軟件或操作系統以集群方式部署，增加的硬件資源與增加的處理能力之間的關系。計算公式為：（增加性能/原始性能）/（增加資源/原始資源）×100%。 擴展能力應通過多輪測試獲得擴展指標的變化趨勢。 一般擴展能力非常好的應用系統，擴展指標應是線性或接近線性的，現在很多大規模的分布式系統的擴展能力非常好。

理想的擴展能力是資源增加幾倍，性能就提升幾倍。
擴展能力至少在70%以上。

可靠性指標

• 雙機熱備

  • 節點切換是否成功及其消耗時間。
  • 雙機切換是否有業務中斷。
  • 節點回切是否成功及其耗時
  • 雙機回切是否有業務中斷。
  • 節點回切過程中的數據丟失量。在進行雙機切換的同時，使用壓力發生工具模擬實際業務發生情況，對應用保持一定的性能壓力，保證測試結果符合生產實際情況。

• 集群

  • 集群中某個節點出現故障時，系統是否有業務中斷情況出現。
  • 集群中新增一個節點時，是否需要重啟系統。
  • 故障節點恢復后，加入集群，是否需要重啟系統。
  • 故障節點恢復后，加入集群，系統是否有業務中斷情況出現。
  • 節點切換需要多長時間。在驗證集群可靠性的同時，需根據具體情況使用壓力工具模擬實際業務發生相關情況，對應用保持一定的性能壓力，確保測試結果符合生產實際情況。

• 備份和恢復：本指標為了驗證系統的備份、恢復機制是否有效可靠，包括系統的備份和恢復、數據庫的備份和恢復、應用的備份和恢復，包括以下測試內容：

  • 備份是否成功及其消耗時間。
  • 備份是否使用腳本自動化完成。
  • 恢復是否成功及其消耗時間。
  • 恢復是否使用腳本自動化完成指標體系的運用原則。
  • 指標項的采用和考察取決于對相應系統的測試目的和測試需求。被測系統不一樣，測試目的不一樣，測試需求也不一樣，考察的指標項也有很大差別。
  • 部分系統涉及額外的前端用戶接入能力的，需要考察用戶接入并發能力指標。
  • 對于批量處理過程的性能驗證，主要考慮批量處理效率并估算批量處理時間窗口。
  • 如測試目標涉及到系統性能容量，測試需求中應根據相關指標項的定義，明確描述性能指標需求。
  • 測試指標獲取后，需說明相關的前提條件（如在多少的業務量、系統資源情況等）。

性能測試的過程

• 測試需求得到批準
• 數據已獲批準
• 性能測試計劃已獲批準
• 測試工具經POC可用
• 業務流程清單已批準
• 測試環境
• 測試腳本
• 測試方案
• 測試監控

測試計劃

測試計劃包含測試環境、測試數據、風險分析、工具和人力資源等內容，具體內容可以基于IEEE829和ISO 29119定制。

為了完成性能測試計劃，通常需要進行如下活動。

• 研討會

開發、產品、項目、測試等聚在一起，性能工程師告知項目的利益相關者關于性能測試的基本規則、要求和程序。

• 業務和技術概述

性能工程師要清楚地了解應用/基礎設施的性質（軟件、硬件、協議、業務流程和所需數據）。在這一點上，性能工程師可以強調系統中任何早期的潛在性能弱點，并提前告知可能需要關于這些弱點的更多信息。

• 需求/用戶故事的定義

結合需求/用戶故事，可以得出明確的成功標準（對于需求和用戶故事，因為兩者都需要一個可衡量的方法來知道最終的測試是否會通過）。

• 接口列表

• 模型分析（目標）

構建一個真實世界的使用模型。這些應該基于平均、峰值和最壞的情況（周末、月末、季末、或財政年或日歷年末，或明年或五年后的預期峰值）。模型使性能工程師能夠確定哪種性能測試情景適合即將進行的性能測試。這些場景將與前面提到的性能要求/用戶故事和風險相關聯。

• 性能測試工具分析/概念驗證

幾乎在每一種情況下，性能測試都需要工具。有大量的商業和開放源碼的工具，選擇正確的工具會使性能測試更容易。需要注意的是，沒有一種工具是適合所有情況的，也沒有一種工具對任何情況都是完美的。

• 性能項目規劃（時間表Schdule）

規劃過程中的最后一步是確定性能項目的時間線。從整個項目的時間表和完成日期開始，向后推算，性能測試的測試計劃階段可以被記錄下來。還需要進一步的細節，但在這一點上，它將給出一個估計性能測試時間表的總體情況。在這一點上，生成一個甘特圖來添加到性能測試計劃中是很有用的。還應該記住，計劃過程中總是會遺漏任務或可能發生的隨機事件，但隨著經驗的積累（或可能是以前的性能測試計劃的 "復制"），這種情況可以減少。

• 性能測試計劃
  讓項目等相關人員參與到性能測試計劃的審查中來是合適的。這份文件成為性能測試項目的預期結果，從利益相關者那里得到反饋，以確保性能測試的目標/目的和整個項目的目標/目的都能實現。

小結：測試計劃定義了性能測試范圍、測試環境、測試數據、工具和所需的人力資源，并完成了風險識別和分析。其輸出是一個更新的項目測試計劃和/或性能測試計劃。

性能測試項目檢測與控制

注意這里提到的監測是指監測性能測試項目的進展，而不是在性能測試期間進行的監測。

控制是為了在遇到可能影響性能效率的問題時提供行動計劃，例如：

• 如果基礎設施不能按計劃為特定的性能測試產生所需的負載，則增加負載生成能力
• 改變、新建或更換硬件
• 網絡組件的變化
• 軟件實施的變化

對性能測試目標進行評估，以檢查退出標準的實現情況。

測試分析

有效的性能測試是基于對性能要求、測試目標、服務水平協議（SLA）、IT架構、流程模型和其他構成測試基礎的項目的分析。這項活動可以通過使用電子表格或容量規劃工具對系統資源需求和/或行為進行建模和分析來支持。

具體的測試條件被確定，如負載水平、時間條件和要測試的事務。然后決定所需的性能測試的類型（例如，負載、壓力、可擴展性）。

a.測試用例和腳本設計

測試是由測試條件、測試用例和測試程序這三個部分組成的。

b.測試場景設計

充分考慮：

• 需求/用戶故事
• 業務流程
• 性能風險
• 選擇的性能工具
• 數據規模
• 項目范圍和約束

充分結合負載測試、壓力測試、可擴展性測試、尖峰測試、耐久性測試、并發測試、容量測試等

1. 前面提到的性能測試類型
2. 虛擬用戶的總數和用戶組之間的分布情況
3. 要測試的業務流程
4. 負載模型--虛擬用戶登錄的速度（上升），測試的持續時間，以及虛擬用戶如何注銷（下降）。
5. 業務流程中細分的交易總數
6. 在性能測試期間，任何需要添加到負載中的后臺工作。

c.監控設計

軟件、硬件和基礎設施將決定如何進行監控，而需求/用戶故事將決定所需的監控量。需要考慮的事情包括：

• 所選擇的性能和監控工具 - 一個工具是否能涵蓋所有需要的監控，還是需要多個工具？

• 結果存儲 - 需要多少存儲空間來存儲結果集，以及這些工具是否能夠訪問這個存儲區域？

• 安全訪問 - 性能監測工具是否能夠訪問所需的計數器進行監測？

• 所需的指標 - 既要考慮默認的指標集，又要考慮與性能測試要求及需求相關的具體指標。

d.數據計劃

性能測試可能需要幾百個用戶做幾十個迭代，需要幾萬個輸入數據記錄，并將數據填充到性能測試環境中。

e.時間表

最后一步是為性能測試的創建和執行創建一個更詳細的低級別的時間表。這個時間表不僅要考慮何時創建和運行性能測試，還要考慮由誰來創建和運行。前面創建的甘特圖可以用較低層次的細節來顯示逐日計劃，包括在這個階段計劃的具體性能測試的創建和隨后的執行。

小結：性能測試是基于對測試基礎的分析（性能要求、測試目標、服務級別協議、IT架構、流程模型和其他項目），由系統資源要求和/或行為的建模和分析來支持。具體的測試條件，如負載水平、時間條件和要測試的事務，決定了性能測試的類型（例如，負載、壓力、可擴展性）。

測試設計

此步實現詳細的性能測試用例與腳本。腳本要遵循公司編程規范。

a.數據準備
主數據、用戶定義的數據、事務性數據

b.測試實現
腳本實現。

注意點

• 手動執行腳本
• 參數化
• 關聯
• 檢查點
• 計時
• 迭代并發執行

測試執行

此步將性能測試用例代碼化并執行。

a.環境搭建
檢查軟硬件列表、網絡等。

b.測試執行
運行性能測試，確保適當的控制是到位的，以允許有意義的結果。這聽起來很明顯，但令人驚訝的是，在執行前經常忘記一些事情，導致無效的結果和時間的浪費。性能測試通常是循環進行的--可能有一個或若干個性能測試，將針對代碼/應用/系統的一個版本/構建來執行。

c.結果分析

d.中期測試報告
每次測試后，應寫一份結果總結。中期報告應該是對測試目標成功或失敗的簡短總結（一封電子郵件或一頁報告）。如果你正在進行上百個測試，這可能是不可能的；顯然，為每個測試寫一份報告是不現實的，為一個測試周期寫一份報告可能更合適。

重要的是，這個總結將給相關者提供一個關于目標的觀點，以便根據需要做出決定。更深層次的分析可以包含在這份報告中，或者可能需要幾個執行周期來確定更深層次的問題。

e.補救措施（如果需要的話）
在每個性能測試執行完成后，應該有一個決定點，決定測試是否完成得令人滿意。
補救工作可以集中在腳本（改變或更新），測試數據（改變或刷新），基礎設施，或被測系統。任何補救工作都必須被記錄下來。

f.測試周期報告
在一個性能測試周期完成時，應完成一份測試周期報告。這比中期測試報告更全面，包含了中期測試報告中沒有包括的額外信息。在這一點上，可以對該周期內的測試和早期執行的周期進行性能比較。

g.結果審查會議
這個會議的目的是與相關者（包括技術和商業）一起分析結果。在這一點上相關者可以利用審查會議的信息，對性能測試項目做出明智的決定。

性能工程師：

• 證明性能測試已經成功執行。
• 識別新的潛在性能風險。
• 識別并展示測試計劃的任何變化。
• 顯示所進行的任何補救工作。
• 顯示任何進一步改進系統和過程的機會。

h.系統和過程的改進
這包括對系統的改進（調整）和對性能過程的改進。只有在未完成的性能項目風險仍然需要進一步緩解時，才會進入這一狀態。目標應該是改善性能測試過程和/或正在遵循的程序。一旦完成，這個過程就會循環到最初的測試設置。

小結：測試執行運行性能測試；對結果進行評估，看系統的性能是否符合既定目標，并報告任何缺陷。

測試完成

性能測試結果在測試總結報告中提供給相關者。測試結果通過指標來表達，這些指標經常被匯總以簡化測試結果的含義。儀表盤等可視化的報告手段經常被用來表達性能測試結果，比基于文本的指標更容易理解。

a.測試完成報告
測試完成報告是對測試周期報告與性能測試計劃的整合。它不僅提供了所執行的測試周期的信息，而且詳細說明了性能測試項目和產品的風險，發現的缺陷，以及如何緩解這兩者。

b.介紹和建議

在會議上向項目利益相關者介紹調查結果和建議可能會更容易。這允許利益相關者澄清他們不理解的任何要點。這個階段對于讓性能測試和性能工程師給那些出席這次會議的利益相關者一個積極的印象是極其重要的。性能工程師必須考慮業務和技術知識的差異--可能需要召開兩次會議。一個好的做法是，在第一次會議上提供業務信息，但不提供技術細節，并在隨后的會議上與相關的書呆子進行技術細節上的 "深入探討"。

小結：性能測試結果在測試總結報告中提供給相關者，顯示為指標和儀表盤匯總，以簡化測試結果，讓利益相關者理解。

性能分析

性能分析的前提

性能分析的前提除了需要豐富的性能測試監控（如客戶側監控、基礎類監控、應用類監控），還需要具備相關的技術知識（包括但不限于：操作系統、中間件、數據庫、開發等）。

性能分析的流程

很多情況下壓測流量并沒有完全進入到后端（服務端），在網絡接入層（云化的架構，例如：SLB（Server Load Balancer）/WAF（Web Application Firewall ）/高防IP，甚至是CDN（Content Delivery Network）/全站加速等）可能就會出現由于各種規格（帶寬、最大連接數、新建連接數等）限制或者因為壓測的某些特征符合CC（Challenge Collapsar）和DDoS（Distributed Denial of Service）的行為而觸發了防護策略導致壓測結果達不到預期。
接著看關鍵指標是否滿足要求，如果不滿足，需要確定是哪個地方有問題，一般情況下，服務器端問題可能性比較大，也有可能是客戶端問題（這種情況非常小）。
對于服務器端問題，需要定位的是硬件相關指標，例如CPU，Memory，Disk I/O，Network I/O，如果是某個硬件指標有問題，需要深入的進行分析。
如果硬件指標都沒有問題，需要查看中間件相關指標，例如：線程池、連接池、GC等，如果是這些指標問題，需要深入的分析。
如果中間件相關指標沒問題，需要查看數據庫相關指標，例如：慢查SQL、命中率、鎖、參數設置。
如果以上指標都正常，應用程序的算法、緩沖、緩存、同步或異步可能有問題，需要具體深入的分析。

可能瓶頸點

• 硬件、規格上的瓶頸

一般指的是CPU、內存、磁盤I/O方面的問題，分為服務器硬件瓶頸、網絡瓶頸（對局域網可以不考慮）。

• 中間件上的性能瓶頸

一般指的是應用服務器、web服務器等應用軟件，還包括數據庫系統。 例如：中間件weblogic平臺上配置的JDBC連接池的參數設置不合理，造成的瓶頸。

• 應用程序上的性能瓶頸

一般指的是開發人員開發出來的應用程序。 例如，JVM參數不合理，容器配置不合理，慢SQL，數據庫設計不合理，程序架構規劃不合理，程序本身設計有問題（串行處理、請求的處理線程不夠、無緩沖、無緩存、生產者和消費者不協調等），造成系統在大量用戶訪問時性能低下而造成的瓶頸。

• 操作系統上的性能瓶頸

一般指的是Linux等操作系統。 例如，在進行性能測試，出現物理內存不足時，虛擬內存設置也不合理，虛擬內存的交換效率就會大大降低，從而導致行為的響應時間大大增加，這時認為操作系統上出現性能瓶頸。

• 網絡設備上的性能瓶頸

一般指的是防火墻、動態負載均衡器、交換機等設備。當前更多的云化服務架構使用的網絡接入產品：包括但不限于SLB、WAF、高防IP、CDN、全站加速等等。 例如，在動態負載均衡器上設置了動態分發負載的機制，當發現某個應用服務器上的硬件資源已經到達極限時，動態負載均衡器將后續的交易請求發送到其他負載較輕的應用服務器上。在測試時發現，動態負載均衡器沒有起到相應的作用，這時可以認為網絡瓶頸。

方法

CPU資源利用率很高的話，需要看CPU消耗User、Sys、Wait哪種狀態。
如果CPU User非常高，需要查看消耗在哪個進程，可以用top（linux）命令看出，接著用top –H –p 看哪個線程消耗資源高。如果是Java應用，就可以用jstack看出此線程正在執行的堆棧，看資源消耗在哪個方法上，查看源代碼就知道問題所在；如果是c++應用，可以用gprof性能工具進行分析。
如果CPU Sys非常高，可以用strace（linux）看系統調用的資源消耗及時間。
如果CPU Wait非常高，考慮磁盤讀寫了，可以通過減少日志輸出、異步或換速度快的硬盤。

操作系統為了最大化利用內存，一般都設置大量的cache，因此，內存利用率高達99%并不是問題，內存的問題主要看某個進程占用的內存是否非常大以及是否有大量的swap（虛擬內存交換）。

磁盤I/O一個最顯著的指標是繁忙率，可以通過減少日志輸出、異步或換速度快的硬盤來降低繁忙率。

網絡I/O主要考慮傳輸內容大小，不能超過硬件網絡傳輸的最大值70%，可以通過壓縮減少內容大小、在本地設置緩存以及分多次傳輸等操作提高網絡I/O性能。
內核參數一般都有默認值，這些內核參數默認值對于一般系統沒問題，但是對于壓力測試來說，可能運行的參數將會超過內核參數，導致系統出現問題，可以用sysctl來查看及修改。

JVM主要分析GC/FULL GC是否頻繁，以及垃圾回收的時間，可以用jstat命令來查看，對于每個代大小以及GC頻繁，通過jmap將內存轉儲，再借助工具HeapAnalyzer來分析哪地方占用的內存較高以及是否有內存泄漏可能。簡單點可以使用APM工具，例如阿里云ARMS。

如果線程不夠用，可以通過參數調整，增加線程；對于線程池中的線程設置比較大的情況，還是不夠用可能的原因是：某個線程被阻塞來不及釋放，可能在等鎖、方法耗時較長、數據庫等待時間很長等原因導致，需要進一步分析才能定位。

JDBC連接池不夠用的情況下，可以通過參數進行調整增加；但是對于數據庫本身處理很慢的情況下，調整沒有多大的效果，需要查看數據庫方面以及因代碼導致連接未釋放的原因。

SQL效率低下也是導致性能差的一個非常重要的原因，可以通過查看執行計劃看SQL慢在哪里，一般情況，SQL效率低下原因主要有：

調優

調優步驟
a.確定問題

• 應用程序代碼：在通常情況下，很多程序的性能問題都是寫出來的，因此對于發現瓶頸的模塊，應該首先檢查一下代碼。
• 數據庫配置：經常引起整個系統運行緩慢，一些諸如大型數據庫都是需要DBA進行正確的參數調整才能投產的。
• 操作系統配置：不合理就可能引起系統瓶頸。
• 硬件設置：硬盤速度、內存大小等都是容易引起瓶頸的原因，因此這些都是分析的重點。
• 網絡：網絡負載過重導致網絡沖突和網絡延遲。
  b.分析問題
• 當確定了問題之后，我們要明確這個問題影響的是響應時間吞吐量，還是其他問題？
• 是多數用戶還是少數用戶遇到了問題？如果是少數用戶，這幾個用戶與其它用戶的操作有什么不同？
• 系統資源監控的結果是否正常？CPU的使用是否到達極限？I/O情況如何？
• 問題是否集中在某一類模塊中？
• 是客戶端還是服務器出現問題？ 系統硬件配置是否夠用？
• 實際負載是否超過了系統的負載能力？ 是否未對系統進行優化？
• 通過這些分析及一些與系統相關的問題，可以對系統瓶頸有更深入的了解，進而分析出真正的原因。

c.確定調整目標和解決方案
高系統吞吐量，縮短響應時間，更好地支持并發。

d.測試解決方案
對通過解決方案調優后的系統進行基準測試。（基準測試是指通過設計科學的測試方法、測試工具和測試系統，實現對一類測試對象的某項性能指標進行定量的和可對比的測試）。

e.分析調優結果
系統調優是否達到或者超出了預定目標；系統是整體性能得到了改善，還是以系統某部分性能來解決其他問題；調優是否可以結束了。 最后，如果達到了預期目標，調優工作可以先告一段落。

調優注意事項

• 在應用系統的設計開發過程中，應始終把性能放在考慮的范圍內，將性能測試常態化，日常化的內網的性能測試+定期的真實環境的業務性能測試，PTS都可以支持。
• 確定清晰明確的性能目標是關鍵，進而將目標轉化為PTS中的壓測場景并設置好需要的目標量級，然后視情況選擇并發、TPS模式，自動遞增/手工調速的組合進行流量控制。
• 必須保證調優后的程序運行正確。
• 系統的性能更大程度上取決于良好的設計，調優技巧只是一個輔助手段。
• 調優過程是迭代漸進的過程，每一次調優的結果都要反饋到后續的代碼開發中去。
• 性能調優不能以犧牲代碼的可讀性和可維護性為代價。