目錄

名詞解釋

附

起壓工具

其他工具

效能測試FAQ

1. 效能測試的基本過程是什麼？

2. 如何準備測試環境？

3. 準備環境時，由於條件限制，機器系統硬體環境可能不同，機器硬體的cpu主頻，單雙核，硬碟轉速等對效能測試的影響情況如何，在準備測試中哪些因素可以較少考慮或者忽略？

4. 我們的機器本身會啟很多自動服務，其對效能的影響如何？

5. 測試過程中應該收集哪些資料？應該怎麼獲得？

6. 是否開啟cache，對效能測試有什麼影響？

7. 系統快取對效能測試有什麼影響，如何減少這種影響？

8. 如何選擇壓力工具？

9. 如何準備壓力詞表？

10. 壓力測試中，每組壓力執行多長時間合適？

11. 如何配置壓力？

12. 什麼是極限，怎麼知道已經到了極限？

13. vmstat 和 iostat 各項指標有什麼含義，怎麼用於分析？

14. 如何評估測試結果的正確性和合理性？

15. 網絡卡頻寬對壓力測試有什麼影響？

16. timewait 對服務極限壓力有何影響？

效能測試Tips (來自於大家的經驗收集)

1．測試前需要對測試結果進行預估

2. 測試過程中對測試環境，以及測試資料的記錄應該清晰統一。

3. 當對要測試的模組或者系統不熟悉時，應該提前做一些背景瞭解。

效能測試例項

附

效能測試常用工具簡介

起壓工具

資料採集工具

其他工具

相關文章

名詞解釋

使用者態資料：指從模組角度看到的反映系統性能的一些資料，如平均響應時間等。通常使用使用者態資料直接衡量模組和叢集的極限壓力。

系統態資料：指從系統角度看到反映系統性能的一些資料，比如cpu佔用率等。通常系統態資料來衡量系統負載和分析效能瓶頸，不直接用它來作為評估極限效能的標準。

效能測試FAQ

1. 效能測試的基本過程是什麼？

效能測試，大概分為以下過程：

l  測試計劃制定

確定性能測試的目標，採用的測試方法等。

通常效能測試可能有以下目標：

                        i.              對架構升級，或者效能升級進行評估測試，摸清極限壓力。通常這類測試更加關注使用者態的資料。

                      ii.              效能升級前或升級進行中的調研，旨在摸清模組效能方面存在的問題，尋找優化的的切入點。通常這類測試更加關注系統態的資料。

當然這裡提到的是兩個主要的方向，實際的效能測試，可能有特性化的需求，比如測試某個模組的 併發性。

對於測試方法，確定時大概需要考慮以下幾個方面：

1.       測試目標

效能測試的目標決定了效能測試的方方面面，比如是測單機，單模組的極限效能，還是測一個子系統的極限效能。這決定了採用測試方法，以及機器的準備，一個子系統的測試，理想情況，需要按照線上的部署方式，完成各各模組在測試環境的部署。而單機，單模組的測試，則對環境要求沒有那麼嚴格，但需要考慮測試機器CPU，記憶體，以及機器上執行的其他程式，對測試的影響。

2.       環境設計

包括以下幾個方面：

1.       需要幾臺機器，各各模組如何部署。

2.       對機器的硬體(CPU, 記憶體)，系統(核心，其他軟體)要求。

3.       使用的測試方法和準備收集的資料。

關於測試方法，以及資料採集，針對不同的效能測試需求，都有不同的方法。後面會有針對性的說明。

l  測試實施

按照測試計劃完成效能測試。並收集重要的資料以供後續的資料分析。

l  測試資料分析

對測試過程得到的資料進行分析。得到 模組 或者 系統 在效能方面的指標，或者發現 模組 或 系統 在效能方面的問題。

l  完成測試報告

通過測試報告，可以清晰的說明效能測試的情況，可用作評審，以及其他相關測試工作的參考。

2. 如何準備測試環境？

       根據測試型別的不同，測試環境的準備也會有一些不同。

一般的極限壓力測試，要求測試環境與線上環境儘可能一樣，包括軟硬體環境。硬體環境主要指機型（dell還是hp）與配置（記憶體，cpu）應該相當；軟體環境包括 基礎庫，線上與該模組一起部署在一臺機器的其他模組，以及這些模組應有的壓力。

       進行單模組的效能測試一般則要求環境裡面影響因素極可能少，一般只執行被測試程式。

       進行對比測試，一般是相同硬體，不同程式實現的測試，或者相同程式，不同硬體的測試。則要求兩個對比環境中，除了需要對比的因素，其他條件儘可能相同，詞表和測試方法，也應該保持一致。

3. 準備環境時，由於條件限制，機器系統硬體環境可能不同，機器硬體的cpu主頻，單雙核，硬碟轉速等對效能測試的影響情況如何，在準備測試中哪些因素可以較少考慮或者忽略？

   機器環境中常見的一些因素以及影響情況如下：

Ø    CPU主頻及單雙核

CPU主頻及單雙核主要影響CPU密集型的業務的效能。同等壓力下，較高主頻的CPU一般處理請求的時間短，而較低主頻的CPU處理請求的時間長。

目前機器的主流CPU 雙路雙核和雙路四核 根據主頻可以分為Xeon3.0G  2.8G

Ø  記憶體大小

記憶體大小對業務效能影響較為明顯，大記憶體的機器，其系統可用cache較大，可載入到記憶體中的資料較多，可以明顯減少系統I/O，大大縮短響應時間。

目前單條容量2G的記憶體比較多，機器總記憶體8G和16G居多。測試前可以通過free命令檢視

Ø  磁碟轉數

我們現有磁碟的轉速基本都是10k/min，15k/min的磁碟較少，除非特殊情況，一般可以忽略該配置。

Ø  磁碟容量

常見的磁碟容量有73GB、146GB、300GB。較大的磁碟容量單碟片資料密度較高，磁頭尋道時間較短，磁碟效能較好。

Ø  磁碟介面

常見磁碟介面有SCSI、SATA、SAS，其中以SAS介面的磁碟效能最好。

Ø  預讀RA值

系統預讀，對於隨即讀為主的業務，由於讀取的資料儲存較為分散，建議調小該預讀值；相反以順序讀為主的業務，應該調大該值。

在隨機度為主的業務中，調小該值可以明顯看到iostat統計到的r/s值明顯降低，vmstat統計到的bi值同時降低。

Ø  RAID級別

現有機器的RAID級別只有兩種：RAID1+0和RAID5，RAID1+0的I/O效能好於RAID5

Ø  RAID讀寫比率

只有HP的RAID卡有讀寫比率的概念，Dell的RAID卡沒有這個概念。

Ø  Swap分割槽

Swap分割槽對系統性能影響較小，可以忽略。大小可以通過free檢視

Ø  磁碟碎片

       對於ext2檔案系統來說，磁碟塊的分配會根據一定的演算法儘量使得同一目錄下的檔案放在同一塊組，即儘量保持連續性。多執行緒的隨機讀寫會導致檔案在磁碟上的存放連續性較低。磁碟連續性越低，導致磁碟尋道頻繁，降低了系統的I/O效能。磁碟連續性可以通過plblk工具檢視。

4. 我們的機器本身會啟很多自動服務，其對效能的影響如何？

機器上啟動的服務如下面所列：

hwinfo: 硬體資訊外掛 每天一次 ，cpu計算型服務

update: 自更新外掛 觸發式    （外掛網路下載）

system-mon: 系統資訊外掛（包括vmstat和iostat） 每10分鐘一次 ，cpu計算型服務、由於會寫日誌，所以會有少量IO。

mysql-mon: 資料庫監控外掛（只有幾個產品線部署了） 每10分鐘一次 ，讀取記憶體中的一些資訊，有一些寫日誌的操作，可能會有少量IO。

sys_agent.sh:  sa的獲取資產資訊的程式，啟動時執行一下。

磁碟監控:  大概每半小時上線上伺服器df一下（其它伺服器上）

core監控:  大概每半天，上線上find core一下（會制定home下的工作目錄，其它伺服器上）

服務監控: 每20秒會向模組發出一次監控請求（其它伺服器上）

5. 測試過程中應該收集哪些資料？應該怎麼獲得？

一般而言，需要收集的資料分為兩類：使用者態資料和系統態資料。使用者態資料直接衡量模組和叢集的極限壓力；而系統態資料來衡量系統負載和分析效能瓶頸。

使用者態關心的資料包括：

A.     請求平均響應時間

B.      最大響應時間

C.      Overflow數或超時數

D.     N倍平均響應時間請求比例

其中， n倍平均響應時間比例是指在所有請求中響應時間超過n倍平均響應時間的請求比例有多大，這個引數比最大響應時間能更好的描述響應時間的分佈狀態，因為最大響應時間受某一次特殊狀態的影響很大。n的取值可以按照所測試系統的不同選擇3倍、5倍或者更多。請求超時數也是一個關鍵的指標，一般認為出現超時情況，即認為效能達到瓶頸，不能穩定服務。

一般而言，使用者態的資料都可以從程式的輸出log中得到。一些壓力工具的日誌也可以作為參考。

系統態資料

系統態資料主要用來衡量系統負載和分析效能瓶頸，不直接用它來作為評估極限效能的標準，一般我們比較關心的常見系統態指標分為CPU相關，I/O相關，網路相關等。

       CPU相關： us sys id wa等

       I/O相關：  bi bo r/s w/s await等

       網路相關： rxpackets txpackets rxbytes txbytes等。

系統態引數一般可以通過linux自帶的工具可以獲取。如cpu、io相關引數可以通過vmstat、iostat命令觀察到，其中iostat的util%表示io請求佇列非空的時間的比例，當達到100%時，系統的io就已經達到飽和。網路相關引數可以通過sar -n DEV 1 10命令獲取，後面兩個數字 1 表示統計的時間間隔，10表示統計次數。這幾個命令基本上可以滿足對系統態引數的觀察，具體使用方法參考man手冊（具體含義請參考 條目13）。

6. 是否開啟cache，對效能測試有什麼影響？

我們目前的系統中通常都有cache模組。在後端是IO型的服務，前端有cache的模式下，前端cache 開啟與否，命中率都會對後端IO型服務得到的測試指標有影響。以 BS 的測試為例，AS 通常都會對BS 的結果有一定的cache，在測試中會發現，AS cache開啟的情況的到BS的極限壓力會低於開啟AS Cache時得到的BS極限壓力。造成這種差異的原因主要為：as端cache的引入，使落到bs的請求更為的隨機，而對系統cache的利用更加低效，從而極限壓力也受到影響。

所以，如果僅僅是想針對bs進行基礎效能迴歸，或者bs進行效能調優過程中的測試，可以暫時不考慮as cache帶來的影響，而在進行bs 極限效能的測試，則必須考慮as cache的影響，因為極限效能的指標將直接作為線上服務部署的依據。

7. 系統快取對效能測試有什麼影響，如何減少這種影響？

   系統快取指作業系統使用一部分未分配記憶體用來對IO操作進行快取，從而優化IO。作業系統的這種行為對 資料量較小，訪問存在一定的連續性 的IO型服務有非常大的影響，可能導致效能測試的資料不準確，通常是測試結果優於實際結果。為了減少這種影響，需要注意：

       1. 詞表的選取應該有一定的數量，現有的壓力工具通常都會迴圈壓力，壓力詞表太小，在迴圈之後，基本上都重磁碟cache，效能遠遠高於正常需要磁碟IO的訪問。 而詞表的順序上，應該儘量模擬線上服務的訪問特性，過於連續，則得到的效能測試結果相對真實情況偏好；過於隨機，則得到的效能測試結果相對真實情況偏差。

       2. 對資料量較小的服務，相同的資料壓過多次後，也受磁碟cache的影響比較大，每次新起壓力應對磁碟cache進行清理。 清理的方法有：重啟系統， 拷貝大檔案，使用系統組提供的工具。

8. 如何選擇壓力工具？

對於直接對web server起壓力進行的測試，目前公司常用的壓力工具有myab, myabc, http_load 等。myab在baidu的qa部門被廣泛使用，但在測試過程中發現myab在壓力較高的情況下（500次每秒以上），不能穩定地輸出壓力。http_load在baidu也有所應用，它能輸出的壓力最高有1000次每秒，且相對很穩定。而http_load是將要傳送的http請求全部載入到記憶體後，隨機選擇請求進行傳送，而myab是按照詞表檔案順序依次發生請求。因此myab用來測cache命中率較準，而http_load的cache命中率相對會低一些，因為隨機發送和線上的實際情況並不一樣。

另外，對於直接發向web server 的效能測試，需要注意配置請求頭的接受壓縮——是否進行壓縮對前端機器的效能影響比較大。

對於直接對某個模組起壓力，可以使用 CerBerus，該工具為模組級的壓力工具，可以模擬模組之間的網路請求，支援併發，大壓力和靈活的構造請求資料。而stl 提供的pfmtest 也可以對模組進行壓力測試，它支援比較靈活的壓力控制，但需要根據不同的模組實現介面函式。

9. 如何準備壓力詞表？

壓力詞表一般而言，希望儘可能模擬線上使用者請求的訪問特性，所以通常從線上日誌(Web Server) 獲得。針對的具體的不同的測試，也可以構造一些壓力詞表。例如comdb的測試中，由於資料量大，訪問離散，測試即採用隨機資料ID進行。

10. 壓力測試中，每組壓力執行多長時間合適？

       每組壓力執行時間並沒有嚴格的規定，通常是隻要足以得到 穩定 的效能表現記錄即可。也不宜進行的太久，否則整個測試時間較長，影響效率。

       以BS的測試為例，一般習慣，進行30分鐘左右的壓力測試，看系統是否穩定，然後統計穩定後15分鐘的資料。

11. 如何配置壓力？

       壓力的配置可以參考該模組歷史的測試情況，新模組可以根據設計的效能指標，或者其他類似模組的效能情況。 對於升壓測試而言，一開始壓力可以不用太大，逐步遞增，最後獲得模組或者系統能能夠承受的最大壓力。

12. 什麼是極限，怎麼知道已經到了極限？

STL對極限壓力有一個抽象的標準：正常線上服務不受影響。意義為，超過這個壓力，服務就開始出現一些異常，比如出現一定數量的 超時，拒絕連線等。

13. vmstat 和 iostat 各項指標有什麼含義，怎麼用於分析？

vmstat 主要關注r b bi bo id wa幾個指標。

r  ready的程序數，也就是還沒有得到cpu的程序數，一旦得到cpu，那麼該程序馬上可以執行，如果該值過大（是否過大的標準是以你的程式會起幾個程序為準，沒有一個固定的值），那說明你的程式起的程序太多，建議一下降低程序個數，過多的程序切換是造成效能下降的原因之一。

b block的程序數，對於IO操作而言，主要是等待IO完成而被block的程序數，該值同樣沒有一個固定的標準值，相對於你的程式，這個值也不要太大。

bi 讀的速度，單位是KB/s，順序讀情況下hp在160MB/s左右，dell在200MB/s左右。隨機讀兩者相差不大。

bo 寫的速度，單位是KB/s，順序寫時，hp的機器在不同的raid卡cache讀寫比率下正常值是不同的（bi值不受raid卡cache讀寫比率的影響），read/write在25/75時最好，寫的速度可以到150~160MB/s；0/100時與25/75差別不大，也能到150~160左右；50/50速度在 100~120MB/s； 75/25 在100MB/s一下；100/0則在30~50MB/s之間。dell的機器一般都在180MB/s以上，最高可以到200MB/s以上。

id 是當前cpu處於idle的時間比例，這個也沒有一個固定的標準值，該值過高說明當前cpu沒有利用完全，還有繼續壓榨的能力

wa 當前cpu處於等待IO的時間比例，該值同樣沒有固定的標準值，如果這個值太高，比方說超過60%，那就要看看當前系統中是不是存在IO擁塞現象。

iostat主要關注r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await %util指標。

r/s 每秒讀請求次數，這個值通常會跟avgrq-sz一起觀察，avgrq-sz大則有可能r/s比較小

w/s 每秒寫請求次數，這個值通常會跟avgrq-sz一起觀察，avgrq-sz大則有可能w/s比較小

rkB/s 這個指標跟vmstat的bi值通常應該是很接近的

wkB/s 這個指標跟vmstat的bo值通常應該是很接近的

avgrq-sz 每個請求平均大小，單位是扇區數，一般在200~400之間算是正常和理想的狀態，如果這個值比較小，比方說只在100左右，說明太多的IO請求沒有被合併，或者大的IO請求被“打散”，在寫操作時，過多小的請求會造成磁碟磁頭的頻繁移動，降低IO效能。

avgqu-sz 平均請求佇列長度，這個值在正常的系統中不應超過113太多，如果在200左右，甚至上千那說明發生了IO擁塞，而系統還在向IO請求佇列中放請求（有一個例外是在執行sync,fsync操作時，該值到達最大值8192是正常的）

await 單位是毫秒，不應超過兩位數，幾百甚至上千都是不可接受的。

%util 儘可能的讓該值達到100%，否則說明IO能力沒有完全被利用。

14. 如何評估測試結果的正確性和合理性？

       在測試前，應該對測試結果有一個初步的估計，比如，效能（IO/CPU）應該是提升，還是降低，大概幅度會有多少。這樣當測試結果與預估偏差極遠時，很可能測試的過程或者方法是有問題的。

       如果是已有模組，可以參考改模組歷史的測試資料。看變化是否合理。

       如果是新模組，可以參考類似模組的效能測試資料。

       對資料本身，可以做一些邏輯上的相互驗證，比如：一般而言，idle應該隨壓力增加而降低，壓力升高，idle反而變高，有可能是大部分的請求都命中了系統cache，此時測試資料已經不準確。

15. 網絡卡頻寬對壓力測試有什麼影響？

對於壓力較大，或者資料流量較大的服務，比如空間圖片服務，可能會出現由於網絡卡跑滿，而壓力上不去的現象，此時機器負載較為正常，但壓力上不去。這對於測試環境，這是一個比較容易的現象。 比如 zjm機房的出口是百兆的，很容易壓滿。此時需要根據情況，將壓力分佈開。

當然也有一些模組，網絡卡本身就是瓶頸。瞭解網絡卡頻寬對壓力的影響，也有助於在分析時得出正確的判斷。

16. timewait 對服務極限壓力有何影響？

對於常見的CS關係的網路互動服務，當client 主動close，會進入timewait 狀態，但此時socket 仍然被佔用，無法回收，這一請情況可能會影響 短連結的併發壓力，因為大量的socket處於timewait 狀態會使client 控制代碼耗盡。 一般情況，短連線壓倒 400~500 就已經不穩定了。

緩解這一問題的，一般而言，有下面四種：

1. 邏輯實現上，儘量 server 端主動關閉。

2. 設定 SO_LINGER close.

    這是一種不太體面的做法， 因為它觸發的不是一個正常的結束。並且抹殺了TIME_WAIT 狀態存在的意義： 網路上可能還有資料在傳送，若此socket的替身出現，會收不到該收的包。

3. 開啟埠複用和快速回收

4. 修改系統timewait 時間

       上面三個是應用層的方法，這是一個需要修改系統kernel的方法。

效能測試Tips (來自於大家的經驗收集)

1．測試前需要對測試結果進行預估

進行測試前，最好能對測試的結果有一個大概的預估。這樣才測試結果出來後，可以有一個大概的對比參考，有助於對測試結果的驗證，可以較早的發現一些由於測試方不合理導致的問題。 預估可以根據 機器的特性； 如果是已經存在的模組，可以參考該模組已有的測試結果；如果是新模組，可以參考相似特性的模組的效能測試結果。

2. 測試過程中對測試環境，以及測試資料的記錄應該清晰統一。

重視測試資料的記錄，注意記錄測試環境、測試過程，可以採用統一的測試報

告模板；不然最後會搞得很混亂，事後分析資料時不清楚當時的情況了

3. 當對要測試的模組或者系統不熟悉時，應該提前做一些背景瞭解。

比如這個模組（或者某個系統， 比如MySQL）的效能特性，是IO型，還是CPU性，歷史的測試情況，測試方法。測試中應該注意的一些問題，可以向有相關經驗的工程師瞭解，能夠很大程度上幫助測試的順利進行。

效能測試例項

下面將以幾個效能測試的例項，說明效能測試的基本過程。

1. Image BS 效能升級測試

       需求場景：

       對Image BS模組進行效能優化升級，需要測試瞭解新BS的極限效能，並同時得出效能升級後的整個系統能夠承擔的流量。

首先，準備測試環境。 由於要測試BS模組的極限效能，希望BS的測試環境能夠儘可能的與線上環境類似，在這次測試中，主要考慮兩個問題：

       A. 機型&配置&軟體部署

         由於測試重點在於 bs的效能，所以測試環境的設計上，要求bs模組部署的環境與線上完全相同：

l  硬體方面包括：

機型(CPU)，記憶體，硬碟，Raid。

l  軟體方面包括：

BS的部署方式， 在本例中，假設一臺伺服器部署兩個BS，兩個DI。 應用層cache等配置與線上保持一致。

l  資料部署：

由於BS屬於IO型服務，受資料量的影響很大，因而測試環境的資料需要保證和線上資料量一致。本例兩個BS，DI 載入線上一層資料。

       B. 測試環境架構

       由於Image BS在線上執行在一個叢集之上，通常叢集的均衡冗餘策略，以及包含cache模組的存在，往往會影響資料的訪問情況，從而影響線下測試的準確性。 由於線下的資源優先，通常我們不可能線上下搭建與線上一樣的叢集，這就要求我們線上下搭建測試環境時，充分考慮叢集部署對測試帶來的影響。

       假設線上前端se機器（部署UI，AS）有8臺，BS/DI 機器有 6層*5列。最終的測試環境選擇 使用一臺機器部署UI，AS； 一臺機器部署BS/DI，做這樣的環境設計包含了兩個前提：

       1. AS 向BS 發請求的方式是 一個query每層都需要發檢索請求，也即BS的多層本身對BS的訪問特性並無影響。

       2. 單BS/DI 機器對DI的訪問特性帶來了較大的影響。包括兩方面：

              I．在多層的環境下，DI請求將根據資料分佈落到各層的DI上，單層的環境下，只會落到一個這一層的DI上。

              II．AS對DI的均衡策略為，根據di_id 在層內做hash均衡，然後每DI都可能有一些di的請求。在這種策略下，如果列數減少，意味著DI每次請求需要讀取的DI資料變多。

              綜合上面兩中情況，總得來說，每個DI每次需要讀取的DI個數變多。 再經過測試後，確認這一情況將會使線下的測試資料表現低於線上真實的表現（也即和我們保守估計的原則一致），並且影響程度在可接受的範圍內。認為可以接受。

       當然，在資源允許的情況下，最好還是能夠按照一層多列的架構進行測試。

       測試環境準備好，可以進行壓力測試，在這個環節，主要考慮下面幾個問題：

       A．測試詞表準備

              測試詞表通常反映了使用者的訪問特性，所以在極限測試的中，為了儘可能模擬線上的真實情況，儘量使用線上的日誌做測試詞表。根據壓力直接作用的模組不同，可以選取不同的模組的日誌。 這裡的測試詞表從UI日誌中取出，但直接作用到Web Server，因為UI與AS為長連線，一對一的關係，所以UI的日誌可以認為和AS的日誌反映的使用者訪問特性是一致的。

       B．壓力方法

              做極限效能測試，通常採用升壓測試的方法。 壓力的設定要考慮測試的目標模組，以及相關模組已知的極限壓力。在本次測試中，壓力的計算大概按照以下方式：

              假設 線上單個 bs 平均壓力為 20，那麼可以以20為基準， 按照as cache穿透率80%，以及一臺機器部署兩個bs，反推as 端的壓力應該為 200。那麼以200為基準，按照一定的步長，比如50，增壓，做升壓測試，直到得到系統的極限。

       C．摒除cache干擾

              在本測試中，cache的影響包含兩方面：

              1. AS端應用層cache的影響。

                     實際線上as cache的命中率平均85%，而as cache的存在會影響到落到bs的請求的訪問特性，從而影響bs端的極限壓力與真實可支援的極限壓力的差異，舉例而言，開啟cache的情況下，bs能夠支援的極限壓力也許是開啟as cache下測試結果的兩倍，因為as cache的存在使bs的訪問更加的隨機。

                     為了避免as cache的影響，在壓力詞表的選擇上，更加需要注意與線上日誌的一致程度，以保證as cache的命中率在一個比較正常的值。這是一個需要根據情況調整的過程，也許根據實際測試資料量的差異，還需要對as cache的配置作一定的更改。

              2. BS端系統cache的影響。

                     由於進行升壓測試，每一小段壓力進行完後，需要清除系統cache，或者新的詞表，以消除系統cache對測試的影響。 系統cache會使測試值遠遠優於真實值，很可能出現，壓力越高，反而系統反應出來的負載比低壓力還低的情況。

                     清除系統cache的方法有：拷貝大檔案，使用系統組提供的工具，重啟機器。

       D．注意資料記錄

              升壓測試的過程中需要做多輪壓力，中間需要記錄使用者態資料，以及系統態資料。在本測試中，使用者態資料主要從各各模組的日誌中體現，而系統態資料則有專門的工具獲得，詳見資料獲取工具介紹。 需要特別注意的時，由於升壓測試需要做多輪測試，多輪測試中產生的日誌等記錄資料需要妥善儲存，並相互區分，以免測試記錄相互覆蓋，混雜，增加後面做資料分析的困難。

       在測試過程完成後，即對測試資料進行分析。關於極限效能的得到，主要是關注使用者態資料，具體而言，在本測試中，即as 對bs讀超時的情況，as兩次讀失敗的情況，以及整個檢索反應出來的響應時間。得到BS的極限效能之後，由於我們在測試架構的設計上就考慮了對線上系統的模擬，因而，得到線上整個系統能夠承受的極限壓力也就相對較為容易獲得，比如在本測試中，對線上極限壓力的反推公式為： (bs極限壓力/0.2)*2*線上列數。

附

效能測試常用工具簡介

起壓工具

1.       myab系列

web server端的負載工具，多執行緒，根據詞表將壓力壓到apache 等web server。 其中myabc是 myab的增強版，可以通過xml詞表定義http請求頭中的各個欄位。

2.       CerBerus

Cerberus 是一款可模擬任意socket介面的模組級測試工具，可用於模組的效能壓力測試，也可用於構造邊界輸入、進行單元測試。

cerberus 根據xml描述的配置檔案構造請求資料包的二進位制格式，根據xml描述的資料檔案構造請求資料包的具體內容。

目標使用者 ：做單元測試的RD，做模組級測試、介面測試的QA

詳情請見：

3.       pmftest

pmftest 為 STL開發的壓力測試框架。socket介面，在框架上實現與待測試模組的互動介面後，即可對待測模組進行壓力測試。 壓力控制方面，支援：

l  控制在指定壓力

l  維持在指定超時時間

l  維持在指定平均響應時間

等多種壓力控制模式， 配合stable.sh 指令碼，可以一次性測試各種不同壓力情況下模組的效能，並統計此期間I/O CPU 等指標。 比較適合做極限壓力測試。

詳見pfmtest 說明文件 <pfmtest_info.doc>

資料採集工具

使用者態資料可以通過壓力工具日誌（例如pfmtest）日誌 或者 模組日誌進行。

系統態資料可以通過下面的一些工具：

1. sysinfo.pl

       綜合記錄 vmstat， iostat， mpstat， sar 等資料

2. vmstatstat.sh

記錄 vmstat 資訊

3. iostatstat.sh

記錄 iostat 資訊

其他工具

1. clearcache

清空系統快取的工具，在做受系統快取干擾大的IO效能測試時，很有用。