1、简介
wrk 是一款针对 Http 协议的基准测试工具,它能够在单机多核 CPU 的条件下,使用系统自带的高性能 I/O 机制,如 epoll,kqueue 等,通过多线程和事件模式,对目标机器产生大量的负载。
PS: 其实,wrk 是复用了 redis 的 ae 异步事件驱动框架,准确来说 ae 事件驱动框架并不是 redis 发明的, 它来至于 Tcl 的解释器 jim, 这个小巧高效的框架, 因为被 redis 采用而被大家所熟知。
2、优势、劣势
优势:
劣势:
wrk 目前仅支持单机压测
,后续也不太可能支持多机器对目标机压测,因为它本身的定位,并不是用来取代 JMeter, LoadRunner 等专业的测试工具,wrk 提供的功能,对我们后端开发人员来说,应付日常接口性能验证还是比较友好的。
3、安装
mac安装
4、使用
wrk -t12 -c400 -d30s http://www.baidu.com
结果
结果说明:
参数说明:
5、lua
在wrk中是通过自定义相应的lua方法
达到改变wrk行为
的目的,wrk的执行分为三个阶段:启动阶段(setup)
、运行阶段(running)
、结束阶段(done)
,每个测试线程,都拥有独立的lua 运行环境。
启动阶段
运行阶段
结束阶段
https://www.jianshu.com/p/5bc2b48bd695
demo:
test.lua
local counter = 1
local threads = {}
-- 启动阶段 (每个线程执行一次)
function setup(thread)
thread:set("id", counter)
table.insert(threads, thread)
counter = counter + 1
end
-- 运行阶段 (该方法init每个线程执行一次)
function init(args)
requests = 0
responses = 0
errnum = 0
local msg = "thread %d created"
print(msg:format(id))
end
-- 这个三个方法每个请求都会调用一次
function delay()
-- 990ms
return 990
end
-- 请求
function request()
requests = requests + 1
uid = math.random(1, 10000000)
path = "/test?test=" .. uid
return wrk.format(nil, path)
end
-- 返回
function response(status, headers, body)
if status ~= 200 then
errnum = errnum + 1
end
responses = responses + 1
end
-- 结束阶段
function done(summary, latency, requests)
for index, thread in ipairs(threads) do
local id = thread:get("id")
local requests = thread:get("requests")
local responses = thread:get("responses")
local errnum = thread:get("errnum")
local msg = "thread %d made %d requests and got %d responses and errnum:%d"
print(msg:format(id, requests, responses,errnum))
end
end
测试
wrk -t4 -c 400 -d 30s -s test.lua http://127.0.0.1
Running 30s test @ http://127.0.0.1
4 threads and 400 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 26.28ms 150.91ms 1.20s 98.36%
Req/Sec 174.68 174.08 535.00 75.38%
7095 requests in 30.09s, 1.05MB read
Socket errors: connect 151, read 86, write 0, timeout 136
Requests/sec: 235.79
Transfer/sec: 35.69KB
https://cloud.tencent.com/developer/article/1777690
6、与JMeter的区别
7、多少QPS才算高并发
(1)首先是无状态前端机器不足以承载请求流量,需要进行水平扩展,一般QPS是千级
。
(2)然后是关系型数据库无法承载读取或写入峰值
,需要数据库横向扩展
或引入nosql
,一般是千到万级
。
(3)之后是单机nosql无法承载,需要nosql横向扩展
,一般是十万到百万QPS
。
(4)最后是难以单纯横向扩展nosql,比如微博就引入多级缓存架构
,这种架构一般可以应对百万到千万
对nosql的访问QPS。 当然面向用户的接口请求一般到不了这个量级,QPS递增大多是由于读放大造成的压力,单也属于高并发架构考虑的范畴。
具体多少QPS跟业务强相关,只读接口读缓存
,将压力给到缓存单机3000+没问题
,写请求1000+
也正常,也复杂些可能也就几百+QPS
。
所以QPS和业务场景和设计相关性很大,比如可以通过浏览器本地缓存,用缓存做热点数据查询,写事务MQ异步处理等方式提升QPS。