工具介紹
ab
ab，全稱是apache benchmark，是apache官方推出的工具。
該工具是用來測試Apache伺服器的效能的。檢視安裝的apache的伺服器能提供的服務能力，每秒可以處理多少次請求。

使用方法
由於OSS的bucket有許可權，而ab不支援OSS的簽名，需要將bucket變成public-read-write（公開讀寫）後進行測試。

假如模擬的是10個併發，請求100KB的Object
ab 執行時常用的配置項
-c 併發數
一次傳送的總請求數，預設是一次發一個請求。

-k 保持keep-alive
開啟keep-alive，在一個HTTP Session中請求多次。預設是關閉的。

-n 請求數
整個benchmark測試過程中需要傳送的請求次數。
預設是一次，預設情況下得到的效能引數沒有代表性。

-t 最大時間
benchmark測試最長時間. 預設沒有限制。

-u 上傳檔案
File containing data to PUT. Remember to also set -T.-T content-type

-T 設定上傳檔案的Content-Type
例如：application/x-www-form-urlencoded. Default is text/plain.

使用示例
測試OSS高併發的讀寫小檔案場景效能

前置條件

建立了一個public-read-write的bucket，假如叫public。下載了ab測試工具（開源）,linux執行環境。oss提供可服務的endpoint，假如叫oss-cn-hangzhou-test.aliyuncs.com，準備5KB的檔案，假如叫5KB.txt
測試過程

測試正常結束 ，Failed requests 為0，Requests per second即表示每秒中客戶端能獲取的處理能力。這不代表OSS服務端的處理能力。
注意事項
觀察測試工具ab所在機器，以及被測試的前端機的CPU，記憶體，網路等都不超過最高限度的75%。
測試中可能出現埠不足導致的測試失敗
需要調整核心引數以支援埠重用
例如：在Linux平臺下
1 sudo vim /etc/sysctl.conf
2 新增如下內容
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_fin_timeout = 30
kernel.printk = 7 4 1 7
3 執行sudo sysctl –p生效
結果分析
$./ab -c 50 -t 60 -n 300000 -k

Benchmarking oss-cn-hangzhou-test.aliyuncs.com (be patient)
Completed 30000 requests
Completed 60000 requests
Completed 90000 requests
Completed 120000 requests
Completed 150000 requests
Completed 180000 requests
Completed 210000 requests
Completed 240000 requests
Finished 250137 requests

Server Software: AliyunOSS
Server Hostname: oss-cn-hangzhou-test.aliyuncs.com
Server Port: 80

Document Path: /public/5KB.txt
Document Length: 5120 bytes

Concurrency Level: 50 併發數
Time taken for tests: 60.000 seconds 測試執行的時間
Complete requests: 250137 在執行期間完成的總請求次數
Failed requests: 0
Write errors: 0
Keep-Alive requests: 248492 keep-alive的請求次數
Total transferred: 1382504896 bytes
HTML transferred: 1280703929 bytes
Requests per second: 4168.94 [#/sec] (mean) 每秒的請求次數
Time per request: 11.993 [ms] (mean) 平均每次請求的時延
Time per request: 0.240 [ms] (mean, across all concurrent requests)
Transfer rate: 22501.67 [Kbytes/sec] received

Connection Times (ms) 請求連線的時間
min mean[+/-sd] median max
Connect: 0 0 0.0 0 1
Processing: 1 12 7.6 12 87
Waiting: 1 12 7.6 12 87
Total: 1 12 7.6 12 87

Percentage of the requests served within a certain time (ms) 請求的半分比及時延
50% 12
66% 15
75% 16
80% 17
90% 20
95% 23
98% 28
99% 37
100% 87 (longest request)

從測試結果，我們可以看到

在50個併發請求的情況下，請求60秒，平均每秒可以處理4168次（也就是說，客戶端在這種壓力下，看到的QPS為4168）
平均每次請求處理的Latency為12ms左右
由於開啟了keep-alive，連線幾乎不耗時間
99%的請求都在37ms內完成，最長的請求是87ms
wrk
wrk是一個用來做HTTP benchmark測試的工具。可以產生顯著的壓力。

使用方法
wrk可以配合lua指令碼來進行put操作

前置條件 > 建立了一個public-read-write的bucket，假如叫public。下載並安裝了wrk，linux執行環境。oss提供可服務的endpoint，假如叫oss-cn-hangzhou-test.aliyuncs.com，準備5KB的檔案，假如叫5KB.txt
上傳

這裡使用lua指令碼來做上傳的操作，lua指令碼put.lua的內容

counter = 0
request = function()
   mypath = "5KB.txt";
   local file = io.open(mypath, "r");
   assert(file);
   local body = file:read("*a");      -- 讀取所有內容
   file:close();
   wrk.method = "PUT"
   wrk.body = body
   path = "/public/test-" .. mypath .. "-" .. counter
   wrk.headers["X-Counter"] = counter
   counter = counter + 1
   return wrk.format(nil, path)
end
done = function(summary, latency, requests)
   io.write("------------------------------\n")
   for _, p in pairs({ 50, 60, 90, 95, 99, 99.999 }) do
      n = latency:percentile(p)
      io.write(string.format("%g%%, %d ms\n", p, n/1000.0))
   end
end

執行命令：

$./wrk -c 50 -d 60 -t 5 -s put.lua http://oss-cn-hangzhou-test.aliyuncs.com
表示向Endpoint發起PUT請求，請求的內容在put.lua中規定，有5個執行緒，開啟的連線有50個，執行60秒
測試結果：

Running input
-c 50 -d 60 -t 5 -s put.lua http://oss-cn-hangzhou-test.aliyuncs.com
Running 1m test @ http://oss-cn-hangzhou-test.aliyuncs.com, test input http://oss-cn-hangzhou-test.aliyuncs.com
5 threads and 50 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 16.23ms 9.49ms 159.48ms 96.45%
Req/Sec 635.38 98.38 0.91k 72.63%
189072 requests in 1.00m, 48.73MB read
Requests/sec: 3151.10

Transfer/sec: 831.58KB

50%, 14 ms
60%, 15 ms
90%, 20 ms
95%, 23 ms
99%, 64 ms
99.999%, 159 ms
結果分析：
從測試結果，我們可以看到

在5個併發請求的情況下，開啟50個連線，請求60秒，平均每秒可以處理3151次（也就是說，客戶端在這種壓力下，看到的QPS為3151）
平均每次請求處理的Latency為16ms左右
99%的請求都在64ms內完成，最長的請求是159ms
下載

執行命令:

Running input
-c 50 -d 60 -t 5 http://oss-cn-hangzhou-test.aliyuncs.com/public/5KB.txt
Running 1m test @ http://oss-cn-hangzhou-test.aliyuncs.com/public/5KB.txt, test input http://oss-cn-hangzhou-test.aliyuncs.com/public/5KB.txt
5 threads and 50 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 12.72ms 5.14ms 62.68ms 80.14%
Req/Sec 814.86 145.65 1.36k 69.43%
241990 requests in 1.00m, 1.25GB read
Requests/sec: 4033.14
Transfer/sec: 21.26MB
結果分析:
從測試結果，我們可以看到

在5個併發請求的情況下，開啟50個連線，請求60秒，平均每秒可以處理4033次（也就是說，客戶端在這種壓力下，看到的QPS為4033）
平均每次請求處理的Latency為12ms左右