摘要: 简单介绍EasyCaching提供的一些功能特性 阅读全文
posted @ 2019-05-04 14:06 Catcher8 阅读(9105) 评论(28) 推荐(54) 编辑
摘要: Jexus用法和知识的相关记录 阅读全文
posted @ 2018-06-24 11:13 Catcher8 阅读(1113) 评论(1) 推荐(2) 编辑
摘要: 利用.NET技术打造一个全平台软件的简单构思与简单实现。 阅读全文
posted @ 2016-05-04 13:03 Catcher8 阅读(8193) 评论(51) 推荐(94) 编辑
摘要: 本人写的Nancy学习系列汇总 阅读全文
posted @ 2016-02-12 14:31 Catcher8 阅读(3204) 评论(12) 推荐(10) 编辑

背景

当我们写了一个类库提供给别人使用时,我们可能会对它做一些基准测试来测试一下它的性能指标,好比内存分配等。

在 .NET 的世界中,用 BenchmarkDotNet 来做这件事是非常不错的选择,我们只要写少量的代码就可以在本地运行基准测试然后得到结果。

这个在修改代码的时候,效果可能会更加明显,因为我们想知道我们的修改会不会使这段代码跑的更快,占用的资源更少。

作一个简单的假设,根据测试用例,代码变更之前,某方法在基准测试的分配的内存是 1M,修改之后变成 500K,那么我们可以认为这次的代码变更是有性能提升的,占用的资源更少了,当然这个得在单元测试通过的前提下。

试想一下,如果遇到下面的情况

  1. 想在多个不同配置的机器上面运行基准测试,好比 4c8g 的windows, 4c16g 的 linux
  2. Pull Request/Merge Request 做代码变更时,如何较好的做变更前后的基准测试比较

这个时候就会复杂一点了,要对一份代码在多个环境下面运行,做一些重复性的工作。

那么我们有没有办法让这个变得简单呢?答案是肯定的。

我们可以用 Crank 这个工具来完成这些内容。

什么是 Crank

Crank 是.NET团队用于运行基准测试的基础设施,包括(但不限于)TechEmpower Web Framework基准测试中的场景。 Crank 第一次出现在公众的视野应该是在 .NET Conf 2021, @sebastienros 演讲的 Benchmarking ASP.NET Applications with .NET Crank

Crank 是 client-server (C/S) 的架构,主要有一个控制器 (Controller) 和一个或多个代理 (Agent) 组成。 其中控制器就是 client,负责发送指令;代理就是 server,负责执行 client 发送的指令,也就是执行具体的测试内容。

下面是它的架构图。

可以看到,控制器和代理之间的交互是通过 HTTP 请求来驱动的。然后代理可以执行多个不同类型的作业类型。

我们这篇博客主要讲的是图中的 .NET project Job

先来看看官方仓库一个比较简单的入门示例。

入门示例

首先要安装 crank 相关的两个工具,一个是控制器,一个是代理。

dotnet tool update Microsoft.Crank.Controller --version "0.2.0-*" --global

dotnet tool update Microsoft.Crank.Agent --version "0.2.0-*" --global

然后运行官方仓库上面的 micro 示例,是一个 Md5 和 SHA 256 对比的例子。

public class Md5VsSha256
{
    [Params(100, 500)]
    public int N { get; set;}
    private readonly byte[] data;

    private readonly SHA256 sha256 = SHA256.Create();
    private readonly MD5 md5 = MD5.Create();

    public Md5VsSha256()
    {
        data = new byte[N];
        new Random(42).NextBytes(data);
    }

    [Benchmark]
    public byte[] Sha256() => sha256.ComputeHash(data);

    [Benchmark]
    public byte[] Md5() => md5.ComputeHash(data);
}

要注意的是 Main 方法,要用 BenchmarkSwitcher 来运行,因为 Crank 是用命令行来执行的,会附加一些参数,也就是代码中的 args。

public static void Main(string[] args)
{
    BenchmarkSwitcher.FromAssembly(typeof(Program).Assembly).Run(args);
}

然后是控制器要用到的配置文件,里面就是要执行的基准测试的内容,要告诉代理怎么执行。

# 作业
jobs:
  # 作业名,自定义
  benchmarks:
    # 源相关内容
    source:
      # 这里是本地文件夹,也可以配置远程 repository 和分支
      localFolder: .
      # 这个是具体的 csproj
      project: micro.csproj
    # 一些变量
    variables:
      filterArg: "*"
      jobArg: short
    # 参数
    arguments: --job {{jobArg}} --filter {{filterArg}} --memory
    options:
      # 使用 BenchmarkDotNet
      benchmarkDotNet: true

# 场景    
scenarios:
  # 场景名,自定义
  Md5VsSha256:
    application:
      # 与前面的定义作业名一致
      job: benchmarks

# 档案
profiles:
  # 档案名,自定义
  local:
    jobs: 
      application:
        # 代理的地址
        endpoints: 
          - http://localhost:5010

下面先来启动代理,直接运行下面的命令即可。

crank-agent

会看到下面的输出:

[11:42:30 INF] Created temp directory 'C:\Users\catcherwong\AppData\Local\Temp\2\benchmarks-agent\benchmarks-server-8952\2mmqc00i.3b1'
[11:42:30 INF] Agent ready, waiting for jobs...

默认端口是 5010,可以通过 -u|--url 来指定其他的;如果运行代理的电脑已经安装好 SDK 了,可以指定 --dotnethome 避免因网络问题导致无法正常下载 SDK。

然后是通过控制器向代理发送指令。

crank --config C:\code\crank\samples\micro\micro.benchmarks.yml --scenario  Md5VsSha256 --profile local

上面的命令指定了我们上面的配置文件,同时还指定了 scenario 和 profile。因为配置文件中可以有多个 scenario 和 profile,所以在单次执行是需要指定具体的一个。

如果需要执行多个 scenario 则需要执行多次命令。

在执行命令后,代理里面就可以看到日志输出了:

最开始的是收到作业请求,然后安装对应的 SDK。安装之后就会对指定的项目进行 release 发布。

发布成功后就会执行 BenchmarkDotNet 相关的内容。

运行完成后会输出结果,最后清理这次基准测试的内容。

代理执行完成后,可以在控制器侧看到对应的结果:

一般来说,我们会把控制器得到的结果保存在 JSON 文件里面,便于后续作对比或者要出趋势图。

这里可以加上 --json 文件名.json

crank --config C:\code\crank\samples\micro\micro.benchmarks.yml --scenario  Md5VsSha256 --profile local --json base.json

运行多次,将结果存在不同的 JSON 文件里,尤其代码变更前后的结果。

crank --config C:\code\crank\samples\micro\micro.benchmarks.yml --scenario  Md5VsSha256 --profile local --json head.json

最后是把这两个结果做一个对比,就可以比较清楚的看到代码变更是否有带来提升。

crank compare base.json head.json

上面提到的还是在本地执行,如果要在不同的机器上面执行要怎么配置呢?

我们要做的是在配置文件中的 profiles 节点增加机器的代理地址即可。

下面是简单的示例:

profiles:
  local:
    jobs: 
      application:
        endpoints: 
          - http://localhost:5010
  remote-win:
    jobs: 
      application:
        endpoints: 
          - http://192.168.1.100:9090
  remote-lin:
    jobs: 
      application:
        endpoints: 
          - http://192.168.1.102:9090      

这个时候,如果指定 --profile remote-win 就是在 192.168.1.100 这台服务器执行基准测试,如果是 --profile remote-lin 就是在 192.168.1.102

这样就可以很轻松的在不同的机器上面执行基准测试了。

Crank 还有一个比较有用的功能是可以针对 Pull Request 进行基准测试,这对一些需要基准测试的开源项目来说是十分有帮助的。

接下来老黄就着重讲讲这一块。

Pull Request

正常来说,代码变更的肯定是某个小模块,比较少出现多个模块同时更新的情况,如果是有,估计也会被打回拆分!

所以我们不会选择运行所有模块的基准测试,而是运行变更的那个模块的基准测试。

思路上就是有人提交 PR 后,由项目组成员在 PR 上面进行评论来触发基准测试的执行,非项目组成员的话不能触发执行。

下面就用这个 Crank 提供的 Pull Request Bot 来完成后面的演示。

要想用这个 Bot 需要先执行下面的安装命令:

dotnet tool update Microsoft.Crank.PullRequestBot --version "0.2.0-*" --global

安装后会得到一个 crank-pr 的文件,然后执行 crank-pr 的命令就可以了。

可以看到它提供了很多配置选项。

下面是一个简单的例子

crank-pr \
  --benchmarks lib-dosomething \
  --components lib \
  --config ./benchmark/pr-benchmark.yml\
  --profiles local \
  --pull-request 1 \
  --repository "https://github.com/catcherwong/library_with_crank" \
  --access-token "${{ secrets.GITHUB_TOKEN }}" \
  --publish-results true

这个命令是什么意思呢?

它会对 catcherwong/library_with_crank 这个仓库的 Id 为 1 的 Pull Request 进行两次基准测试,一次是主分支的代码,一次是 PR 合并后的代码;基准测试的内容由 benchmarks,components 和 profiles 三个选项共同决定;最后两个基准测试的结果对比会在 PR 的评论上面。

其中 catcherwong/library_with_crank 是老黄提前准备好的示例仓库。

下面来看看 pr-benchmark.yml 的具体内容

components:
    lib: 
        script: |
            echo lib
        arguments:
            # crank arguments
            "--application.selfContained false"

# default arguments that are always used on crank commands
defaults: ""

# the first value is the default if none is specified
profiles:
    local:
      description: Local
      arguments: --profile local
    remote-win:
      description: windows
      arguments: --profile remote-win 
    remote-lin:
      description: linux
      arguments: --profile remote-lin 

benchmarks:
    lib-dosomething:
      description: DoSomething
      arguments: --config ./benchmark/library.benchmark.yml --scenario dosomething

    lib-getsomething:
      description: GetSomething
      arguments: --config ./benchmark/library.benchmark.yml --scenario getsomething

    lib-another:
      description: Another
      arguments: --config ./benchmark/library.benchmark.yml --scenario another

基本上可以说是把 crank 的参数拆分了到了不同的配置选项上面去了,运行的时候就是把这些进行组合。

再来看看 library.benchmark.yml

jobs:
  lib:
    source:
      localFolder: ../src
      project: BenchmarkLibrary/BenchmarkLibrary.csproj
    variables:
      filter: "*"
      jobArg: short
    arguments: --job {{jobArg}} --filter {{filter}} --memory
    options:
      benchmarkDotNet: true  

scenarios:
  dosomething:
    application:
      job: lib
      variables:
        filter: "*DoSomething*"

  getsomething:
    application:     
      job: lib
      variables:
        filter: "*GetSomething*"

  another:
    application:     
      job: lib
      variables:
        filter: "*Method*"

profiles:
  local:
    jobs: 
      application:
        endpoints: 
          - http://localhost:9999
  
  remote-lin:
    jobs: 
      application:
        endpoints: 
          - http://remote-lin.com

  remote-win:
    jobs: 
      application:
        endpoints: 
          - http://remote-win.com

和前面入门的例子有点不一样,我们在 scenarios 节点 里面加了一个 variables,这个和 jobs 里面定义的 variables 和 arguments 是相对应的。

如果指定 --scenario dosomething,那么最后得到的 arguments 就是

--job short --filter *DoSomething* --memory

后面就是来看看效果了。

这里省略了评论内容的解析,也就是评论什么内容的时候会触发执行,因为这一块不是重点,有兴趣可以看 workflow 的脚本即可。

具体的执行过程可以参考

https://github.com/catcherwong/library_with_crank/actions/runs/4598397510/jobs/8122376959

当然,如果条件允许的话,也可以用自己的服务器资源来跑基准测试,不用 Github Action 提供的资源。

这样的好处是相对稳定,可以自己根据场景指定不同配置的服务器。不过对一些没那么复杂类库,用 Github Action 的资源也是无伤大雅的。

下面这个截图就是在提交到外部服务器上面执行的。

如果仓库不是在 Github,是在自建 Gitlab 或者其他的,就可以根据这个思路来自定义流水线从而去完成这些基准测试的操作。

总结

Crank 还是一个挺不错的工具,可以结合 BenchmarkDotNet 来做类库的基准测试,也可以结合 wrk/wrk2/bombardier/h2load 等压测工具进行 api/grpc 框架和应用的测试。

这里只介绍了其中一个小块的内容,还有挺多内容可以挖掘一下的。

最后是本文的示例代码:

https://github.com/catcherwong/library_with_crank

参考资料

posted @ 2023-04-06 08:20 Catcher8 阅读(384) 评论(4) 推荐(6) 编辑
摘要: 背景 代码质量其实是一个很容易被忽略的关键点,可能有的团队会有 Code Review 这些环节来做一定程度的保障,但是这个 Code Review 会很耗费人力和时间,估计大部分团队都不会很经常的来弄,比较多的可能会是有间隔性的来几次。 这个时候就会需要引入一些工具来协助去处理这一块。 sonar 阅读全文
posted @ 2023-03-06 08:21 Catcher8 阅读(282) 评论(0) 推荐(0) 编辑
摘要: 聊一聊HTTPS双向认证的简单应用 阅读全文
posted @ 2023-02-15 23:26 Catcher8 阅读(942) 评论(2) 推荐(3) 编辑
摘要: 背景 接口层做数据加密应该算是老生常谈的一件事了,业界用的比较多的,不外乎是对称加密,非对称加密以及两者的结合。 对称加密,比较有代表性的就是 AES,密钥只有一个,客户端和服务端都要进行存储,但是对客户端来说,比较容易泄露,需要定期进行更换。 非对称加密,比较有代表性的就是 RSA,有公钥和私钥, 阅读全文
posted @ 2023-02-10 08:30 Catcher8 阅读(711) 评论(0) 推荐(4) 编辑
摘要: 记一次系统迁移遇到的中文字符串排序问题 阅读全文
posted @ 2023-01-30 08:19 Catcher8 阅读(78) 评论(0) 推荐(1) 编辑
摘要: 2022年,*似躺*的一年。 阅读全文
posted @ 2023-01-30 08:15 Catcher8 阅读(47) 评论(0) 推荐(1) 编辑
摘要: Redis离线分析,可用CLI,也可以用C#自定义。 阅读全文
posted @ 2022-04-18 22:24 Catcher8 阅读(794) 评论(0) 推荐(3) 编辑
摘要: 背景 前面写了两篇如何用 C# 基于 DTM 轻松实现 SAGA 和 TCC 的分布式事务,其中有一个子事务屏障的功能,很好的处理了空补偿、悬挂、重复请求等异常问题。 https://dtm.pub/practice/barrier.html 不过前面的例子都是基于 mysql 的,有人问是否还支持 阅读全文
posted @ 2022-02-14 08:20 Catcher8 阅读(574) 评论(0) 推荐(5) 编辑
摘要: 聊一聊如何用C#轻松完成一个TCC分布式事务 阅读全文
posted @ 2022-02-08 08:13 Catcher8 阅读(3159) 评论(15) 推荐(44) 编辑
摘要: 聊一聊如何用C#轻松完成一个SAGA分布式事务 阅读全文
posted @ 2022-01-24 08:03 Catcher8 阅读(2952) 评论(7) 推荐(39) 编辑
摘要: 老黄的2021 阅读全文
posted @ 2021-12-31 23:50 Catcher8 阅读(90) 评论(0) 推荐(1) 编辑
摘要: Yarp结合Nacos完成服务发现 阅读全文
posted @ 2021-12-27 08:06 Catcher8 阅读(961) 评论(1) 推荐(3) 编辑
摘要: 背景 在很多时候,产品同学或其他 boss 会有一些想法,或好或坏,都会想放到线上环境去验证,看看能不能带来更好的效果。 这其实就是一个提出假设和验证假设的过程,而 AB 测试,是验证假设的好方法。 对于服务之间的调用,这一块其实也是相当符合的。 举几个例子吧 A → B,B 进行了重构 A → B 阅读全文
posted @ 2021-12-13 08:09 Catcher8 阅读(748) 评论(0) 推荐(0) 编辑
摘要: 聊一聊声明式接口调用与Nacos的结合使用 阅读全文
posted @ 2021-11-12 08:21 Catcher8 阅读(812) 评论(0) 推荐(0) 编辑
摘要: 聊一聊Jmeter多用户token使用问题 阅读全文
posted @ 2021-10-18 08:24 Catcher8 阅读(891) 评论(0) 推荐(1) 编辑
摘要: 背景 上一篇关于 JMeter 的多接口测试,虽说可以把几个步骤的串联起来,但是会比较简单和单调。 还有许多业务场景,会根据上一个接口的返回,再决定要不要调用第二个接口或者是掉用其他接口。 还是拿大家常见的查询订单举个例,首先可以是查询订单列表,然后再查订单详情。 试想一下如果订单列表是空,还有必要 阅读全文
posted @ 2021-10-15 08:11 Catcher8 阅读(340) 评论(0) 推荐(0) 编辑
摘要: 背景 公司内部的API接口一般会分为两大类,一类是直接暴露在公网可以访问的,一类是只能在局域网内访问的。 暴露在公网的一般就是业务网关以及一些和第三方公司有着某些合作,从而进行数据交互的接口。 检查API接口是否存活,第一反应应该就是健康检查了。 在局域网环境内搭配 nginx 或注册中心之类的健康 阅读全文
posted @ 2021-08-23 08:06 Catcher8 阅读(1368) 评论(1) 推荐(0) 编辑
摘要: Cassandra存储聊天记录是个不错的选择 阅读全文
posted @ 2021-07-12 08:27 Catcher8 阅读(2811) 评论(0) 推荐(0) 编辑
摘要: 背景 当我们把应用的配置都放到配置中心后,很多人会想到这样一个问题,配置里面有敏感的信息要怎么处理呢? 信息既然敏感的话,那么加个密就好了嘛,相信大部分人的第一感觉都是这个,确实这个是最简单也是最合适的方法。 其实很多人都在关注这个问题,好比说,数据库的连接字符串,调用第三方的密钥等等这些信息,都是 阅读全文
posted @ 2021-06-15 08:09 Catcher8 阅读(3579) 评论(9) 推荐(22) 编辑
摘要: 前言 ElasticSearch,开源的搜索和数据分析引擎,也是名列前茅的 nosql。 很多时候会想拿它和关系型数据库做对比,严格上它们是没有太多可比性的。 不过把有的东西放在一起比较,会帮助我们快速去理解一些 ElasticSearch 的内容。 老黄这边抽空梳理了一些常用的 sql 语句 “对 阅读全文
posted @ 2021-06-09 21:01 Catcher8 阅读(579) 评论(0) 推荐(2) 编辑
点击右上角即可分享
微信分享提示