乐趣区

关于后端:性能测试小工具-wrk-可以怎么用

jiezi

工作中，我的项目设计之初或者是我的项目快要完结的时候，大佬就会问咱们，这个服务性能测试的后果是什么，QPS 能够达到多少，RPS 又能达到多少？

你本人写的接口性能能够满足将来生产环境的理论状况吗？有没有本人测试过本人接口的吞吐量等等

作为设计开发人员，这些问题不仅仅是用来面试，还是实实在在的落地在理论工作中

很多我的项目上线初期用户量较小，外表上看是惊涛骇浪，实则暗流涌动，缓缓的用户量上来之后，零碎的瓶颈缓缓凸显

已经挖的坑，最初还是要咱们本人来填，若不能及时填上，可能整个产品就这么葬送了

明天一起来看看 wrk 轻量级的 性能测试工具如何应用

性能测试相干名词

  • QPS 每秒查问率 (Query Per Second)

每秒查问率 QPS 是对一个特定的查问服务器在规定工夫内所解决流量多少的衡量标准

  • 并发用户数

指零碎能够同时承载的失常应用零碎性能的用户的数量

  • 吞吐量 (Throughput)

吞吐量是指零碎在单位工夫内解决申请的数量

  • 响应工夫 (RT)

指系统对申请作出响应的工夫

wrk 是什么

wrk 是 github 的一个我的项目

https://github.com/wg/wrk

依据官网的阐明，wrk 是一个 HTTP 基准测试工具

当运行在单个多核 CPU 上时，它可能产生微小的负载。它联合了多线程设计和可伸缩的事件告诉零碎，如 epoll 和 kqueue 等等

wrk 中的一个可选的 LuaJIT 脚本能够执行 HTTP 申请生成、响应解决和自定义报告

wrk 如何应用

那么 wrk 如何应用呢，咱们就来实操一下看看成果，既然是 开源工具，下载安装编译的形式都很相似

1、下载 wrk 我的项目

git clone https://github.com/wg/wrk.git wrk

2、编译我的项目

cd wrk
make

3、将编译进去的 wrk 可执行程序放到用户本人的 bin 目录下

 cp wrk /usr/local/sbin/

4、这个时候，咱们就能够 开始应用 wrk 工具 了

咱们间接执行 wrk 来看看成果

# wrk
Usage: wrk <options> <url>
  Options:
    -c, --connections <N>  Connections to keep open // 和服务器建设连贯并放弃的 TCP 连贯数量  
    -d, --duration    <T>  Duration of test  // 具体的压测工夫
    -t, --threads     <N>  Number of threads to use // 应用的线程数量

    -s, --script      <S>  Load Lua script file    // 加载 lua 文件
    -H, --header      <H>  Add header to request // 增加申请头
        --latency          Print latency statistics // 打印提早统计数据
        --timeout     <T>  Socket/request timeout // 超时工夫
    -v, --version          Print version details // 版本信息

  Numeric arguments may include a SI unit (1k, 1M, 1G)
  Time arguments may include a time unit (2s, 2m, 2h)

下面的 N 示意数字参数，能够是 1k, 1M, 1G

T 示意工夫参数，能够是 2s, 2m, 2h

尝试应用 wrk 工具

咱们应用 wrk 同样的参数来性能 测试一下 掘金 和 百度的地址

  • 200 个链接
  • 8 个线程
  • 测试 40 s

先测试掘金的

# wrk -c200 -t8 -d40 --latency https://juejin.cn/
Running 40s test @ https://juejin.cn/
  8 threads and 200 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     1.53s   481.41ms   2.00s    87.68%
    Req/Sec    10.27      7.50    70.00     73.61%
  Latency Distribution
     50%    1.67s
     75%    1.85s
     90%    1.95s
     99%    2.00s
  2406 requests in 40.05s, 476.65MB read
  Socket errors: connect 0, read 0, write 0, timeout 1797
Requests/sec:     60.08
Transfer/sec:     11.90MB

再测试百度的

# wrk -c200 -t8 -d40 --latency https://www.baidu.com
Running 40s test @ https://www.baidu.com
  8 threads and 200 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   284.06ms  332.08ms   2.00s    86.02%
    Req/Sec    96.41     36.69   538.00     79.63%
  Latency Distribution
     50%  120.17ms
     75%  357.11ms
     90%  730.79ms
     99%    1.56s
  31088 requests in 40.07s, 466.95MB read
  Socket errors: connect 0, read 138, write 0, timeout 264
Requests/sec:    775.87
Transfer/sec:     11.65MB

解释下面测试报告相干字段的含意：

  • Latency 提早
  • Avg 平均值
  • Stdev 标准差
  • +/- Stdev 标准差占比
  • Requests/sec 均匀每秒解决的申请数，通常说的 qps 这里能够看出 掘金是 60.08，百度是 775.87，差异还是有的

实际结束之后，咱们来捋一捋 wrk 的劣势和劣势

劣势：

  • wrk 是轻量级性能测试工具，用起来十分不便，且装置也很简略，学习成本低

  • 依据官网介绍，咱们晓得 wrk 基于零碎自带的高性能 I/O 机制，如 epoll, kqueue

    这些机制是利用异步的事件驱动框架 多路 IO 复用来进步并发性能的

劣势：

  • 仅反对单机压测，如果须要测试多台机器，wrk 就不适合了

小常识，大挑战，工具要用起来才有用

欢送点赞，关注，珍藏

敌人们，你的反对和激励，是我保持分享，提高质量的能源

好了，本次就到这里

常见技术是凋谢的，咱们的心态，更应是凋谢的。拥抱变动，背阴而生，致力向前行。

我是 阿兵云原生，欢送点赞关注珍藏，下次见~

退出移动版