大型網站壓力測試及優化方案

目錄

• 木桶理論應用在系統優化中
• 壓力測試如何實施
• 經常使用壓力測試工具選型
• 如何監控系統資源，定位性能瓶頸
• 針對測試報告進行鍼對性優化
• 使用JMeter進行壓力測試實踐

 

 

木桶理論應用在系統優化中

 

木桶理論又稱短板理論，其核心思想是一隻木桶盛水多少，並不取決於最高的木板，而取決於最短的那塊木板。

木桶原理應用在系統分析中，即系統的最終性能取決於系統中性能表現最差的組件，爲了提高系統總體性能，對系統中表現最差的組件進行優化能夠獲得最好的效果。

 

 

在網站系統中，用戶的訪問請求到達服務器，而後服務器返回數據並展現給用戶，這個過程要通過不少處理，每個過程的低效都會影響系統總體表現出來的性能。

 

按照木桶理論，若是一臺服務器性能很是強大，擁有充足的內存資源和CPU資源，可是磁盤I/O性能不足，那麼系統的整體性能是取決於當前最慢的磁盤I/O速度，而不是當前最優越的CPU或者內存，此時，磁盤I/O就是系統的性能瓶頸。

 

典型的好比使用Redis進行存儲的系統，因爲Redis自己性能很是優秀，一般狀況下存儲並不會制約系統的性能，在海量請求的狀況下，Redis的吞吐量會很是大，這時候制約系統的性能瓶頸就變成網絡帶寬。

 

 

壓力測試如何實施

性能測試在大型網站系統的設計和開發中很是重要，一般會和容量預估等工做結合在一塊兒，穿插在系統開發的不一樣方案。

性能測試能夠幫助咱們及時發現系統的性能短板，評估系統的能力，在這個基礎在上再進行鍼對性的性能優化。

同時，壓力測試還能夠幫助咱們驗證系統的穩定性和可靠性。

 

一個完整的性能測試方案一般包括如下幾個方面： 

1.壓力測試及生成性能報告

壓力測試一個重點是如何產生壓力，一般能夠經過本身編寫腳本模擬請求，或者使用成熟的壓測工具進行。

壓力測試很重要的一點是如何使得模擬壓測的數據儘可能真實，越接近真實用戶越好。

2.根據性能報告定位系統瓶頸，進行鍼對性優化，測試和優化的工做能夠和平常開發並行

壓力測試完成之後，咱們會拿到一個壓測報告，這個報告一般會告訴咱們系統的QPS、TPS、響應時延等數據，

這些數據可讓咱們對服務器的性能有個總體的瞭解，發現存在的問題，可是不能幫助咱們定位問題。

 

這個時候咱們能夠從系統的各個組件入手，關注系統的CPU、內存、IO、網絡，對比這些環節對總體性能的影響，肯定性能問題是系統哪一部分形成的，而後針對性的在系統中逐個優化。

3.估算容量承載能力，合理規劃系統資源

進行壓力測試的一個重要目的是讓現有的服務器資源發揮最大的價值，

通過前期的測試和分析，這時候咱們對系統總體的性能有了一個認識，對服務器的承載能力有了預估，

這個時候咱們就能夠結合業務規模配置服務器數量，CDN資源等，讓最少的資源產生最大的價值。

 

經常使用壓力測試工具選型

壓力測試很關鍵的一點是如何產生壓力，選擇哪款測試工具很重要，大的互聯網公司如百度／騰訊等，都有專門的測試開發團隊，開發公司內部應用的測試工具，以便更好的適應公司的業務，做爲SAAS服務的重要部分，幾個雲服務提供商也紛紛開放了壓測及性能監控服務。

大多數公司仍是會選擇本身完成測試工做，這裏關注一下經常使用的壓力測試工具。 

1.幾款流行的壓力測試工具 

（1）JMeter

Apache JMeter是Apache組織開發的基於Java的壓力測試工具，用於對軟件作壓力測試，它最初被設計用於Web應用測試但後來擴展到其餘測試領域。 它能夠用於測試靜態和動態資源例如靜態文件、Java小服務程序、CGI腳本、Java 對象、數據庫， FTP服務器, 等等。

 

JMeter 能夠用於對服務器、網絡或對象模擬巨大的負載，來在不一樣壓力類別下測試它們的強度和分析總體性能。

另外，JMeter可以對應用程序作功能迴歸測試，經過建立帶有斷言的腳原本驗證你的程序是否返回了指望的結果。

爲了最大限度的靈活性，JMeter容許使用正則表達式建立斷言。

 

（2）LoadRunner

LoadRunner是惠普旗下一款自動負載測試工具，它能預測系統行爲，優化性能。LoadRunner強調的是整個企業的系統，它經過模擬實際用戶的操做行爲和實行實時性能監測，來幫助更快的確認和查找問題。此外，LoadRunner 能支持最寬範的協議和技術，量身定作地提供解決方案。

 

（3）其餘測試工具

• Siege是一款開源的壓力測試工具，能夠根據配置對一個WEB站點進行多用戶的併發訪問，

記錄每一個用戶全部請求過程的相應時間，並在必定數量的併發訪問下重複進行。

• TCPCopy是一種請求複製（全部基於tcp的packets）工具，能夠把在線請求導入到測試系統中去。

TCPCopy的特色是能夠拷貝線上真實流量，模擬用戶數據。

 

2.性能測試工具的橫向對比

這裏對比主流的 JMeter和LoadRunner，通常來講，除了自研測試工具的公司，互聯網公司使用JMeter做爲測試工具的較多。

	JMeter	LoadRunner
開發語言	純Java開發	使用C語言開發
支持應用	對Java爲主的系統支持較好	支持比較全面
是否收費	開源免費	商業軟件
學習成本	應用簡單，上手快，Java自定義測試計劃	功能複雜，學習成本高
協議支持	支持常見的HTTP/FTP/SMP等	支持較全面
自定義測試	支持使用Java編寫Sample	使用完善的組件進行定製化測試
組件功能	Thread Group, Samplers, Listeners, Pre & Post processors	一套完整的測試組件，好比VU Generator, Controller, Analyzer, Load generator, Load calculator 和protocol advisor.

 

 

如何監控系統資源，定位性能瓶頸

壓力測試能夠暴露系統性能問題，如高併發下訪問緩慢，服務宕機等，可是經過壓測不能具體到哪裏存在瓶頸，必需要在壓測同時配合適當的資源監控，幫助咱們定位問題。

1.配置合理的資源監控方案

（1）使用nmon監控系統性能

 

nmon是Linux上普遍使用的監控與分析工具，相對於其它一些系統資源監控工具來講，nmon所記錄的信息是比較全面的，它能在系統運行過程當中實時地捕捉系統資源的使用狀況，而且能輸出結果到文件中，而後經過nmon_analyzer工具產生數據文件與圖形化結果。

 

nmon所記錄的數據包含如下一些方面：

　　● cpu佔用率

　　● 內存使用狀況

　　● 磁盤I/O速度、傳輸和讀寫比率

　　● 文件系統的使用率

　　● 網絡I/O速度、傳輸和讀寫比率、錯誤統計率與傳輸包的大小

　　● 消耗資源最多的進程

　　● 計算機詳細信息和資源

　　● 頁面空間和頁面I/O速度

　　● 用戶自定義的磁盤組

　　● 網絡文件系統

 

（2）使用rpc.rstatd監控系統性能

 

rpc.rstatd一般配合LoadRunner一塊兒使用，注意與系統服務rpc.statd進行區分。

rstatd後臺程序能夠從系統核心中獲取系統性能統計的相關信息，將結果返回給調用程序。

進行壓力測試時，LoadRunner客戶端經過給服務器上的 rstatd 後臺程序發送請求，來收集應用或數據庫服務器的性能數據。

 

（3）針對不一樣的服務合理配置資源監控方案

以Java服務爲例，在壓測同時能夠對JVM虛擬機進行性能監控，這方面經常使用的有Jvisualvm、jps、jstack等。

下面是Jvisualvm的應用界面，能夠監控本地和遠程的JVM實例運行狀態。

 

針對測試報告進行鍼對性優化

在壓力測試發現問題之後，就要進行有針對性的優化。對於不一樣的系統，這個過程的策略並非肯定的，可是大概能夠劃分爲如下幾個步驟： 

1.定位性能瓶頸，找出系統存在的問題 

不一樣系統的特色不一樣，在性能瓶頸上也有不一樣的表現，通常來講，下面的幾個方面一般存在比較大的優化空間：

 

（1）磁盤I/O及文件操做

因爲磁盤I/O讀寫的速度要比內存慢不少，程序在運行過程當中，若是須要等待磁盤I/O完成，那麼低效的I/O操做會拖累整個系統。

 

（2）網絡操做

對網絡數據進行讀寫的狀況與磁盤I/O相似。因爲網絡環境的不肯定性，尤爲是對互聯網上數據的讀寫，網絡操做的速度可能比本地磁盤I/O更慢。

 

（3）CPU

對計算資源要求較高的應用，因爲其長時間、不間斷地大量佔用CPU資源，那麼對CPU的爭奪將致使性能問題。如科學計算、3D渲染等對CPU需求旺盛的應用。

 

（4）高併發下的上下文切換及鎖競爭等

高併發程序若是沒有作好優化，存在大量的鎖競爭，激烈得鎖競爭將會明顯增長線程上下文切換的開銷，對性能形成極大的影響

 

（5）數據庫

大部分應用程序都離不開數據庫，而海量數據的讀寫操做多是至關費時的。而應用程序可能須要等待數據庫操做完成或者返回請求的結果集，那麼緩慢的同步操做將成爲系統瓶頸。

2.肯定調整目標，提出解決方案

找到系統的性能問題之後，須要做出對應的解決方案。

 

典型的影響性能的問題，好比：

（1）系統對高併發的場景響應不足，如數據庫鏈接池太低，服務器鏈接數超過上限，數據庫鎖控制考慮不足等

（2）內存泄露，如在長時間運行下，內存沒有正常釋放，發生宕機等

（3）數據庫優化不足，業務日益增加，關聯表衆多，SQL不夠優化等

 

定位到上述問題，接下來就是提出合理的調整目標，

好比服務器資源有限，能夠經過配置更多的機器，服務上雲等進行優化；

若是對高併發支持很差，就能夠在代碼層面優化，提升併發支持；

數據庫性能問題，如慢查詢等問題，就能夠進行 SQL語句優化等。

3.實施解決方案，進行迭代開發

上一步的分析給出了一個初步的性能優化方案，接下來就是針對方案中提到的內容進行鍼對性的改進。

這個過程能夠應用敏捷的思想進行迭代，在開發完成後，爲了對比優化結果，能夠對調優後的系統進行小範圍測試。

4.進行基準測試並分析調優結果

數聽說明一切，性能優化的結果不能簡單的經過 「感受系統變快了」來衡量，最好是經過對比優化先後的測試結果，用圖表的方式直觀的把優化結果展現出來。基準測試是指經過設計科學的測試工具和方式方法，實現對一類測試對象的某項性能指標進行定量的和可對比的測試。對比測試結果，結合容量評估等工做，可讓系統發揮最大的效用。

 

一個階段的優化工做完成之後，最好是總結反思一下，好比本次優化是否達到了目標？系統的總體性能是否獲得了改善？用戶體驗是否獲得了提高？以及如何在接下來的開發工做中作的更好。

 

使用JMeter進行壓力測試實踐

JMeter是目前流行的測試工具，這裏簡單的介紹一下相關的應用。

1.JMeter安裝與使用

Linux下可直接下載安裝，MAC系統進入http://jmeter.apache.org/download_jmeter.cgi，下載apache-jmeter-3.1.tgz。

下載完畢後解壓，獲得安裝包，進入到進入解壓目錄/bin/，單擊jmeter圖案，便可啓動JMeter。 

2.基本組件簡介

應用JMeter須要熟悉一些基本的概念，這是編輯測試計劃的界面：

 

 

(1)Threads 線程組

這個組件主要用來控制Jmeter併發時產生線程的數量，在它的下一級菜單下只有一個組件（線程組），能夠這麼理解每一個線程就是一個虛擬的用戶。全部的其餘類型組件必須是（線程組）節點的子節點。

 

(2)ConfigElement 配置單元

和Sample組件一塊兒工做，主要用來配置Sample如何來發起請求訪問服務器，這個東西的主要特色是能夠把一些Sample的共同配置放在一個元素裏面方便管理，配置單元是有做用域的。做用域和樹的那個關係同樣越是上級節點的做用域越大，越是接近葉子節點的

做用域就越小，能夠複寫上級做用域的配置。

 

(3)Timer 定時器

這個主要是用來調節（線程組），控制線程每次運行測試邏輯（好比說：發出請求）的時間間隔。固然這個下面還有不少類型的定時器，他們主要功能就是調節時間間隔，但個個組件之間的策略有很大不一樣。

 

(4)Pre Processors 前置處理器 / Post Processors 後置處理器

相似一個HOOK，在測試執行以前和執行以後執行一些腳本的邏輯。該組件我尚未具體使用過，但大體功能就是這樣，非重點組件。

 

(5)Assert 斷言

是指對於Sample完成了請求發送以後，判斷一下返回的結果是否知足指望。

 

(6)Listener 監聽器

這個組件不一樣於平時在Web編程的那種監聽器，他是伴隨着Jemeter測試的運行而從中抓取運行期間的數據的一個組件，常用的是聚合報告組件，從裏面能夠統計到測試的TPS，響應時間等關鍵測試數據。

3.進行第一個測試

（1）設置線程組參數

首先在TestPlan下面添加一個ThreadGroup組件，設置線程組組件各項參數。

 

 

線程數：最大測試時使用的線程數。

Ramp-Up Period : Jmeter達到指定最大線程數的時間。

循環次數 : 若是是Forever，線程組中的線程將不間斷的連續測試系統，固然也能夠設置每一個線程測試的次數，當完成了規定次數後，該線程將自動退出線程組。

 

（2）添加Sampler信息

保存線程組後，接着在線程組下面添加Sample組件，咱們添加一個HTTP Request組件，

設置屬性以下圖:

 

Sampler表示客戶端發送某種格式或者規範的請求到服務端，因此有各類各樣的Sampler，如FTP/JDBC等。

這裏我添加了一個針對百度百科首頁的訪問請求，端口爲80，使用http協議。

 

（3）添加聚合報告的監聽器組件

添加一個Aggregate Report的listener的監聽器組件。

Aggregate Report 是 JMeter 經常使用的一個 Listener，中文被翻譯爲「聚合報告」。

 

（4）啓動運行

點擊RUN運行測試便可。而後能夠看到本次測試的Aggregate Report。

 

4.Jmeter中的幾個重要測試指標釋義

能夠看到，上面的聚合報告中有不少維度的信息，簡單介紹幾個比較重要的指標。

 

Label	每一個 JMeter 的 element（例如 HTTP Request）都有一個 Name 屬性，這裏顯示的就是 Name 屬性的值
#Samples	表示你此次測試中一共發出了多少個請求，若是模擬10個用戶，每一個用戶迭代10次，那麼這裏顯示100
Average	平均響應時間——默認狀況下是單個 Request 的平均響應時間，當使用了 Transaction Controller 時，也能夠以Transaction 爲單位顯示平均響應時間
Median	中位數，也就是 50％ 用戶的響應時間
90% Line	90％ 用戶的響應時間，其餘的幾個能夠類推
Min	最小響應時間
Max	最大響應時間
Error%	本次測試中出現錯誤的請求的數量/請求的總數
Throughput	吞吐量——默認狀況下表示每秒完成的請求數（Request per Second）
Received / Sent KB/Sec	每秒從服務器端接收到／發送的數據量