手機瀏覽器美圖笑話功能協議如下：

笑話協議：

pread.ie.sogou.com/infolist?count=20&lastindex=&b=%E7%AC%91%E8%AF%9D&mode=up&t=1445931068206&h=00000000-4379-c005-d445-0540728befc5&r=0000&v=4.1.0&hv=GT-I9500&pv=ANDROID4.2.2

美圖協議：

pread.ie.sogou.com/infolist?count=20&lastindex=&b=%E7%BE%8E%E5%A5%B3&mode=up&t=1445932269394&h=00000000-4379-c005-d445-0540728befc5&r=0000&v=4.1.0&hv=GT-I9500&pv=ANDROID4.2.2

測試過程中的難點和解決方案、思路歸納如下：

第一個難點：

由于是兩個請求，如何測試兩個請求同時存在情況下，服務端承受壓力情況？即如何考慮兩個請求的壓力配比？

這個測試場景涉及到兩個請求，為了模擬實際的使用環境，我們必須考慮到兩個請求的配比情況，一般設計配比有兩種情況：

一種情況是已經上線過這個功能，就像我這個版本，很久之前有過相關功能，只是這次做一個接口重構，所以有歷史數據可以參照。

我這邊主要是與產品要了笑話、美圖的UV數據，分別利用笑話美圖一段時間的UV和PV最大值，算出相應的比例，從而用這個數據設置為相應的打點比例。

另一種情況是從未上線過該內容，此時就需要依賴于一個小型灰度，灰度前要設置相應的請求pingback數據，從而能通過灰度數據計算出相應的比例。

第二個難點：

兩個請求一起打壓，如何設計腳本和添加到loadrunner中？

首先要在Run logic中設置好Init、Run、End，以美圖笑話為例具體設置截圖如下：

我們從圖中看出，笑話是美圖的259倍。

腳本展示如下：

美圖腳本：

meitu() 
{ 
int itera_num，rand_num，i; 
char StrTable[]="abcdefghijklmnopqrstuvwxyz1234567890____"; 
char i_data[36]=""; 
//itera_num=rand()%16; 
itera_num=36; 
for(i=0;i<=itera_num;i++) 
{ 
rand_num=rand()%39; 
strncat(i_data，StrTable+rand_num，1); 
} 
lr_save_string(i_data，"i_data_value"); 
web_reg_find("Text=index"， 
LAST ); 
lr_start_transaction("meitu"); 
web_url("xiaohuameitu"， 
"URL=http：
//10.134.73.228/infolist?count=20&lastindex=&b=%E7%BE%8E%E5%A5%B3&mode=up&t=1468726249
158&h={i_data_value}&r=0000&v=4.1.0&hv=GT-I9500&pv=ANDROID4.2.2"， 
"Resource=0"， 
"RecContentType=text/html"， 
"Referer="， 
"Snapshot=t15.inf"， 
"Mode=HTTP"， 
LAST); 
lr_end_transaction("meitu"， LR_AUTO); 
 
 
 
41 
                                       
return 0; 
}

腳本中需要注意的是：

1. i_data_value為一個隨機數，從而保證模擬到不同手機請求的結果，也能防止
   服務端的緩存機制。
2. h={i_data_value}，其中大括號的意思為參數化，一定要進行參數化，否則
   loadrunner不認為這是一個變量。

參數化的方法：//ke049m.cn/article/2016/2/4/23498.html

第三個難點：

承受最大打點數通過loadrunner檢測出來，如何估算出能夠承載的用戶數？

通過請教loadrunner專家小曹和我的leader立人，我了解到，估算這個承載用戶數 有多種方法，羅列如下（以案例的形式）：

1. 如何建設一個能承受500萬PV/每天的網站嗎？
   計算模型：
   每臺服務器每秒處理請求的數量=（（80%*總PV量）/（24小時*60分*60秒 *40%））/服務器數量
   其中關鍵的參數是80%、40%。表示一天中有80%的請求發生在40%的時間內。24 小時的40%是9.6小時，有80%的請求發生一天的9.6個小時當中（很適合互聯網的應 用）。
   （（80%*500萬）/（24小時*60分*60秒*40%））/1 = 115.7個請求/秒
2. 做過線上灰度，有一個請求數與用戶日活的比例，可以直接計算得出。
   本次笑話我算出最大承受打點數為200QPS，主要是利用第一種算法計算
   （200QPS*（24*40%）*3600）/80% = 864w
   鑒于線上的2臺機器做負載均衡，整體可以承受至少400QPS并保持性能穩定。
   根據以上經驗公式計算評估，400QPS可以支撐線上至少每天1600W用戶的訪問 量。由于該服務端同時還要支撐PC端的150w用戶，故在笑話美圖這邊實際支持 1400w用戶的訪問。

第四個難點：

測試中涉及到的是兩個服務器，一個中轉服務器，一個提供數據的服務器，如何同
時進行兩個服務端的壓力測試？

兩臺服務端直接進行壓力測試，根據響應結果，觀察是哪臺服務端成為瓶頸，當 然，有些時候是帶寬成為瓶頸。

第五個難點：

Loadrunner只有打點端服務器的數據監控，如何監控被測服務端的參數情況？

需要在被測服務端上安裝nmon_analyser_34a這個軟件。

這里有一個特別重要的命令：

./nmon_x86_rhel52 -f -c 1（執行次數） -s 1（時間間隔）的意思是形成分析表格，其 中第一個1是表示執行次數，第二個1是表示記錄數據間隔，如果是1，就是代表時間間隔為1s。

具體第一個1的數據是由總共執行的時間決定的，其中總共的時間是由loadrunner設置決定的，如果loadrunner總設定時間為10分鐘，那么如果命令中時間間隔設置為1s，那么執行次數應該就是600次。

將結果形成表格后，再通過命令將該表格導出即可。

第六個難點：

最后打點過程中的一些參數和選項配置的細節問題。

1. 壓力測試log存放位置：Temporary directory，截圖如下：
   
2. 設置打點參數的細節：
   
3. 線程托管一般選擇5-150Vusers，選擇是線程還是什么的位置如下：
   
4. 其他設置項：
   
   
   以上要注意這些設置項:
   Goal Type選擇的是
   
   
   Transaction選擇的是
   
   
   我這次測試中選擇的是xiaohua這個時間的事務數。

第一個總結：

壓力測試中到底是在關注什么？

1. CPU占用：比較穩定，不要超過70% 這個是平均到每一個核的 。
2. 內存占用：只要有空余內存即可，一般不會成為瓶頸，具體可以參考Linux內存管理知識 。
3. 平均響應時間：3、5、8原則。
4. 帶寬限制：如果帶寬成為限制，就要與產品溝通，在這種帶寬下給出極限值， 要采取限流措施。
5. 測試出最高的打壓值，之后，需要降低打壓值，一直到服務端的CPU占用、內 存占用、平均響應時間均為正常值情況。這時的指標值才是真正想要的值。

第二個總結：

如何寫出一個壓力測試的測試報告？應該公示哪些內容？

一個基本的壓力測試報告包含以下幾個部分：

1. 測試結論總結：主要包含能夠承受的訪問量，在這個訪問量下內存占用情況。
2. 具體測試結果：
   • CPU占用情況
   • 每秒事務數
   • Free內存
   • 平均事務響應時間

以上就是我整個壓力測試過程的一些總結，希望對一些同學有所幫助。

原文轉載自：