用ab的post方式進行測試

一、Ab是常用的性能測試工具，因為它支持windows……

　　通常使用的命令是ab –c –n –k -r，分別表示：模擬終端數、發送包數、請求是否帶keepalive、忽略錯誤，默認都是以GET方式去請求的，也就是下面這種請求就可以用它測試：

　　這里不再說了。

二、本次主要說測試post方式的請求，也就是瀏覽器抓包看到的下面這種：

　　需要加上兩個參數-p和-T，先說-T是指請求的內容類型，比如上圖的'application/x-www-form-urlencoded'就寫-T "application/x-www-form-urlencoded"，-p后面跟的是要post的內容，以文本方式記錄即可，以我這次測試的例子為例：

　　-T參數就要寫成-T "multipart/form-data; boundary=----------------------------350e95503198"，但事實上boundary的內容是可以自己定義的，只要是給服務端識別出內容在哪里而已

　　比如我測試時就是寫-T "multipart/form-data; boundary=---1234ceshi"。

　　-p參數跟的是內容，只要把上圖抓包結果保存為txt即可，比如test.txt，但是注意如果你修改了boundary，那么這里記得也要修改，如

　　-----1234abcd

　　Content-Disposition: form-data; name="midn" 

　　7213c8d95ccc968d28d2d48b0c59a63e 

　　-----1234abcd—

注意最后那兩個破折號不能省略哦。

　　那文中例子的測試命令行就是：ab -n 1 -p test.txt -T "multipart/form-data; boundary=---1234abcd" http://172.22.31.45:8080/check_client_need_query.html
　　如果出現“ab: Could not stat POST data file : Partial results are valid but processing is incomplete”這是因為ab對post支持不好，尤其是在windows下。

三、通過面的例子可以看到這種方法是存在缺陷的，就是test.txt的內容是寫死的，如果實際測試需要post不同的數據（比如不同的midn）怎么做？有兩個方法：

　　1、通過另外的腳本或者程序在測試前修改這個文檔

　　2、換loadrunner。。。

 

ab的應用

   ab的命令參數比較多，我們經常使用的是-c和-n參數。

   ab -c 10 -n 100 http://www.myvick.cn/index.php　：同時處理100個請求並運行10次index.php

　　-c10表示並發用戶數為10

　　-n100表示請求總數為100

[root@vic html]# ab -c 10 -n 100 http://www.myvick.cn/index.php
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking www.myvick.cn (be patient).....done


Server Software:        nginx/1.13.6   #測試服務器的名字
Server Hostname:        www.myvick.cn  #請求的URL主機名
Server Port:            80             #web服務器監聽的端口

Document Path:          /index.php　　  #請求的URL中的根絕對路徑，通過該文件的后綴名，我們一般可以了解該請求的類型
Document Length:        799 bytes       #HTTP響應數據的正文長度

Concurrency Level:      10　　　　　　　　# 並發用戶數，這是我們設置的參數之一
Time taken for tests:   0.668 seconds   #所有這些請求被處理完成所花費的總時間 單位秒
Complete requests:      100 　　　　　　  # 總請求數量，這是我們設置的參數之一
Failed requests:        0　　　　　　　　  # 表示失敗的請求數量，這里的失敗是指請求在連接服務器、發送數據等環節發生異常，以及無響應后超時的情況
Write errors:           0
Total transferred:      96200 bytes　　　 #所有請求的響應數據長度總和。包括每個HTTP響應數據的頭信息和正文數據的長度
HTML transferred:       79900 bytes　　　　# 所有請求的響應數據中正文數據的總和，也就是減去了Total transferred中HTTP響應數據中的頭信息的長度
Requests per second:    149.71 [#/sec] (mean) #吞吐率，計算公式：Complete requests/Time taken for tests  總請求數/處理完成這些請求數所花費的時間
Time per request:       66.797 [ms] (mean)   # 用戶平均請求等待時間，計算公式：Time token for tests/（Complete requests/Concurrency Level）。處理完成所有請求數所花費的時間/（總請求數/並發用戶數）
Time per request:       6.680 [ms] (mean, across all concurrent requests) #服務器平均請求等待時間，計算公式：Time taken for tests/Complete requests，正好是吞吐率的倒數。也可以這么統計：Time per request/Concurrency Level
Transfer rate:          140.64 [Kbytes/sec] received  #表示這些請求在單位時間內從服務器獲取的數據長度，計算公式：Total trnasferred/ Time taken for tests，這個統計很好的說明服務器的處理能力達到極限時，其出口寬帶的需求量。

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        1    2   0.7      2       5
Processing:     2   26  81.3      3     615
Waiting:        1   26  81.3      3     615
Total:          3   28  81.3      6     618

Percentage of the requests served within a certain time (ms)
  50%      6
  66%      6
  75%      7
  80%      7
  90%     10
  95%    209
  98%    209
  99%    618
 100%    618 (longest request)

#Percentage of requests served within a certain time（ms）這部分數據用於描述每個請求處理時間的分布情況，比如以上測試，80%的請求處理時間都不超過7ms，這個處理時間是指前面的Time per request，即對於單個用戶而言，平均每個請求的處理時間

 

ab帶session的請求測試
如 ab -c 10 -n 100 -C JSESSIONID=A0ECB52A493B7287C767F0C9FE46F270 http://47.107.159.29/iqc-pc/task/listTaskRecordVO?current=1&size=20&taskName=&taskType=&voiceSource=