背景
随着应用OSS的用户越来越多，很多人都想知道，OSS能提供的性能是什么。
这里的性能主要指的是每秒能处理的请求次数（QPS），以及每次请求处理的时延（Latency）。
该如何对OSS进行性能测试，这是一个很广泛的话题。
从用户的角度来看，OSS能提供的性能和请求的压力类型（同步，异步），请求Object的大小，请求的方式（读，写）都是有关系的。
从OSS服务端的角度，对外提供的性能和自身的机器型号（磁盘，网卡，内存，CPU），机器数量，整个集群的网络，负载都有关系。
使用范围
本文讲的是：
使用ab和wrk工具
- 在单机的环境下
- 向OSS的Endpoint发出请求
- 然后在客户端统计请求的QPS，请求的Latency。
工具介绍
ab
ab，全称是apache benchmark，是apache官方推出的工具。
该工具是用来测试Apache服务器的性能的。查看安装的apache的服务器能提供的服务能力，每秒可以处理多少次请求。
获取和安装
http://httpd.apache.org/docs/2.4/install.html
http://httpd.apache.org/docs/2.4/programs/ab.html
在编译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
- 测试过程
- 模拟小文件（5KB），高并发（50个线程）的写，运行5分钟
./ab -c 50 -t 300 -T 'text/plain' -u 5KB.txt http://oss-cn-hangzhou-test.aliyuncs.com/public/5KB.txt- 模拟小文件（5KB），高并发（50个线程）的读，运行5分钟
./ab -c 50 -t 300 http://oss-cn-hangzhou-test.aliyuncs.com/public/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 http://oss-cn-hangzhou-test.aliyuncs.com/public/5KB.txt
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 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
下载
执行命令:
$./wrk -c 50 -d 60 -t 5 http://oss-cn-hangzhou-test.aliyuncs.com/public/5KB.txt
表示向Endpoint发起GET请求，有5个线程，开启的连接有50个，运行60秒
注意这里的5KB.txt是需要存在的。测试结果:
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左右
总结
以上就是用开源的benchmark工具来从客户端的角度来衡量所能获取的QPS以及Latency。
但从客户端看到的性能会受到各种因素的影响，例如请求的方式，本机的资源（CPU，内存，网络），OSS的网络状况，OSS的负载等都会影响客户端看到的性能指标。
需要根据实际情况来查看性能瓶颈是来自于OSS还是来自于本机。
