wrk学习

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。

https://my.oschina.net/u/1000241/blog/3065185