[开发测试]Dapr for dotnet | 服务调用-Service invoke（性能压测）

前言

前面我们演示了 Dapr 基于 HTTP 和 gRPC 协议的 Service invoke 案例，这两种协议下的服务调用性能差距如何呢？

• Dapr 服务调用-Service invoke（HTTP协议）
• Dapr 服务调用-Service invoke（gRPC协议）

基于上面的疑问，就需要对相关接口进行相应的性能压力测试，那常用的性能压测工具有哪些，接下来我们简单的了解下性能压测工具。

常用的性能压测工具

对于压测工具，业界常用的有以下这些：

• Apache JMeter

一款广为流传的开源压测产品，在早期应用于Web应用测试，如今JMeter可以用于测试静态和动态资源，例如静态文件、Java 小服务程序、CGI 脚本、Java 对象、数据库、FTP 服务器等等，还能对服务器、网络或对象模拟巨大的负载，通过不同压力类别测试它们的强度和分析整体性能。另外，JMeter能够对应用程序做功能/回归测试，通过创建带有断言的脚本来验证你的程序返回了你期望的结果。为了最大限度的灵活性，JMeter允许使用正则表达式创建断言。

• LoadRunner

一种预测系统行为和性能的负载测试工具，通过模拟实际用户的操作行为进行实时性能监测，来帮助测试人员更快的查找和发现问题。

• TCPCopy

一种请求复制（所有基于 TCP 的 packets）工具，支持对 Internet 服务器应用程序的真实测试。 可以把在线流量导入到测试系统中去（也可以在测试系统内部放大流量），从而模拟真实运行环境，以便排查测试系统的性能问题和风险。TCPCopy 的优势在于其实时性及真实性，除了少量的丢包，可以完全拷贝线上流量到测试机器，真实的模拟线上流量的变化规律。

• Apache Bench（简称ab）

是 Apache 超文本传输协议(HTTP)的性能测试工具。其设计意图是描绘当前所安装的Apache 的执行性能，主要是显示你安装的 Apache 每秒可以处理多少个请求。既可以用来测试 Apache 的负载压力，也可以测试 Nginx、Lighthttp、Tomcat、IIS 等其它 Web 服务器的压力。
ab 命令对发出负载的计算机要求很低，它既不会占用很高CPU，也不会占用很多内存。但却会给目标服务器造成巨大的负载，其原理类似CC攻击。自己测试使用也需要注意，否则一次上太多的负载。可能造成目标服务器资源耗完，严重时甚至导致死机。

• WRK

wrk 是一款针对 HTTP 协议的基准测试工具，它能够在单机多核 CPU 的条件下，它将多线程设计与可扩展的事件通知系统（如 epoll 和 kqueue）相结合，对目标机器产生大量的负载。可选的 LuaJIT 脚本可以执行 HTTP 请求生成、响应处理和自定义报告。

• WRK2

wrk2 经过 wrk 修改以产生恒定的吞吐量负载，并将准确的延迟详细信息精确到高 9 秒（即当运行足够长的时间时，可以产生准确的 99.9999%'ile）。除了 wrk 的参数之外，wrk2 还通过 --rate 或 -R 参数（默认值为 1000）获取吞吐量参数（以每秒请求数为单位）。

了解更多的压测工具，请参考以下文章

• 10大主流压力/负载/性能测试工具推荐
• TCPCopy-网易开源的流量重放（replay）工具
• wrk 一个现代的HTTP基准测试工具，gitee 地址
• wrk2 一个主要基于 wrk 的 HTTP 基准测试工具

为什么是 wrk2 压测工具

wrk2 主要是基于 wrk 的压测工具，也就是说 wrk 具备的功能 wrk2 都有，wrk 目前仅支持单机压测，后续也不太可能支持多机器对目标机压测，因为它本身的定位，并不是用来取代 JMeter, LoadRunner 等专业的测试工具，wrk 提供的功能，对我们后端开发人员来说，应付日常接口性能验证还是比较友好的。

说完 wrk 的劣势，再来说说 wrk 的优势：

• 轻量级性能测试工具;
• 安装简单（相对 Apache ab 来说）;
• 学习曲线基本为零，几分钟就能上手体验；
• 基于系统自带的高性能 I/O 机制，如 epoll, kqueue, 利用异步的事件驱动框架，通过很少的线程就可以压出很大的并发量；

基于以上的了解情况，wrk2 符合我们的压测需求，可以快速上手实践接口性能压测。

wrk2 压测工具安装及应用

wrk2 （wsl2环境）安装

wrk 只能被安装在类 Unix 系统上，所以我们需要一个 Linux 或者 MacOS 环境。Windows 10 安装需要开启自带的 Linux 子系统（WSL2）。

此处我是使用 WSL2 （Ubuntu 20.04 LTS）环境安装：

sudo apt install wget
sudo wget https://aspnetbenchmarks.blob.core.windows.net/tools/wrk2

查看 wrk2 版本信息，验证是否安装成功。

root@sws-it-dev:~# ls
wrk2
root@sws-it-dev:~# ./wrk2 -v
wrk 4.0.0 [epoll] Copyright (C) 2012 Will Glozer

wrk2 基本用法

Usage: wrk <options> <url>
  Options:
    -c, --connections <N>  Connections to keep open # HTTP连接数，如1k、1M、1G
    -d, --duration    <T>  Duration of test # 测试持续时间，如 2s、2m、2h       
    -t, --threads     <N>  Number of threads to use # 开启的线程数 

    -s, --script      <S>  Load Lua script file # 进阶功能，使用 lua 脚本
    -H, --header      <H>  Add header to request # 添加请求头
    -L  --latency          Print latency statistics # 打印详细延迟统计
    -U  --u_latency        Print uncorrected latency statistics # 打印未更正的延迟统计信息
        --timeout     <T>  Socket/request timeout # 设置请求超时时间，大于该时间的请求将被记录
    
    # 测量整批流水线操作的延迟。(相对于每一次操作)
    -B, --batch_latency    Measure latency of whole 
                           batches of pipelined ops
                           (as opposed to each op)
    -v, --version          Print version details # 查看 wrk2 版本号

    # 工作速率（吞吐量）即每个线程每秒钟完成的请求数
    -R, --rate        <T>  work rate (throughput) 
                           in requests/sec (total)
                           [Required Parameter]


  Numeric arguments may include a SI unit (1k, 1M, 1G)
  Time arguments may include a time unit (2s, 2m, 2h)
root@sws-it-dev:~#

其他环境的安装方式请自行查看相关资料，此处不再说明。

压测目标规划

在做测试前，有必要说明下测试主机的规格配置清单。

宿主机资源

测试场景

测试的目标很简单，代码中没有任何的业务逻辑，单纯的对比以下模式的性能极限：

1. dotnet run 原生模式基于 http1.1 的性能压测（web api 和跨服务调用）；
2. dapr run 模式基于 http1.1 的性能压测（web api 和跨服务调用）；
3. dapr run 模式基于 grpc/http2.0 的性能压测（跨服务调用）；

根据上面的测试目标，规划如下测试情况：

运行测试

注意：下面的测试命令，分别在 dotnet run 和 dapr run 模式下执行测试。

例如：开启 2 个线程、100 个 http 连接、并保持每个线程每秒 200 个请求的恒定吞吐量，运行 30 秒的基准测试，并输出详细延时统计。

• Requests/sec：每秒请求次数
• Transfer/sec：每秒吞吐量

./wrk2 -t2 -c 100 -d 30s -R 100 -L http://localhost:5000/WeatherForecast/Get

压测接口如下：

# http 1.1
http://localhost:5000/WeatherForecast/Get
http://localhost:5001/api/DaprHttpInvoke/Get
http://localhost:5001/api/DaprHttpInvoke/Get2
http://localhost:5001/api/DaprHttpInvoke/Get3
http://localhost:5001/api/DaprHttpInvoke/Get4

# grpc(http2.0)
http://localhost:5001/api/DaprGrpcInvoke/Grpc
http://localhost:5001/api/DaprGrpcInvoke/Grpc2

压测数据性能统计

该测试数据仅供参考，实际项目环境考虑的情况还有很多因素，以实战项目测试情况为准。

总结

就目前测试指标统计的数据来看，Dapr Sidecre 模式运行的项目，性能有一定程度的损耗，基于 http 和 grpc 协议的 Service invoke 整体性能差距不大，但和原生 dotnet run 模式启动的项目差距较明显。不知该测试方式是否有误，欢迎更多的小伙伴实践测试对比。感兴趣的小伙伴，赶快动手哟(＾Ｕ＾)ノ~ＹＯ