名詞解釋
性能測試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
詳情請見：
http://com.baidu.com/twiki/bin/view/Main/CerBerus
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性能測試時，很有用。