v2tn-测试鼠

MASA.Blazor：https://github.com/BlazorComponent/MASA.Blazor

如果你对我们的 MASA Framework 感兴趣，无论是代码贡献、使用、提 Issue，欢迎联系我们

自动化测试的生命周期是什么？

炒蚕豆吃蹦豆 — 2023-05-27

软件测试发展到今日，已经逐渐标准化且能力更强，其流程每天都在发展。测试人员的技术熟练程度对于整个测试阶段的成功来说至关重要。测试不再意味着仅仅发现错误；它的范围已经扩大，从任何开发项目开始就可以看出它的重要性。

当谈论起自动化测试生命周期（Automation Testing Life Cycle）时，大多数人认为这只是 SDLC 的一部分，但它远不止于此。有必要了解自动化测试应该是自动化测试策略的突出部分，并且具有生命周期。企业必须对其进行调整以提高其软件产品的质量。

随着继续推进，需要能够回答以下问题：什么是自动化测试生命周期，以及自动化测试生命周期中的有哪些阶段。

自动化测试生命周期的各个阶段

测试的自动化应该得到强大的测试计划的支持。流程的预定义结构有助于设计测试计划并制定自动化测试工具的选择策略，从而设置测试环境、设计测试用例并编写脚本。它进一步定义了测试自动化、测试准备、实施、测试验证和报告的范围。

自动化测试生命周期中的这六个阶段与软件开发周期并行运行。以下是各阶段：

阶段1：确定自动化测试的范围
阶段2：选择合适的自动化工具
阶段3：定义自动化测试的计划、策略和设计
阶段4：设置测试环境
阶段5：测试脚本和执行
阶段6：测试分析和报告

1. 确定自动化测试的范围

这是自动化测试生命周期的第一步。在此步骤中，测试团队需要确定自动化测试的可行性。可行性分析对于每个阶段都是必不可少的，以检查其可操作性，并帮助测试团队设计测试脚本。本阶段需要考虑的事项包括：

应用程序的哪些模块应该自动化，哪些模块不应该自动化。
哪些测试用例可以或需要自动化。
如何自动化这些测试用例。
考虑到自动化与测试目标的适应性，选择哪些自动化工具。
预算、实施成本、可用资源和可用技能。

测试用例和自动化测试可行性分析应在开始测试自动化之前进行。

2. 选择合适的自动化工具

这是ATLC最关键的阶段之一，因为自动化测试依赖于工具。要谨慎地考虑和选择正确的自动化工具来自动化UI组件。选择工具可能需要完成另一个层次的分析。在选择工具之前，应该始终牢记预算和成本。除此之外，团队还应分析资源是否具有技术技能，以及工具是否支持项目所需的技术。此外，该工具应提供强大的技术支持，以回答使用中可能存在的疑问。

3.自动化测试的计划、策略和设计

这是自动化测试周期中的另一个关键步骤，主要解释实现测试自动化策略的方法。这个阶段的主要步骤是决定使用哪个测试自动化框架。在为项目选择合适的工具时，必须记住软件项目所需的技术。因此，对产品进行深入分析非常重要。

在执行自动化测试计划时，测试人员为测试过程创建、测试环境的硬件、软件和网络需求、测试数据先决条件、测试时间表、错误跟踪机制和工具等建立标准和指南。测试人员还负责决定测试体系结构、测试程序的结构和测试程序管理。

测试管理策略涵盖以下几点：

测试管理工具将捕获所有手动测试用例。测试人员需要收集手动测试用例并确定哪些需要测试。
必须进行彻底的研究来确定测试框架并了解自动化测试工具的优缺点。
此外，测试人员还需要了解工具和应用程序之间的所有相关威胁、背景和依赖关系。
团队还必须在测试管理工具中为自动化测试用例构建一个测试套件。
未经利益相关者和客户批准，无法实施或执行制定的测试策略。

4. 搭建测试环境

在此阶段，测试团队必须设置、跟踪和安排测试环境。换句话说，这意味着在这个阶段，建立了一个机器/远程环境来执行测试用例。需要虚拟机是因为并非所有用户都使用相同的机器来访问 Web 应用程序。因此，我们需要观察用户使用的各种设备、浏览器和版本。如果未正确验证其在不同设备-浏览器-操作系统组合之间的兼容性，网站效果跟用户看到的可能不一样。为了实现这一点，跨浏览器测试成为首要任务，以确保您的 Web 应用程序按预期提供出色的用户体验。
此阶段需要详细规划以处理尽可能多的场景并增加测试覆盖率。在测试团队负责任的参与下，必须维护所有环境设置活动的正确跟踪和时间表。除此之外，设置测试环境、安排网络和硬件资源、执行测试数据库清理、开发测试平台和环境脚本等一切都必须处理。

执行跨浏览器测试并不像听起来那么容易。它涉及设置不同的浏览器、不同的版本、不同的设备等，这对团队来说是个不小的负担。

维护浏览器实验室并不是一件容易的事，因为从头开始建立和维护基础设施成本高昂，而且并非所有企业都能负担得起。因此，建议采用基于云的测试基础设施，为测试人员提供一个平台，以测试虚拟机托管的多个移动和桌面设备的各种浏览器设备操作系统组合。

以下是测试环境设置的几个方面：

确保有一个可以进行负载测试的前端运行环境，以检查其是否有能力处理高负载的Web流量。
有时，设置的测试环境没有提供与生产数据相似的数据，使产品容易受到生产环境中任何代码更改的影响。
需要进行测试的所有系统、模块和应用程序的列表应该进行维护检查。
测试尽可能多的浏览器及其版本。
跨多个客户端操作系统进行测试。
需要用于登台环境的单独数据库服务器。
确保在不同网络条件下测试 Web 应用程序，以了解实际的网站渲染时间和整体外观。
在中央数据库中维护用户手册、安装指南和其他文档也是为未来需求设置测试环境的关键。

5. 测试脚本和执行

配置测试环境设置后，下一步就是执行测试脚本。测试人员在开发测试脚本之前应该考虑以下几点：

根据项目要求创建脚本。
在整个过程中使用通用的方法。
确保脚本可重用、简单且结构化，以便任何人都能理解它们。
执行适当的代码审查和报告以获得更好的见解并在整个过程中保持质量。

脚本开发完成后，需要牢记以下几点以确保脚本无障碍运行：

根据测试用例，它们应该包括所有功能方面。
它们应该涵盖执行测试脚本的所有平台和环境。。
它们必须批量处理以节省时间和精力。
要始终练习编写错误报告，以防出现任何功能错误。

评估和记录测试结果以供进一步参考，并在 ATLC 的这一部分创建测试结果文档。

6. 测试分析和报告

它是自动化测试生命周期的最后也是最关键的阶段，只保存数据而不进行分析并没有帮助。捕获所有测试结果后，要执行所有类型的测试，测试团队分析并识别有问题的功能。这些报告有助于了解团队是否需要附加程序，并提供有关遇到的不同错误的信息。准备一份详尽的报告，并与在此阶段对项目至关重要的利益相关者、客户、员工和团队共享。这些报告对于了解 Web 应用程序在不利情况下的行为至关重要。

结论

毫无疑问，软件自动化测试是SDLC 不可或缺的一部分，是实现测试目标的最有效方法之一。但软件测试也有其自己的一组阶段，必须认真遵循这些阶段才能获得这种技术的好处。它允许使用任何可用资源在规定的时间内实现测试目标。遵循自动化测试生命周期的每一步都有助于获得最佳结果，无需任何人工干预并减少预算和时间表。精心规划的自动化测试生命周期会带来成功的自动化测试。

6. 堪比JMeter的.Net压测工具 - Crank 实战篇 - 收集诊断跟踪信息与如何分析瓶颈

MASA技术团队 — 2023-05-27

1. 前言

上面我们已经做到了接口以及场景压测，通过控制台输出结果，我们只需要将结果收集整理下来，最后汇总到excel上，此次压测报告就可以完成了，但收集报告也挺麻烦的，交给谁呢……

找了一圈、没找到愿意接手的人，该怎么办呢……思考了会儿还是决定看看能否通过程序解决我们的难题吧，毕竟整理表格太累╯﹏╰

2. 收集结果

通过查阅官方文档，我们发现官方提供了把数据保存成Json、csv、以及数据库三种方式，甚至还有小伙伴积极的对接要把数据保存到Es中，那选个最简单的吧！

要不选择Json吧，不需要依赖外部存储，很简单，我觉得应该可试，试一下看看：输入命令：

crank --config load.benchmarks.yml --scenario api --load.framework net5.0 --application.framework net5.0 --json 1.json --profile local --profile crankAgent1 --description "wrk2-获取用户详情" --profile defaultParamLocal

最后得到结果：

{
  "returnCode": 0,
  "jobResults": {
    "jobs": {
      "load": {
        "results": {
          "http/firstrequest": 85.0,
          "wrk2/latency/mean": 1.81,
          "wrk2/latency/max": 1.81,
          "wrk2/requests": 2.0,
          "wrk2/errors/badresponses": 0.0,
          "wrk2/errors/socketerrors": 0.0,
          "wrk2/latency/50": 1.81,
          "wrk2/latency/distribution": [
            [
              {
                "latency_us": 1.812,
                "count": 1.0,
                "percentile": 0.0
              },
              {
                "latency_us": 1.812,
                "count": 1.0,
                "percentile": 1.0
              }
            ]
          ]
        }
      }
    }
  }
}

完整的导出结果

好吧，数据有点少，好像数据不太够吧，这些信息怎么处理能做成报表呢，再说了数据不对吧，QPS、延迟呢？好吧，被看出来了，因为信息太多，我删了一点点（也就1000多行指标信息吧），看来这个不行，用json的话还得配合个程序好难……

csv不用再试了，如果也是单个文本的话，也是这样，还得配个程序，都不能单干，干啥都得搭伴，那试试数据库如何

crank --config load.benchmarks.yml --scenario api --load.framework net5.0 --application.framework net5.0 --sql "Server=localhost;DataBase=crank;uid=sa;pwd=P@ssw0rd;" --table "local" --profile local --profile crankAgent1 --description "wrk2-获取用户详情" --profile defaultParamLocal

我们根据压测环境，把不同的压测指标存储到不同的数据库的表中，当前是本地环境，即 table = local

最后我们把数据保存到了数据库中，那这样做回头需要报告的时候，我查询下数据库搞出来就好了，终于松了一口气，但好景不长，发现数据库存储也有个坑，之前json中看到的结果竟然在一个字段中存储，不过幸好SqlServer 2016之后支持了json，可以通过json解析搞定，但其中参数名有/等特殊字符，sql server处理不了，难道又得写个网站才能展示这些数据了吗？？真的绕不开搭伴干活这个坑吗？

微软不会就做出个这么鸡肋的东西，还必须要配个前端才能清楚的搞出来指标吧……还得用vue、好吧，我知道虽然现在有blazer，可以用C#开发，但还是希望不那么麻烦，又仔细查找了一番，发现Crank可以对结果做二次处理，可以通过script，不错的东西，既然sql server数据库无法支持特殊字符，那我加些新参数取消特殊字符不就好了，新建scripts.profiles.yml

scripts: 
  changeTarget: |
    benchmarks.jobs.load.results["cpu"] = benchmarks.jobs.load.results["benchmarks/cpu"]
    benchmarks.jobs.load.results["cpuRaw"] = benchmarks.jobs.load.results["benchmarks/cpu/raw"]
    benchmarks.jobs.load.results["workingSet"] = benchmarks.jobs.load.results["benchmarks/working-set"]
    benchmarks.jobs.load.results["privateMemory"] = benchmarks.jobs.load.results["benchmarks/private-memory"]
    benchmarks.jobs.load.results["totalRequests"] = benchmarks.jobs.load.results["bombardier/requests;http/requests"]
    benchmarks.jobs.load.results["badResponses"] = benchmarks.jobs.load.results["bombardier/badresponses;http/requests/badresponses"]
    benchmarks.jobs.load.results["requestSec"] = benchmarks.jobs.load.results["bombardier/rps/mean;http/rps/mean"]
    benchmarks.jobs.load.results["requestSecMax"] = benchmarks.jobs.load.results["bombardier/rps/max;http/rps/max"]
    benchmarks.jobs.load.results["latencyMean"] = benchmarks.jobs.load.results["bombardier/latency/mean;http/latency/mean"]
    benchmarks.jobs.load.results["latencyMax"] = benchmarks.jobs.load.results["bombardier/latency/max;http/latency/max"]
    benchmarks.jobs.load.results["bombardierRaw"] = benchmarks.jobs.load.results["bombardier/raw"]

以上处理的数据是基于bombardier的，同理大家可以完成对wrk或者其他的数据处理

通过以上操作，我们成功的把特殊字符的参数改成了没有特殊字符的参数，那接下来执行查询sql就可以了。

SELECT Description as '场景',
  JSON_VALUE (Document,'$.jobs.load.results.cpu') AS 'CPU使用率(%)',
  JSON_VALUE (Document,'$.jobs.load.results.cpuRaw') AS '多核CPU使用率(%)',
  JSON_VALUE (Document,'$.jobs.load.results.workingSet') AS '内存使用(MB)',
  JSON_VALUE (Document,'$.jobs.load.results.privateMemory') AS '进程使用的私有内存量(MB)',
  ROUND(JSON_VALUE (Document,'$.jobs.load.results.totalRequests'),0) AS '总发送请求数',
  ROUND(JSON_VALUE (Document,'$.jobs.load.results.badResponses'),0) AS '异常请求数',
  ROUND(JSON_VALUE (Document,'$.jobs.load.results.requestSec'),0) AS '每秒支持请求数',
  ROUND(JSON_VALUE (Document,'$.jobs.load.results.requestSecMax'),0) AS '每秒最大支持请求数',
  ROUND(JSON_VALUE (Document,'$.jobs.load.results.latencyMean'),0) AS '平均延迟时间(us)',
  ROUND(JSON_VALUE (Document,'$.jobs.load.results.latencyMax'),0) AS '最大延迟时间(us)',
  CONVERT(varchar(100),DATEADD(HOUR, 8, DateTimeUtc),20)  as '时间'
FROM dev;

3. 如何分析瓶颈

通过上面的操作，我们已经可以轻松的完成对场景的压测，并能快速生成相对应的报表信息，那正题来了，可以模拟高并发场景，那如何分析瓶颈呢？毕竟报告只是为了知晓当前的系统指标，而我们更希望的是知道当前系统的瓶颈是多少，怎么打破瓶颈，完成突破呢……

首先我们要先了解我们当前的应用的架构，比如我们现在使用的是微服务架构，那么

应用拆分为几个服务？了解清楚每个服务的作用
服务之间的调用关系
各服务依赖的基础服务有哪些、基础服务基本的信息情况

举例我们当前的微服务架构如下：

通过架构图可以快速了解到项目结构，我们可以看到用户访问web端，web端根据请求对应去查询redis或者通过http、grpc调用服务获取数据、各服务又通过redis、db获取数据。

首先我们先通过crank把当前的数据指标保存入库。调出其中不太理想的接口开始分析。

在这里我们拿两个压测接口举例：

获取首页Banner、QPS：3800 /s (Get)
下单、QPS：8 /s (Post)

3.1. 获取首页Banner

通过单测首页banner的接口，QPS是3800多不到4000这样，虽然这个指标还不错，但我们仍然觉得很慢，毕竟首页banner就是很简单几个图片+标题组合的数据，数据量不大，并且是直连Redis，仅在Redis不存在时才查询对应服务获取banner数据，这样的QPS实在不应该，并且这个还是仅压测单独的banner，如果首页同时压测十几个接口，那其性能会暴降十倍不止，这样肯定是不行的

我们又压测了一次首页banner接口，发现有几个疑点：

redis请求数徘徊在3800左右的样子，网络带宽占用1M的样子，无法继续上涨
查看web服务，发现时不时的会有调用服务超时出错的问题，Db的访问量有上涨，但不明显，很快就下去了

思考: Redis的请求数与最后的压测结果差不多，最后倒也对上了，但为什么redis的请求数这么低呢？难道是带宽限制！！

虽然是单机redis，但4000也绝对不可能是它的瓶颈，怀疑是带宽被限制了，应该就是带宽被限制了，后来跟运维一番切磋后，得到结论是redis没限制带宽……

那为什么不行呢，这么奇怪，redis不可能就这么点并发就不行了，算了还是写个程序试一下吧，看看是不是真的测试环境不给力，redis配置太差了，一番操作后发现，同一个redis数据，redis读可以到6万8，不到7万、带宽占用10M，redis终于洗清了它的嫌疑，此接口的QPS不行与Redis无关，但这么简单的一个结构为什么QPS就上不去呢……，如果不是redis的问题，那会不会是因为请求就没到redis上，是因为压测机的强度不够，导致请求没到redis……当时冒出来这个有点愚蠢的想法，那就增加压测机的数量，通过更改负载压测机配置，1台压测机升到了3台，但可惜的是单台压测机的指标不升反降，最后所有压测机的指标加到一起正好与之前一台压测机的压测结果差不多一样，那说明QPS低与压测机无关，后来想到试试通过增加多副本来提升QPS，后来web副本由1台提升到了3台，之前提到的服务调用报错的情况更加严重，之前只是偶尔有一个错误，但提升web副本后，看到一大片的错误

提示Thread is busy，很多线程开始等待
大量的服务调用超时，DB查询缓慢

最后QPS 1000多一点，有几千个失败的错误，这盲目的提升副本貌似不大有效，之前尽管Qps不高，但起码也在4000,DB也没事，这波神操作后QPS直降4分之3，DB还差点崩了，思想滑坡了，做了负优化……

继续思考，为何提升副本，QPS不升反降，为何出现大量的调用超时、为何DB会差点被干崩，我只是查询个redis，跟DB有毛关系啊！奇了怪了，看看代码怎么写的吧……烧脑

public async Task<List<BannerResponse>> GetListAsync()
{
  List<BannerResponse> result = new List<BannerResponse>();
  try
  {
    var cacheKey = "banner_all";
    var cacheResult = await _redisClient.GetAsync<List<BannerResponse>>(cacheKey);
    if (cacheResult == null)
    {
      result = this.GetListServiceAsync().Result;
      _redisClient.SetAsync(cacheKey, result, new()
      {
        DistributedCacheEntryOptions = new()
        {
          AbsoluteExpirationRelativeToNow = TimeSpan.FromDays(5)
        }
      }).Wait();
    }
    else
    {
      result = cacheResult;
    }
	}
  catch (Exception e)
  {
    result = await this.GetListServiceAsync();
  }

  return result;
}

看了代码后发现，仅当Reids查询不到的时候，会调用对应服务查询数据，对应服务再查询DB获取数据，另外查询异常时，会再次调用服务查询结果，确保返回结果一定是正确的，看似没问题，但为何压测会出现上面那些奇怪现象呢……

请求超时、大量等待，那就是正好redis不存在，穿透到对应的服务查询DB了，然后压测同一时刻数据量过大，同一时刻查询到的Reids都是没有数据，最后导致调用服务的数量急剧上升，导致响应缓慢，超时加剧，线程因超时释放不及时，又导致可用线程较少。

这块我们查找到对应的日志显示以下信息

System.TimeoutException: Timeout performing GET MyKey, inst: 2, mgr: Inactive, queue: 6, qu: 0, qs: 6, qc: 0, wr: 0, wq: 0, in: 0, ar: 0,
IOCP: (Busy=6,Free=994,Min=8,Max=1000), 
WORKER: (Busy=152,Free=816,Min=8,Max=32767)

那么我们可以调整Startup.cs：

public void ConfigureServices(IServiceCollection services)
{
  ThreadPool.GetMinThreads(out int workerThreads, out int completionPortThreads);
  ThreadPool.SetMinThreads(1000, completionPortThreads);//根据情况调整最小工作线程，避免因创建线程导致的耗时操作

  ……………………………………………………………此处省略…………………………………………………………………………………………………………
}

web服务调用底层服务太慢，那么提升底层服务的响应速度（优化代码）或者提高处理能力（提升副本）
防止高并发情况下全部穿透到下层，增加底层服务的压力

前两点也是一个好的办法，但不是最好的解决办法，最好还是不要穿透到底层服务，如果reids不存在，就放一个请求过去是最好的，拿到数据就持久化到redis，不要总穿透到下层服务，那么怎么做呢，最简单的办法就是使用加锁，但加锁会影响性能，但这个我们能接受，后来调整加锁测试，穿透到底层服务的情况没有了，但很可惜，请求数确实会随着副本的增加而增加，但是实在是有点不好看，后来又测试了下另外一个获取缓存数据的结果，结果QPS：1000多一点，比banner还要低的多，两边明明都使用的是Reids，性能为何还有这么大的差别，为何我们写的redis的demo就能到6万多的QPS，两边都是拿的一个缓存，差距有这么大？难道是封装redis的sdk有问题？后来仔细对比了后来写的redis的demo与banner调用redis的接口发现，一个是直接查询的redis的字符串，一个是封装redis的sdk，多了一个反序列化的过程，最后经过测试，反序列化之后性能降低了十几倍，好吧看来只能提升副本了……但为何另外的接口也是从redis获取，性能跟banner的接口不一样呢！！

经过仔细对比发现，差别是信息量，QPS更低的接口的数据量更大，那结果就有了，随着数据量的增加，QPS会进一步降低，那这样一来的话，增加副本的作用不大啊，谁知道会不会有一个接口的数据量很大，那性能岂不是差的要死，那还怎么玩，能不能提升反序列化的性能或者不反序列化呢，经过认真思考，想到了二级缓存，如果用到了二级缓存，内存中有就不需要查询redis，也不需要再反序列化，那么性能应该有所提升，最后的结构如下图：

最后经过压测发现，单副本QPS接近50000，比最开始提升12倍，并且也不会出现服务调用超时，DB崩溃等问题、且内存使用平稳

此次压测发现其banner这类场景的性能瓶颈在反序列化，而非Redis、DB，如果按照一开始不清楚其工作原理、盲目的调整副本数，可能最后会加剧系统的雪崩，而如果我们把DB资源、Redis资源盲目上调、并不会对最后的结果有太大帮助，最多也只是延缓崩溃的时间而已

3.2. 下单

下单的QPS是8，这样的QPS已经无法忍受了，每秒只有十个请求可以下单成功，如果中间再出现一个库存不足、账户余额不足、活动资格不够等等，实际能下单的人用一个手可以数过来，真的就这么惨……虽然下单确实很费性能，不过确实不至于这么低吧，先看下下单流程吧

简化后的下单流程就这么简单，web通过dapr的actor服务调用order service，然后就是漫长的查询db、操作redis操作，因涉及业务代码、具体代码就不再放出，但可以简单说一下其中做的事情，检查账户余额、反复的增加redis库存确保库存安全、检查是否满足活动、为推荐人计算待结算佣金等等一系列操作，整个看下来把人看懵了，常常是刚看了上面的，看下面代码的时候忘记上面具体干了什么事，代码太多了，一个方法数千行，其中再调用一些数百行的代码，真的吐血了，不免感叹我司的开发小哥哥是真的强大，这么复杂的业务居然能这么"顺畅"的跑起来，后面还有N个需求等待加到下单上，果然不是一般人

不过话说回来，虽然是业务是真的多，也真的乱，不过这样搞也不至于QPS才只有8这么可怜吧，服务器的处理能力可不是二十几年前的电脑可以比拟的，单副本8核16G的配置不支持这么拉胯吧，再看一下究竟谁才是真正的幕后黑手……

但究竟哪里性能瓶颈在哪里，这块就要出杀手锏了

通过Tracing可以很清楚的看到各节点的耗时情况，这将对我们分析瓶颈提供了非常大的帮助、我们看到了虽然有几十次的查询DB操作，但DB还挺给力，基本也再很短时间内就给出了响应，那剩余时间耗费到了哪里呢？我们看到整体耗时11s、但查询Db加起来也仅仅不到1s，那么剩余操作都在哪里？要知道哪怕我们优化DB查询性能，减少DB查询，那提升的性能对现在的结果也是微乎其微

结合Tracing以及下单流程图，我们发现从Web到Order Service是通过actor来实现的，那会不是这里耗时影响的呢？

但dapr是个新知识、开发的小哥哥速度真快，这么快就用上dapr了（ˇˍˇ）不知道小哥哥的头发还有多少……

快速去找到下单使用actor的地方，如下:

[HttpPost]
[Authorize]
public async Task<CreateOrderResponse> CreeateOrder([FromBody] CreateOrderModel request)
{
    string actionType = "SalesOrderActor";
    var salesOrderActor = ActorProxy.Create<ISalesOrderActor>(new ActorId(request.SkuList.OrderBy(sku => sku.Sku).FirstOrDefault().Sku), actionType);
    request.AccountId = Account.Id;
    var result = await salesOrderActor.CreateOrderAsync(request);
    return new Mapping<ParentSalesOrderListViewModel, CreateOrderResponse>().Map(result);
}

我们看到了这边代码十分简单，获取商品信息的第一个sku编号作为actor的actorid使用，然后得到下单的actor，之后调用actor中的创建订单方法最后得到下单结果，这边的代码太简单了，让人心情愉快，那这块会不会有可能影响下单速度呢？它是不是那个性能瓶颈最大的幕后黑手？

首先这块我们就需要了解下什么是Dapr、Actor又是什么，不了解这些知识我们只能靠抓阄来猜这块是不是瓶颈了……

Dapr 全称是Distributed Application Runtime，分布式应用运行时，并于今年加入了 CNCF 的孵化项目，目前Github的star高达16k，相关的学习文档在文档底部可以找到，我也是看着下面的文档了解dapr

通过了解actor，我们发现用sku作为actorid是极不明智的选择，像秒杀这类商品不就是抢的指定规格的商品吗？如果这样一来，这不是在压测actor吗？这块我们跟对应的开发小哥哥沟通了下，通过调整actorid顺利将Qps提升到了60作用，后面又通过优化减少db查询、调整业务规则的顺序等操作顺利将QPS提升到了不到一倍，虽然还是很低，不过接下来的优化工作就需要再深层次的调整业务代码了……

4. 总结

通过实战我们总结出分析瓶颈从以下几步走：

通过第一轮的压测获取性能差的接口以及指标
通过与开发沟通或者自己查看源码的方式梳理接口流程
通过分析其项目所占用资源情况、依赖第三方基础占用资源情况以及Tracing更进一步的确定瓶颈大概的点在哪几块
通过反复测试调整确定性能瓶颈的最大黑手
将最后的结论与相关开发、运维人员沟通，确保都知晓瓶颈在哪里，最后优化瓶颈

知识点：

Dapr
- 手把手教你学Dapr系列
Tracing
- OpenTracing 简介、关于OpenTracing后续我们也会开源，可以提前关注我们的开源项目
  - Masa.BuildingBlocks
  - Masa.Contrib

开源地址

MASA.BuildingBlocks：https://github.com/masastack/MASA.BuildingBlocks

MASA.Contrib：https://github.com/masastack/MASA.Contrib

MASA.Blazor：https://github.com/BlazorComponent/MASA.Blazor

如果你对我们的 MASA Framework 感兴趣，无论是代码贡献、使用、提 Issue，欢迎联系我们

5. 堪比JMeter的.Net压测工具 - Crank 实战篇 - 接口以及场景压测

MASA技术团队 — 2023-05-27

1. 前言

通过之前的学习，我们已经掌握了crank的配置以及对应http基准工具bombardier、wrk、wrk2的用法，本篇文章介绍一下如何将其用于实战，在实际的项目中我们如何使用crank来完成压测任务。

2. 项目背景

目前有一个项目，我们希望通过压测来了解其QPS、吞吐量、以及临界值，并通过压测来分析出其瓶颈在哪里？并通过解决瓶颈问题以提高QPS、吞吐量等指标

先看下我们手头掌握了什么：

项目信息
- 项目中的接口基本都需要登录
- 通过与开发沟通可以得到每个页面的接口信息以及参数信息
环境信息
- 压测项目有单独的环境部署应用、Redis、数据库等基础配置

此处项目名我们暂定为ProjectA。

3. 如何开展

首先我们先回顾一下Agent、Controller的职责以及特点

Controller
- 做任务调度以及结果输出
- 无需单独服务器，可以在本机执行发送命令，需要与Agent相通
Agent
- 任务的实际执行者
- 单任务执行，不能做到接收到多个任务并同时执行，先收到哪个任务，哪个任务会先执行
- 相同一个任务可以被多个Agent同时执行，最终指标结果会自动累加，可以通过提升Agent来模拟更高的并发能力

3.1. 思路

先做好单独接口的压测，大概掌握每个接口的指标情况
同时压测多个接口，完成对场景的压测
通过压测观察应用服务器、基础服务器的CPU、带宽、内存等指标，观察Redis、数据库、消息队列等基础组件情况，根据压测的返回结果得到每个场景的基础指标
通过分析发现瓶颈、然后再考虑如何突破瓶颈，提升QPS、吞吐量等

3.2. 如何做？

了解到单个Agent同时执行多个任务会进行排队，无法做到多任务同时执行，那么我们可以通过多个Agent同时执行不同的任务来模拟用户访问页面。

3.2.1. 构建Agent

之前与开发沟通得到每个页面最多可发送的请求是6个，那么我们准备6个Agent，分别为Agent1、Agent2、Agent3、Agent4、Agent5、Agent6

我们这里使用Docker来启动Agent、Agent对内开放端口: 5010、对外端口随机，镜像使用我们自建的: doddgu/crankagent:net5.0

并新建load.yml为之后压测使用:

profiles:
  crankAgent1:
    jobs:
      load:
        endpoints:
          - http://localhost:5010
  crankAgent2:
    jobs:
      load:
        endpoints:
          - http://localhost:5011
  crankAgent3:
    jobs:
      load:
        endpoints:
          - http://localhost:5012
  crankAgent4:
    jobs:
      load:
        endpoints:
          - http://localhost:5013
  crankAgent5:
    jobs:
      load:
        endpoints:
          - http://localhost:5014
  crankAgent6:
    jobs:
      load:
        endpoints:
          - http://localhost:5015

load.yml 中记录了所有的压测机信息，其信息一般不做修改，我们可以作为公共的配置来使用无需每个项目都单独维护一份新的

3.2.2. 构建压测脚本

在这里我们选择wrk2作为本次基准测试工具，选择wrk2的原因是：

支持随机参数
可支持设置恒定的吞吐量负载
具备wrk的所有功能

此时我们针对ProjectA项目新建配置：project.profiles.yml，作为本次压测的环境配置来使用，其配置如下

imports:
  - https://raw.githubusercontent.com/doddgu/crank/sample/samples/wrk2/common/load.profiles.yml # 这边建议使用远程load.profiles.yml地址。(如果输入的是本地路径、则需输入与当前命令所在路径的相对路径)

profiles:

  local: # 本地环境
    variables:
      serverAddress: localhost # 应用服务域
      serverPort: 80 # 应用服务端口
      connections: 256 # 每个线程处理时保持打开的 HTTP 连接总数 N = 连接数/线程数
      threads: 32 # 线程数
      warmup: 3 # 预热时间: 3s
      duration: 180 # 测试时长: 3分钟
      rate:  # 吞吐量参数（每秒总请求数）

project.profiles.yml中记录了指定项目的各环境的配置，项目自己独立维护即可

除了项目信息、压测机配置之外，我们还需要有地方维护我们压测的接口信息，这边我的做法是将api独立拆分出来，每个yml只配置一个接口的压测信息，至于为什么不放到一块，而要单独拆分开呢？

这块考虑到我们压测的最小单元是API接口，如果把API接口独立拆分开，那么可以对单接口压测，而如果我们需要场景压测，也可以通过组合接口完成多接口同时压测，并且一旦我们完成了某个接口的压测编写，后续不需要再改动这个配置，如果我们按照场景拆分成不同的yml，在yml中再根据定义不同的scenario来做，那么后续场景新增加接口，还需要再更改这个场景的yml，并且scenario中的场景实际上也是根据接口维度区分的，目前crank并不能完成单个场景任务同时处理，基于以上原因，这边我们新调整好的配置格式为：

新增load.benchmarks.yml

imports:
  - https://raw.githubusercontent.com/doddgu/crank/sample/src/Microsoft.Crank.Jobs.Wrk2/wrk2.yml
  - https://raw.githubusercontent.com/doddgu/crank/sample/samples/wrk2/common/project.profiles.yml

jobs:
  server:
    source:
      repository: https://github.com/doddgu/crank
      branchOrCommit: sample
      project: samples/hello/hello.csproj
    readyStateText: Application started.

scenarios:
  api:
    application: # 实际压测项目时可移除此节点，此处是为模拟应用服务启动
      job: server
      variables:
        duration: 1
    load:
      job: wrk2
      variables:
        serverPath: /user/get
        script: request.lua
        duration: 1

profiles:
  defaultParamLocal: # 本地环境的参数信息
    variables: 
      serverQueryString: ?id={1}
      serverQueryParameter: 1||2 # 随机请求/get?id=1、/get?id=2

按照此格式保存，后续新增接口也可以快速复制，简单修改即可快速完成压测工作的编写，这样一来，如果我们希望对localhost:5000/user/get这个接口做压测，仅需要在crank控制端输入：

crank --config load.benchmarks.yml --scenario api --load.framework net5.0 --application.framework net5.0 --profile local --profile crankAgent1 --description "获取用户详情" --profile defaultParamLocal

3.2.3. 构建批处理命令

但作为一个开发人员，总是希望事情能更简单一点，每次输入命令太麻烦了，所以就想到了通过批处理快速完成任务的发送，最终的项目结构就变成了

benchmarks
├─ defaultTitle              接口名称( Description )
└─ load.bat                  最终执行的脚本，其中指定了要指定的yml配置、场景、以及任务环境是.net 5.0
└─ load.benchmarks.yml       yml配置
└─ load.local.bat            测试本地环境时要执行的脚本、格式：load.{环境}.bat
└─ README.md                 帮助文档

每次通过双击load.{环境}.bat就完成了对当前接口的压力测试，然后就是等待结果输出……

| application           |                |
| --------------------- | -------------- |
| CPU Usage (%)         | 1              |
| Cores usage (%)       | 10             |
| Working Set (MB)      | 85             |
| Private Memory (MB)   | 278            |
| Build Time (ms)       | 3,469          |
| Start Time (ms)       | 352            |
| Published Size (KB)   | 93,323         |
| .NET Core SDK Version | 5.0.404        |
| ASP.NET Core Version  | 5.0.13+55738ff |
| .NET Runtime Version  | 5.0.13+b3afe99 |


| load                  |                |
| --------------------- | -------------- |
| Build Time (ms)       | 3,281          |
| Start Time (ms)       | 0              |
| Published Size (KB)   | 74,276         |
| .NET Core SDK Version | 5.0.404        |
| ASP.NET Core Version  | 5.0.13+55738ff |
| .NET Runtime Version  | 5.0.13+b3afe99 |
| First Request (ms)    | 86             |
| Requests/sec          | 2              |
| Requests              | 2              |
| Mean latency (ms)     | 2.68           |
| Max latency (ms)      | 2.68           |
| Bad responses         | 0              |
| Socket errors         | 0              |
| Latency 50th (ms)     | 2.68           |
| Latency 75th (ms)     | 2.68           |
| Latency 90th (ms)     | 2.68           |
| Latency 99th (ms)     | 2.68           |
| Latency 99.9th (ms)   | 2.68           |
| Latency 99.99th (ms)  | 2.68           |
| Latency 99.999th (ms) | 2.68           |

3.2.4. 构建场景压测批处理命令

通过上面的一番操作，我们已经可以很容易的对单接口进行压测，但目前想模拟完成多接口同时压测，还需要再改造一下，之前我们想到，crank目前只能完成单独压测任务，那是不是有多个Agent，每个Agent单独压测一个接口，并同时启动多个Agent同时压测是不是可以模拟出来场景压测，那我通过批处理任务多点几次不同的接口压测不就可以了，基于以上考虑，又做了一个批处理脚本，用于调用多个接口的压测任务启动，最后的结构如下所示：

Crank
├─ benchmarks                压测脚本
│  ├─ api                   接口压测脚本               
│  │  ├─ add               
│  │  └─ get                  
│  ├─ scipts               lua脚本             
│  │  ├─ common            lua公共脚本
│  │  │  ├─ oauth.lua     认证lua脚本
│  │  │  ├─ util.lua      lua工具类脚本
│  │  ├─ request.lua       封装请求lua脚本   
│  ├─ scripts.tar           lua脚本压缩包
├─ common                            
│  ├─ load.profiles.yml     agent 负载机配置
│  ├─ project.profiles.yml  项目配置
│  ├─ scripts.profiles      crank 执行script配置，用于对输出结果的二次处理
│  ├─ project.profiles.yml  项目配置
├─ scripts                   场景压测脚本
│  ├─ 用户.bat              用户压测     
└─ env                       环境配置，标记当前需要压测的环境在哪个配置文件中存储
└─ env.local                 本地环境，存储本地环境的配置信息
└─ README.md                 帮助文档

4. 结尾

通过上面的操作我们已经完成了对单接口以及单场景的压测，通过控制台可以清晰的看到每个接口的压测结果，我们只需要耐心等待压测任务结束，并整理压测结果数据，最后进行汇总我们的任务就完成了，但压测结果的收集也是一个费事费力的工作，作为一个开发，是不想把时间花费到这些整理表格的事情上，那我们如何做可以把整理表格数据的工作节省下来让我们可以歇会儿呢……

源码地址：https://github.com/doddgu/crank/tree/sample/samples/wrk2

参考链接：

https://www.cnblogs.com/xinzhao/p/6233009.html

开源地址

MASA.BuildingBlocks：https://github.com/masastack/MASA.BuildingBlocks

MASA.Contrib：https://github.com/masastack/MASA.Contrib

MASA.Blazor：https://github.com/BlazorComponent/MASA.Blazor

如果你对我们的 MASA Framework 感兴趣，无论是代码贡献、使用、提 Issue，欢迎联系我们

4. 堪比JMeter的.Net压测工具 - Crank 进阶篇 - 认识wrk、wrk2

MASA技术团队 — 2023-05-27

1. 前言

上一篇文章我们了解了bombardier，并知道了bombardier.yml与开源项目bombardier的关系，接下来的文章我们了解一下wrk、wrk2，并对比一下它们与bombardier的关系

2. 认识wrk

wrk是一种现代 HTTP 基准测试工具，能够在单个多核 CPU 上运行时产生大量负载。它结合了多线程设计和可扩展的事件通知系统，例如 epoll 和 kqueue。

其支持参数：

-c, --connections: total number of HTTP connections to keep open with
                   each thread handling N = connections/threads

-d, --duration:    duration of the test, e.g. 2s, 2m, 2h

-t, --threads:     total number of threads to use

-s, --script:      LuaJIT script, see SCRIPTING

-H, --header:      HTTP header to add to request, e.g. "User-Agent: wrk"

    --latency:     print detailed latency statistics

    --timeout:     record a timeout if a response is not received within
                   this amount of time.

基础用法：

运行了30秒的基准测试, 使用2个线程、100个http连接:

wrk -t2 -c100 -d30s http://127.0.0.1:8080/index.html

进阶用法:

每次发送三个http请求:

wrk -t2 -c100 -d30s --script ./pipeline.lua http://127.0.0.1:8080

新建pipeline.lua

-- example script demonstrating HTTP pipelining

init = function(args)
   local r = {}
   r[1] = wrk.format(nil, "/?foo")
   r[2] = wrk.format(nil, "/?bar")
   r[3] = wrk.format(nil, "/?baz")

   req = table.concat(r)
end

request = function()
   return req
end

3. 认识wrk2

wrk2是一个主要基于 wrk 的 HTTP 基准测试工具。是一个被 wrk 修改以产生恒定的吞吐量负载，并将延迟细节精确到高 9s（即当运行足够长的时间时可以产生准确的 99.9999%'ile）。除了 wrk 的参数之外，wrk2 通过 --rate 或 -R 参数（默认为 1000）采用吞吐量参数（每秒总请求数）

除支持wrk的参数之外，还支持参数：

-R, --rate: 采用吞吐量参数（每秒总请求数）,默认为1000

基础用法：

运行了30秒的基准测试, 使用2个线程、100个http连接、并保持每秒2000个请求的恒定吞吐量:

wrk -t2 -c100 -d30s -R2000 http://127.0.0.1:8080/index.html

高级用法与wrk一致，此处忽略不写

我们使用wrk2测试一下百度的压测情况

安装：

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

运行：

./wrk2 -d 3s -c 200 -t 200 -R 10 -L https://www.baidu.com

输出了本次请求每秒请求次数、吞吐量以及详细情况：

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

4. 了解Microsoft.Crank.Jobs.Wrk

在Microsoft.Crank.Jobs.Wrk项目中Program.cs

检查平台是否是64位的Linux系统、并检查参数是否满足要求
通过HttpClient发送请求，并记录第一次发送请求所消耗的时间
下载wrk，并设置wrk是可执行的
通过yml传递过来的参数构建完整的wrk命令
将输出的结果使用追加到stringBuilder上，再赋值给output，
通过正则匹配结果，最后通过BenchmarksEventSource存储并输出到控制台或数据库、csv、json中

其中:

connections: 每个线程处理时保持打开的 HTTP 连接总数 N = 连接数/线程数
serverUri: 自定义url，如果此参数存在，则请求地址为: {serverUri}:{serverPort}{path}
serverPort: 服务端口
serverScheme: 服务的Scheme，默认http、支持http、https两种
serverAddress: 服务地址、不包含http、例如: www.baidu.com，如果serverUri存在，此配置无效，如果不存在，请求格式为: {serverScheme}://{serverAddress}:{serverPort}{path}
path: 服务接口地址，不包含域，例如: /api/check/healthy
warmup: 预热时间，默认15s，与执行duration类似，而并非压测次数
- 当warmup > 0时，会先预热warmup秒后再执行一次压测，第二次的压测才是最后返回的结果
- 当warmup = 0时，不进行预热，直接开始压测
duration: 测试时长，默认15s
threads: 线程数、默认：32
customHeaders: 自定义headers，如果预设headers中没有需要的header，则通过重写customHeaders，以完成自定义header的目的
pipeline: 管道数量，默认为1，当大于1时，支持同时发送多个请求
script: 如果pipeline不大于1时，支持自定义lua脚本以及lua参数{scriptArguments}

5. 总结

优势:

支持lua脚本，支持动态参数或者更改请求等复杂操作
使用C语言开发、性能高

劣势:

lua脚本存在学习成本

wrk.yml的存在是为Microsoft.Crank.Jobs.Wrk提供配置参数，Microsoft.Crank.Jobs.Wrk通过调用开源项目wrk实现压测，并将压测结果通过BenchmarksEventSource存储并输出到控制台或数据库、csv、json中

wrk2是基于wrk二次开发，拥有所有wrk的配置，并且支持吞吐量限制，bombardier、wrk、wrk2都是http基准测试工具，丰富了crank对于Http的基准测试能力，三者之间并无优劣之分，根据三者之间的优劣势自行选择适合自己的即可

开源地址

MASA.BuildingBlocks：https://github.com/masastack/MASA.BuildingBlocks

MASA.Contrib：https://github.com/masastack/MASA.Contrib

MASA.Blazor：https://github.com/BlazorComponent/MASA.Blazor

如果你对我们的 MASA Framework 感兴趣，无论是代码贡献、使用、提 Issue，欢迎联系我们

3 步排查，3 步优化，探针性能损耗直降 44%

数列科技 — 2023-05-27

应用接探针除了安全问题，最担心的就是占用系统性能影响业务正常运转，今天分享一个实际案例告诉大家如何来降低探针的性能损耗。下表为某用户的2条核心链路在200并发压测下的性能数据对比，可以看见在接入探针后性能损耗居高不下。

3步快速排查

1.对比链路差异

首先想到的排查方案是通过skywalking监控进行排查，对比应用在接入探针和未接入探针的情况下，性能表现的差异在哪，具体的的性能消耗在哪个中间件。在对比skywalking监控的链路耗时，确实可以观察到未接入探针比接入探针和链路的RT高，但是不清楚是否存在客户环境问题或者skywallking上的链路有断裂的问题，信息并不全面无法准确定位。

2.插件排除法

在无其它有效信息时，尝试通过排除法定位具体影响性能的插件。具体做法是先整理链路用到的中间件，先移除所有中间件插件，再逐一增加单个中间件插件，不断的进行压测，观察哪个插件对性能的影响比较大。依靠这个方法定位成功到dubbo与logback两个插件，它们对性能影响比较大。

3.性能数据收集

在压测测试的同时，我们在agent框架内增加了对中间件插件interceptor方法执行的耗时统计代码，这部分数据会统一输出到固定的日志文件中。此外我们开发了与之配套的性能日志分析程序，配合日志收集脚本，可以对整个链路的所有应用打印的性能数据进行分析，输出汇总出一份中间件interceptor的统计结果，这份结果可以直观的看到每个中间件的性能耗时占比。 统计结果样例：

性能收集代码展示：

3步具体优化

1.减少切点

agent产生性能损耗的终归原因是因为agent增强中间件代码后，会修改目标类的字节码，植入一些额外的逻辑，正是这些额外的逻辑带来了额外的耗时。切点越多植入的逻辑越多，整个链路的损耗就可能越高，所以尽可能的减少切点的数量一定会减少性能损耗。按照这个思路，我们将前面排查出来耗时占比较高的logback中间件进行了重新设计。原先logback的实现有三个切点，分别负责：影子appender的注册、流量标识、日志隔离，经过重新设计后，优化为一个切点实现所有功能。

2.静默&业务流量过滤

尽管中间件插件的增强逻辑不尽相同，但agent在植入到目标类的字节码都是统一的。他们都有统一入口，前置的运行逻辑都是同一套框架，实际运行时序图如下：

实际上有很多Interceptor的增强逻辑只有压测流量时才会执行，可这部分interceptor的执行全部需要经过前面从Messager到AdviceListener的一系列调用，这是完全没有必要并且会带来一定的性能损耗。这种无用调用可以在最前端做个判断，从开始就过滤掉，在达到效果的同时降低性能损耗。

为此我们对框架进行了改造，让类似这种interceptor能在最前端就把流量过滤掉，避免执行无意义的逻辑。同时在最前端增加了静默开关，静默开关可以一键禁用掉所有中间件增强逻辑的执行，一定程度上可以代替卸载操作。相比卸载来说它不会还原实际的字节码，也不会回收内存占用，但是会更加轻量级，响应更快，影响更小。 改造后的运行时序图：

3.中断逻辑优化

对logback插件进行重新设计后产生了一定效果，但是从性能采集的数据来看，性能损耗占比最高的还是logback插件。经过反复斟酌发现logback本身已经没有在进一步优化的空间了，于是将目光转向了框架层面，最后将重点放在了优化CutoffInterceptor类型中断机制。 CutoffInterceptor是一个类似挡板的Interceptor，它可以中断源码本身的运行，并且支持对返回值替换。比如数据库隔离的实现，我们一般会实现一个CutoffInterceptor，在压测流量经过时返回影子数据库的connection代替业务connection，以实现数据的隔离。logback同样也是实现了一个CutoffInterceptor，在压测流量经过时返回影子的appender替换业务的appender实现日志隔离。 CutoffInterceptor内部的实现原理是通过异常机制实现的，在替换返回值时，实际上是抛出了一个异常由上层捕获，实现对源代码的中断。

众所周知，在java中通过抛出实现流程控制的效率其实是比较低的，我们内部测试验证也证实了这点，一个空逻辑的CutoffInterceptor和同样的一个空逻辑Interceptor的性能差距相差几十近百倍。恰好logback这种日志类型的中间件执行频率是非常高的，所以导致这块的性能损耗一直下不去。于是我们把CutoffInterceptor的中断机制进行了优化，抛出异常改为了先advice设置中断标记，再由上层判断去控制中断。

最终结果

经过一系列的优化动作之后，两条核心链路的性能损耗都有了大幅度的提升，链路A性能损耗由48%下降至4%，链路B的性能损耗由35%下降至3.4%。

阿里巴巴在开源压测工具 JMeter 上的实践和优化

阿里云云原生 — 2023-05-27

作者：灵苒、涧泉

Apache JMeter [1] 是 Apach 旗下的开源压测工具，创建于 1999 年初，迄今已有超过 20 年历史。JMeter 功能丰富，社区（用户群体）庞大，是主流开源压测工具之一。

性能测试通常集中在新系统上线或大型活动前（如电商大促，春节活动等），以验证系统能力，帮助排查定位性能瓶颈等问题。

一次压测活动可粗略分为几个步骤：

场景配置。配置压测场景模拟用户（业务）与系统的交互。
压测执行。按指定压力量级启动压测。
压测监控分析。压测中通常关注施压 RPS，成功率，业务响应时间（RT），网络带宽等关键指标。
报告总结。披露系统能力是否符合要求，同时沉淀记录系统性能演变和优化过程。

原生 JMeter 实施压测

在 JMeter 的 GUI 页面编辑压测脚本，点击开始按钮调试 JMeter 脚本，具体操作可参考 JMeter官网 [1] 。

对于场景简单，要求测试并发量不高的情况下，JMeter 本地测试就能满足需求。但随着互联网用户的增加，对系统承载更大并发的需求日渐提升，而单台 JMeter 施压机的施压能力有一定上限，所以需要使用多台施压机，以提高 JMeter 的施压能力，这就要使用到 JMeter 的分布式施压功能。

JMeter 的分布式压测需要用户自己管理维护多台机器，使用过程中注意以下几点：

施压机的防火墙已关闭或打开了正确的端口。为 RMI 设置了 SSL 或禁用了它。
所有施压机都在同一个子网上。如果使用 192.xxx 或 10.xxx IP 地址，则服务器位于同一子网中。
所有施压机上使用相同版本的 JMeter 和 Java。
所有施压机都已经拷贝了切分好的 CSV 数据文件、依赖 jar 包等。
压测过程中需要监控施压机是否正常发流量，保持压力与配置一致。
施压前配置好监控数据的收集，方便压测结束后报告的生成。

由此可见 JMeter 的分布式压测需要协调各资源，前置准备以及施压过程维护施压引擎比较麻烦，对实施压测的人员来说压测效率低。

云上的 JMeter 实践

阿里巴巴有着非常丰富的业务形态，每一种业务形态背后都由一系列分布式的技术体系提供服务，随着业务的快速发展，特别是在双 11 等大促营销等活动场景下，准确评估整个业务站点的服务能力成为一大技术难题。

在这个过程中，我们打造了自己的全链路压测系统，以应对更复杂、更多样的压测需求，并将此技术输出到性能测试 PTS 上，同时支持原生 JMeter 压测。

通过控制台实践 JMeter

上传脚本

打开 PTS 控制台 [2] 主页，左侧导航栏选择压测中心 > 创建场景 > JMeter 压测，新建 JMeter 压测场景。填写场景名，如 jmeter-test 。场景配置页面点击上传文件按钮，上传本地测试通过的 test.jmx 脚本。

施压配置

施压配置页面，并发数设置为 50，压测时长设置为 2 分钟。

保存压测

点击保存去压测，弹出提示框点击确认，PTS 即开始在云端引擎执行 JMeter 脚本发起压力。

压测中页面如下：

注意：因为机器配置和网络环境的差异（PTS 施压机默认为 4 核 8G，BGP 多线路公网），PTS 上压测结果可能与本地压测结果存在一定差异。另外，PTS 上的施压配置会覆盖原脚本中的配置，原脚本无论是写死固定配置还是使用 JMeter 属性配置都没关系。

通过 OpenAPI 实践 JMeter

云计算会发展成像水电煤一样，成为社会的基础设施。OpenAPI 好比一条条快速管道，连接着企业和阿里云，把资源源源不断的输送给企业。使用云计算来构建 IT 基础设施是未来的发展趋势，这一点已经成为社会共识。OpenAPI 是云服务开放的重要窗口，没有 OpenAPI 的云服务将很难被客户的系统所集成，既影响了用户体验，也制约了云厂商本身的发展。同样的，在压测领域，随着压测需求日益多样化，更多用户希望将云上的压测能力继承到自己的系统，或者根据自己的业务系统，编排自定义的压测平台，从而实现自动化定制化压测需求。

以下代码实现了使用 PTS 的 OpenAPI 一键启动 JMeter 压测场景，并且在完成压测后查看压测报告。

引入 pom 依赖

<!--创建PTS场景需要的实体类，如果只使用JMeter压测则不需要引入-->
<dependency>
  <groupId>com.aliyun</groupId>
  <artifactId>pts-api-entity</artifactId>
  <version>1.0.1</version>
</dependency>
<!--PTS Java SDK依赖。-->
<dependency>
  <groupId>com.aliyun</groupId>
  <artifactId>pts20201020</artifactId>
  <version>1.8.10</version>
</dependency>
<!--阿里云核心库。-->
<dependency>
  <groupId>com.aliyun</groupId>
  <artifactId>aliyun-java-sdk-core</artifactId>
  <version>4.5.2</version>
</dependency>

复制下列代码

import com.aliyun.pts20201020.Client;
import com.aliyun.pts20201020.models.*;
import com.aliyun.teaopenapi.models.Config;

import java.util.ArrayList;
import java.util.List;
import java.util.Map;


public class StartingDemo {

    public static void main(String[] args) throws Exception {
        Client client = getClient();
        // 创建场景
        String sceneId = createScene(client);
        // 启动场景
        String reportId = startTesting(client, sceneId);
        // 最多等待次数
        int count = 0;
        // 查询是否已生成报告
        while (!hasReport(client, reportId) && count++ < 20) {
            // 若报告还未生成，则等待(30s)一段时间再查询
            // 根据压测时间酌情等待
            Thread.sleep(30 * 1000);
        }
        // 查看报告
        getJMeterReport(client, reportId);
    }

    private static boolean hasReport(Client client, String reportId) throws Exception {
        ListJMeterReportsRequest request = new ListJMeterReportsRequest();
        // 分页设置
        request.setPageNumber(1);
        request.setPageSize(1);
        // 查询条件设置
        request.setReportId(reportId);
        ListJMeterReportsResponse response = client.listJMeterReports(request);
        return response.getBody().getReports().size() > 0;
    }

    private static void getJMeterReport(Client client, String reportId) throws Exception {
        // 查看机器日志
        GetJMeterLogsResponse getJMeterLogsResponse = getJMeterLogs(client, reportId);
        List<Map<String, ?>> logs = getJMeterLogsResponse.getBody().getLogs();
        // 查看采样器聚合数据
        GetJMeterSampleMetricsResponse getJMeterSampleMetrics = getJMeterSampleMetrics(client, reportId);
        List<String> sampleMetricList = getJMeterSampleMetrics.getBody().getSampleMetricList();
        // 查看采样日志
        GetJMeterSamplingLogsResponse getJMeterSamplingLogs = getJMeterSamplingLogs(client, reportId);
        List<String> sampleResults = getJMeterSamplingLogs.getBody().getSampleResults();
    }

    private static GetJMeterSamplingLogsResponse getJMeterSamplingLogs(Client client, String reportId) throws Exception {
        GetJMeterSamplingLogsRequest request = new GetJMeterSamplingLogsRequest();
        // 分页设置
        request.setPageNumber(1);
        request.setPageSize(10);
        // 条件设置
        request.setReportId(reportId);
        GetJMeterSamplingLogsResponse response = client.getJMeterSamplingLogs(request);
        return response;
    }

    private static GetJMeterSampleMetricsResponse getJMeterSampleMetrics(Client client, String reportId) throws Exception {
        GetJMeterSampleMetricsRequest request = new GetJMeterSampleMetricsRequest();
        // 设置报告id
        request.setReportId(reportId);
        GetJMeterSampleMetricsResponse response = client.getJMeterSampleMetrics(request);
        return response;
    }

    private static GetJMeterLogsResponse getJMeterLogs(Client client, String reportId) throws Exception {
        GetJMeterLogsRequest request = new GetJMeterLogsRequest();
        // 分页设置
        request.setPageNumber(1);
        request.setPageSize(10);
        // 查询的压测引擎索引
        request.setReportId(reportId);
        GetJMeterLogsResponse response = client.getJMeterLogs(request);
        return response;
    }

    private static String startTesting(Client client, String sceneId) throws Exception {
        StartTestingJMeterSceneResponse startTestingSceneResponse = startTestingScene(client, sceneId);
        String reportId = startTestingSceneResponse.getBody().getReportId();
        return reportId;
    }

    private static StartTestingJMeterSceneResponse startTestingScene(Client client, String sceneId) throws Exception {
        StartTestingJMeterSceneRequest request = new StartTestingJMeterSceneRequest();
        request.setSceneId(sceneId);
        StartTestingJMeterSceneResponse response = client.startTestingJMeterScene(request);
        return response;
    }

    private static String createScene(Client client) throws Exception {
        SaveOpenJMeterSceneRequest request = new SaveOpenJMeterSceneRequest();
        // 定义场景
        SaveOpenJMeterSceneRequest.SaveOpenJMeterSceneRequestOpenJMeterScene scene = new SaveOpenJMeterSceneRequest.SaveOpenJMeterSceneRequestOpenJMeterScene();
        // 设置场景名
        scene.setSceneName("test");
        // 设置文件列表，包括JMeter脚本、JMeter压测依赖jar包、配置额度数据文件等
        List<SaveOpenJMeterSceneRequest.SaveOpenJMeterSceneRequestOpenJMeterSceneFileList> fileList = new ArrayList<SaveOpenJMeterSceneRequest.SaveOpenJMeterSceneRequestOpenJMeterSceneFileList>();
        // 设置文件的属性 需要设置文件的名称和文件公网可访问的oss地址
        SaveOpenJMeterSceneRequest.SaveOpenJMeterSceneRequestOpenJMeterSceneFileList testFile = new SaveOpenJMeterSceneRequest.SaveOpenJMeterSceneRequestOpenJMeterSceneFileList();
        testFile.setFileName("baidu.jmx");
        testFile.setFileOssAddress("https://pts-openapi-test.oss-cn-shanghai.aliyuncs.com/baidu.jmx");
        fileList.add(testFile);
        scene.setFileList(fileList);
        // 设置场景并发，可设置为100万
        scene.setConcurrency(1000000);
        // 设置引擎数量 说明：一台引擎最多能发500并发，最少1并发所以此处能设置的引擎数为[2,1000]，另外引擎数量越多消耗vum越快
        scene.setAgentCount(2000);
        // 设置压测持续时间 60s
        scene.setDuration(60);
        // 设置测试文件的名称，这个文件需包括在文件列表中
        scene.setTestFile("baidu.jmx");
        request.setOpenJMeterScene(scene);
        SaveOpenJMeterSceneResponse response = client.saveOpenJMeterScene(request);
        return response.getBody().getSceneId();
    }

    private static Client getClient() throws Exception {
        // 填写自己的AK/SK
        String accessKeyId = "ak";
        String accessKeySecret = "sk";
        Config config = new Config();
        config.setAccessKeyId(accessKeyId);
        config.setAccessKeySecret(accessKeySecret);
        Client client = new Client(config);
        return client;
    }
}

填写自己的 ak/sk

在上述代码的 getClient 中填写正确的 ak/sk

点击启动

点击 main 方法启动

通过插件实践 JMeter

对于长期使用 JMeter 的用户来说，学习一款新的压测工具还是需要一定的时间成本。因此，PTS 开发了一款 PTS-JMeter 插件，可帮助 JMeter 用户在不改变原来的压测行为下直接使用 PTS 的压测资源。用户几乎不感知 PTS-JMeter 插件的存在，与原生 JMeter 使用方式一致，保存/打开 JMeter 脚本点击启动压测即可。

下载安装

点击链接下载最新版本 jar 包 [3]

将 jar 包拷贝到 JMeter 主目录下的 lib/ext 扩展目录下

点击压测

新建 JMeter 脚本，或者打开已有 JMeter 脚本，点击 PTS-JMeter 启动按钮开始压测

查看报告

压测过程中，JMeter 图形界面会显示部分压测指标，用户可随时去控制台查看压测进程。压测结束后，PTS 会生成更加详细的压测报告，默认保留 30 天，用户可随时去控制台查看。

其他

PTS-JMeter 插件更详细的使用方式可以去 PTS 帮助文档 [4] 中查看。

压测监控分析

性能测试不仅仅是简单的发起压力，对压力负载（RPS，网络带宽等）和业务表现（RT，成功率等）的监控和分析也是压测活动的重要组成部分。JMeter 脚本中每个请求节点（Sampler）可设置一个具有业务含义的名字（如 home 和 download page ），我们可称之为业务 API 。JMeter 监控统计按业务 API 名字汇总，如两个名字相同的请求节点将汇总统计为一个业务 API 。配置脚本时需注意，不同业务 API 节点应配置为不同的名字。

业务 API 压力负载和表现

实际工作中，不同业务 API 的统计数据可能存在巨大差异（如浏览商品 RT 通常比提交订单快很多），因此 PTS 默认将各个业务 API 独立统计展示（如上述压测中页面展示的 home 和 download page）。

压测中每个时间点的数据 PTS 都在后台记录了下来，最终将形成完整直观的压测报告。点击业务 API 实时监控趋势图按钮，即可查看对应的 RPS，成功率，响应时间，网络带宽等监控数据的变化趋势图。

业务 API 采样日志

很多时候我们还希望看到一个具体请求执行的详细信息。如有 1% 的请求失败，需要查看完整的请求、响应内容，以排查失败原因等。JMeter 图形界面下测试脚本时，可添加 View Results Tree 查看单个请求的详细信息，但执行压力测试时，对每个请求都记录详细信息，不仅没有必要，而且非常耗费资源，影响施压性能。

阿里云 PTS 采取了一个折中的办法，施压引擎间隔一段时间对每个业务 API（压测Sampler）分别采样记录一条成功和失败（如果有）的请求详细信息。在压测中或压测报告页面，点击查看采样日志按钮即可查询记录的请求采样信息，并支持按业务 API（压测Sampler），响应状态（是否成功），请求时间等进行搜索过滤。

点击查看详情即可看到单个请求的详细信息。目前对详细信息提供了通用和 HTTP 两种展示模板，HTTP 展示模板可针对 HTTP 请求进行更友好的排版展示，展示内容包括请求 URL，请求方法，返回码，完整的请求头、请求体，响应头、响应体等。

因为页面上只展示文本内容，请求体或响应体包含图片等无法识别为文本的内容时，可能显示为乱码。另外当请求体或响应体很大时，对应的内容可能被截断。

JMeter 日志

本地执行 JMeter 脚本时，默认将日志记录到 jmeter.log 文件。在 PTS 上执行 JMeter 脚本时，可通过 JMeter 日志页面实时查看 JMeter 日志，并支持根据日志级别、时间或线程名进行查询过滤。

JMeter 日志主要用于脚本执行报错时排查错误原因。一些插件可能通过 JMeter 日志输出一些重要信息，用户在 groovy 脚本等代码中也可以直接打印日志。

报告总结

压测结束后，PTS 将汇总监控数据形成压测报告。用户根据压测报告分析评估系统性能是否符合要求，如 RPS，成功率和 RT（响应时间）是否符合期望。并可辅助用户排查分析业务系统性能瓶颈。

PTS 压测报告页面可查询历史压测报告列表。

点击查看报告打开查看报告详情。压测报告在 PTS 上默认保存 30 天，可点击报告导出按钮，导出保存 PDF 版压测报告到本地。压测报告概要信息包括压测执行时间，RPS，RT，成功率等概要数据。场景详情包含全场景维度和业务 API 维度的监控统计信息。

相比手动命令行执行 JMeter 脚本，PTS 更加简单易用，提供简单直观的监控，并提供海量施压能力。

3. 堪比JMeter的.Net压测工具 - Crank 进阶篇 - 认识bombardier

MASA技术团队 — 2023-05-27

1. 前言

通过之前的学习，我们已经了解了各参数以及配置的意义，接下来的文章我们分别从bombardier以及wrk入手，进一步了解彼此之间的联系

2. 认识 bombardier

bombardier 是一个 HTTP(S) 基准测试工具。它是用 Go 编程语言编写的，并使用优秀的fasthttp代替 Go 的默认 http 库，因为它具有闪电般的快速性能，详细文档查看

其支持参数：

-c, --connections=125       Maximum number of concurrent connections
-t, --timeout=2s            Socket/request timeout
-l, --latencies             Print latency statistics
-m, --method=GET            Request method
-b, --body=""               Request body
-f, --body-file=""          File to use as request body
-s, --stream                Specify whether to stream body using chunked
                            transfer encoding or to serve it from memory
    --cert=""               Path to the client's TLS Certificate
    --key=""                Path to the client's TLS Certificate Private Key
-k, --insecure              Controls whether a client verifies the server's
                            certificate chain and host name
-H, --header="K: V" ...     HTTP headers to use(can be repeated)
-n, --requests=[pos. int.]  Number of requests
-d, --duration=10s          Duration of test
-r, --rate=[pos. int.]      Rate limit in requests per second
    --fasthttp              Use fasthttp client
    --http1                 Use net/http client with forced HTTP/1.x
    --http2                 Use net/http client with enabled HTTP/2.0
-p, --print=<spec>          Specifies what to output. Comma-separated list of
                            values 'intro' (short: 'i'), 'progress' (short:
                            'p'), 'result' (short: 'r'). Examples:

                              * i,p,r (prints everything)
                              * intro,result (intro & result)
                              * r (result only)
                              * result (same as above)
-q, --no-print              Don't output anything
-o, --format=<spec>         Which format to use to output the result. <spec>
                            is either a name (or its shorthand) of some format
                            understood by bombardier or a path to the
                            user-defined template, which uses Go's
                            text/template syntax, prefixed with 'path:' string
                            (without single quotes), i.e.
                            "path:/some/path/to/your.template" or
                            "path:C:\some\path\to\your.template" in case of
                            Windows. Formats understood by bombardier are:

                              * plain-text (short: pt)
                              * json (short: j)

并且bombardier支持多平台，可以在Windows、Linux、OSX系统上运行，那接下来我们使用bombardier测试一下百度的压测情况

安装（WSL-Ubuntu）：

sudo apt install wget
sudo wget https://github.com/codesenberg/bombardier/releases/download/v1.2.5/bombardier-linux-arm64

运行：

./bombardier-linux-arm64  -c 200 -d 1s --insecure -l https://www.baidu.com --print r --format json

其中:

req1xx代表http响应码为1**
req2xx代表http响应码为2**
req3xx代表http响应码为3**
req4xx代表http响应码为4**
req5xx代表http响应码为5**
result.rps.mean代表每秒请求数
result.rps.max代表每秒最大请求数
result.latency.mean代表每毫秒延迟
result.latency.max代表每毫秒最大延迟

3. 了解Microsoft.Crank.Jobs.Bombardier

在Microsoft.Crank.Jobs.Bombardier项目中Program.cs

根据参数获取-w、-d、-n、-f参数信息
校验压测时长、请求数等参数信息
判断当前运行环境是Windows、Linux、OSX，根据环境下载对应的bombardier，并根据传递的
根据yml参数最后拼装bombardier的原始命令:

bombardier -c 200 -d 1s --insecure -l https://www.baidu.com --print r --format json

将输出的结果使用追加到stringBuilder上，再赋值给output
通过JObject.Parse解析指标，最后通过BenchmarksEventSource存储并输出到控制台或数据库、csv、json中

其中

请求总数 = req1xx + req2xx + req3xx + req4xx + req5xx + others
成功请求数 = req2xx + req3xx
失败请求数 = 请求总数 - 成功请求数

BenchmarksEventSource.Register("bombardier/requests;http/requests", Operations.Max, Operations.Sum, "Requests", "Total number of requests", "n0");
BenchmarksEventSource.Register("bombardier/badresponses;http/requests/badresponses", Operations.Max, Operations.Sum, "Bad responses", "Non-2xx or 3xx responses", "n0");

BenchmarksEventSource.Register("bombardier/latency/mean;http/latency/mean", Operations.Max, Operations.Avg, "Mean latency (us)", "Mean latency (us)", "n0");
BenchmarksEventSource.Register("bombardier/latency/max;http/latency/max", Operations.Max, Operations.Max, "Max latency (us)", "Max latency (us)", "n0");

BenchmarksEventSource.Register("bombardier/rps/mean;http/rps/mean", Operations.Max, Operations.Sum, "Requests/sec", "Requests per second", "n0");
BenchmarksEventSource.Register("bombardier/rps/max;http/rps/max", Operations.Max, Operations.Sum, "Requests/sec (max)", "Max requests per second", "n0");
BenchmarksEventSource.Register("bombardier/throughput;http/throughput", Operations.Max, Operations.Sum, "Read throughput (MB/s)", "Read throughput (MB/s)", "n2");

BenchmarksEventSource.Register("bombardier/raw", Operations.All, Operations.All, "Raw results", "Raw results", "json");

var total =
    document["result"]["req1xx"].Value<long>()
    + document["result"]["req2xx"].Value<long>()
    + document["result"]["req3xx"].Value<long>()
    + document["result"]["req3xx"].Value<long>()
    + document["result"]["req4xx"].Value<long>()
    + document["result"]["req5xx"].Value<long>()
    + document["result"]["others"].Value<long>();

var success = document["result"]["req2xx"].Value<long>() + document["result"]["req3xx"].Value<long>();

BenchmarksEventSource.Measure("bombardier/requests;http/requests", total);
BenchmarksEventSource.Measure("bombardier/badresponses;http/requests/badresponses", total - success);

BenchmarksEventSource.Measure("bombardier/latency/mean;http/latency/mean", document["result"]["latency"]["mean"].Value<double>());
BenchmarksEventSource.Measure("bombardier/latency/max;http/latency/max", document["result"]["latency"]["max"].Value<double>());

BenchmarksEventSource.Measure("bombardier/rps/max;http/rps/max", document["result"]["rps"]["max"].Value<double>());
BenchmarksEventSource.Measure("bombardier/rps/mean;http/rps/mean", document["result"]["rps"]["mean"].Value<double>());

BenchmarksEventSource.Measure("bombardier/raw", output);

var bytesPerSecond = document["result"]["bytesRead"].Value<long>() / document["result"]["timeTakenSeconds"].Value<double>();

// B/s to MB/s
BenchmarksEventSource.Measure("bombardier/throughput", bytesPerSecond / 1024 / 1024);

4. 解读bombardier.yml各参数作用

connections: 最大并发连接数，默认: 256
warmup: 预热时间，默认15s，与执行duration类似，而并非压测次数
- 当warmup > 0时，会先预热warmup秒后再执行一次压测，第二次的压测才是最后返回的结果
- 当warmup = 0时，不进行预热，直接开始压测
duration: 测试时长，单位: s
requests: 请求数
rate: 每秒请求数限制
transport: 传输方式。默认: fasthttp 、支持fasthttp、http1、http2三种
presetHeaders: 预设header，根据全局参数headers，自选其一即可，选择json，那请求的header即为: --header "Accept: application/json,text/html;q=0.9,application/xhtml+xml;q=0.9,application/xml;q=0.8,/;q=0.7" --header "Connection: keep-alive"
customHeaders: 自定义headers，如果预设headers中没有需要的header，则通过重写customHeaders，以完成自定义header的目的
serverUri: 自定义url，如果此参数存在，则请求地址为: {serverUri}:{serverPort}{path}
serverPort: 服务端口
serverScheme: 服务的Scheme，默认http、支持http、https两种
serverAddress: 服务地址、不包含http、例如: www.baidu.com，如果serverUri存在，此配置无效，如果不存在，请求格式为: {serverScheme}://{serverAddress}:{serverPort}{path}
path: 服务接口地址，不包含域，例如: /api/check/healthy
bodyFile: body内容，仅在非Get请求时使用，支持远程路径与本地绝对路径（Agent服务的绝对地址，非Controller端的绝对地址）
verb: 请求方式: 默认GET、支持POST、PUT、DELETE、PATCH、GET

5. 总结

优势:

跨平台
用法简单
使用go语言开发、性能高

劣势:

不支持动态参数
不支持多个接口同时压测

bombardier.yml的存在是为Microsoft.Crank.Jobs.Bombardier提供配置参数，Microsoft.Crank.Jobs.Bombardier通过调用开源项目bombardier实现压测，并将压测结果通过BenchmarksEventSource存储并输出到控制台或数据库、csv、json中

开源地址

MASA.BuildingBlocks：https://github.com/masastack/MASA.BuildingBlocks

MASA.Contrib：https://github.com/masastack/MASA.Contrib

MASA.Blazor：https://github.com/BlazorComponent/MASA.Blazor

如果你对我们的 MASA Framework 感兴趣，无论是代码贡献、使用、提 Issue，欢迎联系我们

2. 堪比JMeter的.Net压测工具 - Crank 进阶篇 - 认识yml

MASA技术团队 — 2023-05-27

1. 前言

入门篇我们已经成功运行hello.benchmarks.yml并输出测试结果，本篇我们就hello.benchmarks.yml、以及运行的shell脚本详细解读下其中的含义

2. 剖析hello.benchmarks.yml

2.1. job

在hello.benchmarks.yml中我们定义了一个新的job: server，并指定了仓库信息 ( 远程仓库 )：

    repository：https://github.com/doddgu/crank.git # 仓库源
    branchOrCommit：sample # 分支
    project: samples/hello/hello.csproj # 项目

并通过import导入了bombardier.yml，其中定义了另外一个job: bombardier，并指定了仓库信息 ( 远程仓库 ):

      repository: https://github.com/doddgu/crank.git
      branchOrCommit: sample
      project: src/Microsoft.Crank.Jobs.Bombardier/Microsoft.Crank.Jobs.Bombardier.csproj
      sourceKey: bombardier # 服务器使用它来重用相同的源文件夹。
      noBuild: true # 定义 SourceKey时，指示是否仍应进行构建

2.2. scenarios

在hello.benchmarks.yml中我们定义了场景: hello，并为此场景指定了两个任务:
- 第一个任务名为application，使用的是项目server
- 第二个任务名为load，并指定使用项目bombardier

2.3. variables 变量

在bombardier.yml中
- 定义了全局变量: headers、presetHeaders（预设header）
- 定义了局部变量: connections、warmup、duration、requests、rate、transport、serverScheme等等
在hello.benchmarks.yml中为load定义了局部变量serverPort、path

2.4. profiles 配置

在hello.benchmarks.yml中我们
- 定义了配置local
- 并指定了局部变量: serverAddress = localhost
- 为任务application、load指定了部署作业的endpoint 是 http://localhost:5010 （指定执行任务的Agent地址）

2.5. arguments 参数

在bombardier.yml中与variables同级的配置: arguments，此参数是在启动job后传递的参数，其中定义的全局参数、局部参数信息也都是为构建完整的参数做准备，bombardier真实的参数信息是:

-c {{connections}} -w {{warmup}} -d {{duration}} -n {{requests}} --insecure -l {% if rate != 0 %} --rate {{ rate }} {% endif %} {% if transport %} --{{ transport}} {% endif %} {{headers[presetHeaders]}} {% for h in customHeaders %}{% assign s = h | split : ':' %}--header \"{{ s[0] }}: {{ s[1] | strip }}\" {% endfor %} {% if serverUri == blank or serverUri == empty %} {{serverScheme}}://{{serverAddress}}:{{serverPort}}{{path}} {% else %} {{serverUri}}:{{serverPort}}{{path}} {% endif %} {% if bodyFile != blank and bodyFile != empty %} -f {{bodyFile}} {% endif %}  {% if verb != blank and verb != empty %} -m {{verb}} {% endif %}

3. 改造hello.benchmarks.yml

改造hello.benchmarks.yml，不考虑重用，最原始的代码如下

variables:
  headers:
    none: ''
    plaintext: '--header "Accept: text/plain,text/html;q=0.9,application/xhtml+xml;q=0.9,application/xml;q=0.8,*/*;q=0.7" --header "Connection: keep-alive"'
    html: '--header "Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8" --header "Connection: keep-alive"'
    json: '--header "Accept: application/json,text/html;q=0.9,application/xhtml+xml;q=0.9,application/xml;q=0.8,*/*;q=0.7" --header "Connection: keep-alive"'
    connectionclose: '--header "Connection: close"'
  presetHeaders: none

jobs:
  bombardier:
    source:
      repository: https://github.com/dotnet/crank.git
      branchOrCommit: main
      project: src/Microsoft.Crank.Jobs.Bombardier/Microsoft.Crank.Jobs.Bombardier.csproj
      sourceKey: bombardier
      noBuild: true
    readyStateText: Bombardier Client
    waitForExit: true
    variables:
      connections: 256
      warmup: 15
      duration: 15
      requests: 0
      rate: 0
      transport: fasthttp # | http1 | http2
      serverScheme: http
      serverAddress: localhost
      serverPort: 5000
      path: 
      bodyFile: # path or url for a file to use as the body content
      verb: # GET when nothing is specified
      customHeaders: [ ] # list of headers with the format: '<name1>: <value1>', e.g. [ 'content-type: application/json' ]
    arguments: "-c {{connections}} -w {{warmup}} -d {{duration}} -n {{requests}} --insecure -l {% if rate != 0 %} --rate {{ rate }} {% endif %} {% if transport %} --{{ transport}} {% endif %} {{headers[presetHeaders]}} {% for h in customHeaders %}{% assign s = h | split : ':' %}--header \"{{ s[0] }}: {{ s[1] | strip }}\" {% endfor %} {% if serverUri == blank or serverUri == empty %} {{serverScheme}}://{{serverAddress}}:{{serverPort}}{{path}} {% else %} {{serverUri}}:{{serverPort}}{{path}} {% endif %} {% if bodyFile != blank and bodyFile != empty %} -f {{bodyFile}} {% endif %}  {% if verb != blank and verb != empty %} -m {{verb}} {% endif %}"
    onConfigure: 
      # - job.timeout = Number(job.variables.duration) + Number(job.variables.warmup) + 10;    
    endpoints: 
      - http://localhost:5010
  
  server:
    source:
      repository: https://github.com/doddgu/crank
      branchOrCommit: sample
      project: samples/hello/hello.csproj
    readyStateText: Application started.
    endpoints: 
      - http://localhost:5010

scenarios:
  hello:
    application:
      job: server
    load:
      job: bombardier
      variables:
        serverPort: 5000
        path: /

4. 解读crank shell

之前我们通过shell执行：

crank --config hello.benchmarks.yml --scenario hello --profile local --load.framework net5.0 --application.framework net5.0
- 其中crank 是固定的、代表：Crank Controller
- --config：固定的配置，指执行哪个yml配置，每次仅能指定一个yml配置
- --scenario：固定的配置，设置场景是hello
- --profile：固定的配置，非必选，可多次设置，指定当前Crank命令申请的配置是local，使用local下配置的所有信息
- --load.framework: 格式：<任务名>.framework，为任务load指定framework的运行框架版本是net5.0、--application.framework同理
改造hello.benchmarks.yml，因为移除了profile，所以执行: crank --config hello.yml --scenario hello --load.framework net5.0 --application.framework net5.0 即可

查看crank更多文档

5. 疑问

为什么启动crank时要增加--application.framework net5.0？
- 安装crank要求必须有net5.0的环境，所以指定net5.0不需要再单独安装框架环境
为什么启动crank时不指定framework时默认是netcore3.1呢？
- 使用记事本打开hello.csproj、Microsoft.Crank.Jobs.Bombardier.csproj 即可了解
scenarios节点下application以及load两个节点名称可以更换吗？只能有两个节点？
- 节点名称不固定，可以更换，也没有限制必须是两个节点，具体多少个节点根据自己的需要来

6. 结尾

通过上面的学习，我们也已经完全的了解了各配置的作用，但对bombardier.yml与开源项目bombardier存在什么样的联系还不清楚，以及为什么叫做bombardier.yml而不是其他名字，并且是如何实现性能指标的输出，接下来就会讲到bombardier.yml与开源项目bombardier的关系，以及wrk.yml与wrk的关系

开源地址

MASA.BuildingBlocks：https://github.com/masastack/MASA.BuildingBlocks

MASA.Contrib：https://github.com/masastack/MASA.Contrib

MASA.Blazor：https://github.com/BlazorComponent/MASA.Blazor

如果你对我们的 MASA Framework 感兴趣，无论是代码贡献、使用、提 Issue，欢迎联系我们

干货｜一次完整的性能测试，测试人员需要做什么？

云智慧AIOps社区 — 2023-05-27

作者介绍

邓宝菊（Kiki Deng），10年软件测试经验，4年团队管理经验，当前任职研发部架构质量工程部，整体负责研发部测试团队的效能、工具流程建设和人才培养。

前言

一、 规范性能测试实施流程的意义

规范的性能测试实施流程能够加强测试工作流程控制，明确性能测试各阶段应完成的工作，指导测试人员正确、有序的开展性能测试工作，提高各角色在性能能测试中的工作效率。本次分享的性能测试实施流程是性能测试开展的”指导方针”，希望帮助您可以早日成为性能测试”达人”。

二、 性能测试实施流程

性能测试流程分为五个阶段，分别是【需求调研阶段】→【测试准备阶段】→【测试执行阶段】→【测试报告阶段】→【测试总结阶段】。

每个阶段做什么事情？重点关注什么？

1.需求调研阶段

正文

1.1. 阶段概述

调研阶段的主要工作为：组建工作小组、项目创建、需求分析、模型构建、定制性能测试详细实施计划。

重点关注：需求调研、需要分析、模型构建

1.2. 关键点描述

需求调研分为两个步骤进行：需求调研、需求分析。

该工作是性能测试必须的工作环节。工作产出文件为《XX项目性能测试需求表》，如：《云智慧_XXX系统_XXX模块性能测试需求表》。

此阶段模型构建主要是业务模型构建。

1.2.1需求调研

Ø 需求调研工作由性能测试实施人员牵头负责，产品经理、开发工程师、运维工程师配合完成；

Ø 需求调研的主要内容为：

n 系统线上环境的性能需求，例如性能需求、可靠性需求、可维护性需求等；

n 与系统性能需求相关的其它信息，包括系统信息（如线上环境硬件、参数配置、系统架构与部署方式、关联系统部署等）、业务信息（关键业务逻辑与处理流程、交易列表、交易量信息、业务分布规律等）、生产问题、文档资料等方面，并对收集到的信息进行汇总整理，实现对待测系统业务与技术的整体了解；

Ø 开发项目组、需求部门、运维部门等测试任务提出方应填写《云智慧_XXX系统_XXX模块性能测试需求表》中的“任务信息”和“测试背景”等信息，提出的测试需求,简单文字不能说明的，可附加文件；

Ø 性能测试小组的实施人员将调研获取的其它内容填入《云智慧_XXX系统_XXX模块性能测试需求表》；

Ø 对于新立项系统或系统新开发版本，《云智慧_XXX系统_XXX模块性能测试需求表》应与《需求规格说明书》中的性能需求相一致。

1.2.2需求分析

Ø 需求分析的基本流程是：

n 首先，由性能测试工程师根据需求调研所获取的信息进行分析，将《云智慧_XXX系统_XXX模块性能测试需求表》中的性能需求转换为具体的性能需求指标值；

n 其次，根据测试环境与线上环境的差异分析，由性能测试工程师将线上环境条件下的性能需求指标值转换为本次测试环境条件下的性能需求指标值；

例如：TPS（Transaction per Second）：系统每秒处理交易数，推导过程如下，

当前线上APP1.0试用系统主要为查询类交易，交易占比40%，系统生产交易量统计为1个月约20W笔，假设APP2.0系统上线后业务量激增到每日查询类20W，则每日总交易量T达到:

T = 20W/40%=500000笔/日

系统处理能力TPS推导:APP2.0上线后交易量最大500000笔/日,系统晚间几乎无交易量，按2:8原则推算,则(50000080%)/(820%3600)=69.4笔/秒，取整为70笔/秒，每年按业务量增长50%计算，则一年后系统处理能力指标约等于70+7050%=105笔/秒。

稳定性交易量推导: 取系统处理能力的60%_时长=105笔/秒*60%*8_3600=1814400笔。

经过分析后汇总成测试指标值

Ø 需求分析其主要内容和规范性要求如下：

n 性能测试需求：应准确描述性能测试指标项及需求指标值。

n 系统范围：应准确描述性能测试需求指标值所依托的测试范围信息，如应描述测试范围的关联系统逻辑示意图，及各关联系统的信息；在对系统局部环节进行测试时，也需阐明具体测试范围，详细描述被测系统的相关子系统。

n 环境差异分析：应准确描述性能测试需求指标值所依托的测试环境信息，如须描述测试环境的总体网络拓扑结构图、测试环境机器配置表（数量、型号、资源、操作系统）、以及相应的软件配置、重要参数配置等。同时应准确描述线上环境的上述信息，并进行详细的环境差异性分析。

以上分析内容将作为性能测试方案的重要组成部分。

1.2.3模型构建例如：业务模型

根据200X年XX月XX日~200X年XX月XX日期间的业务高峰日200X年XX月XX日的业务量统计，经过略微调整得出以下业务模型，要求业务模型交易至少占线上交易量的90%以上：

2.测试准备阶段

2.1阶段概述

测试准备阶段是性能测试工作中重要阶段。在准备阶段，需要完成业务模型到测试模型的构建、性能测试实施方案编写、测试环境的准备、性能测试案例设计、性能测试监控方案设计、性能测试脚本，及相关测试数据的准备，并在上述相关准备活动结束后按照测试计划进行准入检查。

重点关注：测试模型构建、方案设计、案例设计、数据准备等

2.2关键点描述

2.2.1测试模型构建

测试模型构建工作由性能测试实施人员完成；

在需求分析的基础上，对调研收集到的相关资料与信息进行分析梳理，重点分析跨系统的交易路径、交易关联关系、数据的处理与流转、业务量、交易比例、典型交易，以及系统的处理能力等性能测试点，针对性地确定多个业务场景，并为每个场景选择一套具体的业务交易集，按照业务量比例构建相应的测试模型。

本阶段的产出物为，各个测试场景，以及场景中典型交易及所占比率。

例如：从业务模型到测试模型推导

依据业务模型，通过与项目组及产品经理沟通，确定本次测试模型还需着重考虑以下内容：

（1）考虑到后期证券系统数据库升级，历史查询可能会影响，所以本次测试单独增加一个场景：历史委托和历史成交查询各50%（即0456和0457）。同时，考虑到线上环境绝大部分该交易是由总中心前置发起，所以本次测试“历史委托和历史成交查询”交易均采用从总中心发起；

（2）增加国债发行交易场景，国债发行认购日一般在柜台营业前进行，此场景只选择国债发行认购一支交易；

（3）同时，证券系统交易高峰时段柜员签到、柜员签退交易占比较小。

通过以上分析得出本次测试模型有3个：一般交易日日间模型、国债发行日模型、以及历史查询交易模型。

一般交易日日间模型：

储蓄国债交易模型：

历史查询交易模型：

2.2.2方案设计

性能测试实施方案编制是性能测试工作中必须的工作环节，其产出为《性能测试方案》，如：《云智慧_XXX项目_XXX功能模块_性能能测试方案V1.0.xlsb》。

在方案中需要描述：测试需求、启停准则、测试模型设计、测试策略、测试内容、测试环境与工具需求，以及各个阶段的输出文档。在方案中还需说明性能测试工作的时间计划安排、预期的风险与风险规避方法等。测试模型设计内容来自本阶段测试模型设计中形成的测试场景，以及场景中典型交易及所占比率。

2.2.3案例设计

在案例设计中，包括案例的描述、测试环境描述（硬件、软件、应用版本、测试数据）、延迟设置、压力场景、执行描述、预期结果、监控要点。

案例设计是性能测试工作的必须工作环节，案例设计的产出文件是《性能测试案例》。

2.2.4数据准备

环境准备工作中涉及到基础数据的准备。测试数据的数量、逻辑关系要求十分严格，测试基础数据的准备一般采用自造模拟数据或者使用脱敏后的线上数据。

2.2.5测试脚本开发

测试脚本开发工作就是发挥LR的时候。

测试脚本是对业务操作的程序化体现，一个脚本一般为一项业务的过程描述。本活动主要为脚本的录制（编写）、修改和调试工作，从而保证在测试实施之前每个测试用例的脚本都能够在单笔和少量迭代次数的条件下能够正确执行。测试脚本开发的一般步骤如下：

Ø 通过录制，或者编写，完成脚本代码生成。代码生成时，主要根据需求插入事务，作为测试过程中统计交易响应时间的单位；

Ø 根据测试需求，进行参数化设置；

Ø 设定检查点，根据报文内容字段判断交易是否正确执行，即检查点的设置在应用层面；

Ø 根据测试要求确定是否设置集合点；

3.测试执行阶段

3.1阶段概述

测试执行阶段是执行测试案例，获得系统处理能力指标数据，发现性能测试缺陷的阶段。测试执行期间，借助测试工具执行测试场景或测试脚本，同时配合各类监控工具。执行结束后统一收集各种结果数据进行分析。根据需要，执行阶段可进行系统的调优和回归测试。

重点关注：结果记录、测试监控、结果分析

3.2关键点描述

3.2.1测试执行与结果记录

测试执行过程有相应的优先级策略，依据测试案例的优先级别，优先执行级别较高的测试案例。测试过程中，通过对每个测试结果的分析来决定是重复执行当前案例还是执行新的测试案例；通常发现瓶颈问题会立即进行调整并重新执行测试用例，直到当前的案例通过。

在执行阶段，测试的执行、分析调优、回归测试工作较为反复，须认真记录全部执行过程和执行结果，执行结果数据是分析瓶颈的主要依据。

3.2.2测试监控

测试的监控工作与执行工作同步进行，场景或脚本开始执行时，同时启动监控程序（可以用nmon或者系统命令top/vmstat/iostat 等），当然也可以用云智慧的监控宝和透视宝协同工作，监控宝可以监控网站／网页性能／Ping/DNS/FTP/UDP/TCP/SMTP等IT基础设施的性能指标，透视宝可以发现主机资源、Web应用、浏览器、APP等应用的性能瓶颈，如下图所示：

监控宝监控页面

透视宝主机资源监控页面

在执行结束后，停止测试监控，并提取监控结果数据。

3.2.3测试结果分析

测试过程中根据前端性能测试工具显示结果、监控结果综合分析出现的测试问题。

例如：

测试组在执行“一般日日间交易模型”负载测试570TPS压力时，数据库监控发现有死锁想象，具体如下：

**问题分析：**经与开发一同分析，原因如下：流控信息收集程序（pltflowGthDaemon）在同一柜员、在毫秒级并发做交易时plt_flowgather表出现死锁。测试环境联机交易使用同一个柜员号发起，因此出现概率较高。

4.测试报告阶段

4.1阶段概述

测试执行工作结束后开始撰写性能测试报告。性能测试报告在发布前需要进行评审。

4.2关键点描述

4.2.1报告撰写

性能测试报告要内容包括：测试目的、范围及方法、环境描述、测试结果描述、结果分析、结论和建议等。

4.2.2测试结果描述

测试结果的描述，应体现性能测试的执行过程，如：混合场景的容量测试结果展示中，需要描述各个并发梯度下测试结果及监控结果；在数字形式的结果记录中，要求小数点后精确3位有效数字。

4.2.3测试缺陷与问题

在性能测试分析报告中须描述测试过程发现的缺陷与问题，对于确认是测试缺陷的项进行风险评估，并给出风险提示。

4.2.4最终结果分析

测试最终结果的分析，该部分内容应该全面、透彻、易理解且通过图表方式表达更直观。

例如：

4.2.5测试结论

测试结论是性能测试分析报告必须包括的内容。测试的结论须清晰、准确回答性能测试需求中描述的各项指标，需全面覆盖测试需求。

5.测试总结阶段

5.1阶段概述

性能测试的总结工作，主要对该任务的测试过程和测试技术进行总结。性能测试工作进入总结阶段，也意味着性能测试工作临近结束。在这个阶段，时间允许的情况下应将所有的重要测试资产进行归档保存。

写在最后

近年来，在AIOps领域快速发展的背景下，IT工具、平台能力、解决方案、AI场景及可用数据集的迫切需求在各行业迸发。**基于此，云智慧在2021年8月发布了AIOps社区，**旨在树起一面开源旗帜，为各行业客户、用户、研究者和开发者们构建活跃的用户及开发者社区，共同贡献及解决行业难题、促进该领域技术发展。

社区先后开源了数据可视化编排平台-FlyFish、运维管理平台OMP、云服务管理平台-摩尔平台、Hours算法等产品。

可视化编排平台-FlyFish：

项目介绍：https://www.cloudwise.ai/flyFish.html

Github地址： https://github.com/CloudWise-OpenSource/FlyFish

Gitee地址： https://gitee.com/CloudWise/fly-fish

行业案例：https://www.bilibili.com/video/BV1z44y1n77Y/

部分大屏案例：

您可以添加小助手（xiaoyuerwie）备注：飞鱼。加入开发者交流群，可与业内大咖进行1V1交流！

也可通过小助手获取云智慧AIOps资讯，了解FlyFish最新进展！

堪比JMeter的.Net压测工具 - Crank 入门篇

MASA技术团队 — 2023-05-27

1. 前言

Crank 是.NET 团队用来运行基准测试的基准测试基础架构，包括（但不限于）来自TechEmpower Web 框架基准测试的场景,是2021年.NET Conf 大会上介绍的一项新的项目，其前身是Benchmarks。

Crank目标之一是为开发人员提供一种工具，让他们能够非常轻松地处理性能并衡量潜在的改进。其中一些功能是：

部署和基准测试基于 .NET 或 Docker 容器的多层应用程序

通过指定.Net项目(本地路径或git远程仓库地址)，支持直接部署或通过Docker部署应用程序，用于基准测试）

通过Yml配置，不仅仅支持结果存储在 JSON 、SQL Server 中还支持存储到csv文件中以用于图表

目前有小伙伴已经在提议将支持存储在es

支持更改自定义应用程序的Franework环境，测试在不同环境下的性能
收集诊断跟踪信息

2. 核心组成

Crank由Agent、Controller两部分组成

Controller是任务的调度者，可以调度负载任务以及输出结果

Agent是基准代理，任务的实际执行者，接收来自Controller的任务并执行。

3. 安装

欲先工其善必先利其器，我们先学习下如何安装crank，以及如何验证是否安装成功

3.1. 准备工作

安装 .NET 5.0.
打开shell：安装Crank Controller

安装命令：

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

验证命令：

crank

打开shell: 安装Crank Agent

安装命令：

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

验证命令：

crank-agent

3.2. 小结

为方便阅读、文章中Crank Controller简称Crank，Crank Agent简称Agent

Agent以及Crank需要根据实际情况安装，可分以下几种情况:

只是为了学习Crank，没有单独的测试环境，则需要分别安装Agent、Controller

Agent有单独提供测试环境，则本地不需要安装Agent，只安装Controller即可

Agent有单独提供测试环境，且压测任务由ci来触发执行，则本地不需要安装任何配置，通过构建ci任务完成压力计划即可

打开shell：查看Agent、Controller版本

dotnet tool list -g

4. 基础知识

4.1. variables: 参数

variables分为局部参数与全局参数两种类型，在根节点的为全局参数，在其他节点下的是局部参数。

例：

hello.benchmarks.yml > scenarios > hello-load > variables节点下的serverPort以及path以及profiles>local>variables节点下的serverAddress是局部参数

scenarios:
  hello:
    application:
      job: server
    load:
      job: bombardier
      variables:
        serverPort: 5000
        path: /

profiles:
  local:
    variables:
      serverAddress: localhost

bombardier.yml > variables > headers为全局参数

variables:
  headers:
    none: ''
    plaintext: '--header "Accept: text/plain,text/html;q=0.9,application/xhtml+xml;q=0.9,application/xml;q=0.8,*/*;q=0.7" --header "Connection: keep-alive"'
    html: '--header "Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8" --header "Connection: keep-alive"'
    json: '--header "Accept: application/json,text/html;q=0.9,application/xhtml+xml;q=0.9,application/xml;q=0.8,*/*;q=0.7" --header "Connection: keep-alive"'
    connectionclose: '--header "Connection: close"'
    ---------------------------------------------------------------------

4.2. profiles: 配置

profiles其实就是配置文件信息，profiles允许被多次使用，这点在可以在文档中找到对应介绍。

Usage: crank [options]

Options:
  -?|-h|--help                       Show help information

  These options are not specific to a Job

  ----------------------------------------------------------------------
  --profile <profile>                Profiles to apply. Can be used multiple times.

命名规则: 建议 *.profiles.yml

4.3. jobs: 任务

将我们要做的事定义为一个job。方便之后重用。此处的事指的是一类事，而不是指特定的某件事。

例如：微软内置定义的bombardier就是一个job，这个job是通过bombardier对其进行基准测试，并将结果记录并输出，而具体针对哪个接口进行基准测试其实并不关心。

job根据应用程序源有分为远程、本地两种。

本地源：

jobs:
  server: #任务名称，可根据任务作用自行命名
    source: #任务源
      localFolder: ../hello 
      project: hello.csproj #要构建的 .NET 项目的文件名
    readyStateText: Application started. #控制台中通知服务器它已启动的文本

本地源localFolder针对当前运行crank --config执行命令所在的相对路径即可，任务开始后会将本地的项目发送到agent后再执行任务。

远程源

jobs:
  server:
    source:
      repository: https://github.com/dotnet/crank
      branchOrCommit: main #远程源执行任务的分支
      project: samples/hello/hello.csproj #要构建的 .NET 项目的文件名，格式：相对根的相对路径+项目名.csproj
    readyStateText: Application started.

远程源会将仓库信息发送到Agent，Agent会先将仓库下载下来并切换到指定的分支后再执行构建任务启动项目

4.4. scenarios: 场景

job关心的是一类事，而特定的事情并不关心，那具体的事是谁比较关心呢，没错那就是场景，也就是scenarios，scenarios通过多个job来完成对指定场景的基准测试，做的是具体任务的编排

4.5. imports: 导入

imports为我们提供了yml重用的可能，因为有imports的支持，我们才可以将公共的yml提取到一个单独的yml中，通过imports将使用到的yml导入即可，与js、css的导入有异曲同工之妙

4.6. 小结

在crank中，variables、profiles都不是必须的，但因为它们的存在，才使得我们可以以面向对象的思想开发，可以通过新增变量或指定配置完成基准测试，这块后面的实战中会有详细解释

5. 入门

经过之前的学习，我们对crank的基本配置也有了一定的了解，那接下来的时间，我们先试着学习下官方已经给我们准备好的Sample，下面的教程也会详细讲解一下各个配置的作用，希望能通过下面的学习了解到Crank的工作基本原理

5.1. 启动Agent

crank-agent --dotnethome "/home/{your-account}/dotnet"

5.1.0.1. 启动Agent并指定dotnet环境

格式：crank-agent –dotnethome "dotnet安装地址"
crank-agent --dotnethome "C:\Program Files\dotnet" (windows)
crank-agent --dotnethome "/usr/share/dotnet" (Linux)

在启动agent时，强烈建议大家增加dotnethome 配置，为agent运行指定环境，以免运行任务时由于环境问题而卡在install sdk这里

因演示机器本地dotnet的使用的是安装路径为/home/gushoudao/dotnet，所以视频中运行的命令有所不同，这块还需要根据本地的实际情况自行调整路径即可 (因视频录制原因，在录制结束后会停止agent，我们真实使用中启动后不需要退出，一旦退出agent，就无法执行任务)

5.1.0.2. 启动Agent并指定不清理临时文件

crank-agen --no-cleanup (指定不清理临时文件)

默认agent执行任务结束后会删除当前任务执行过程中产生的临时文件

5.1.0.3. 启动Agent并指定构建任务的最大持续时间

crank-agent --build-timeout

默认构建任务的最大持续时间为10 minutes

更多配置点击查看

5.2. 新建hello.benchmarks.yml配置

配置文件源码来自hello.benchmarks.yml

imports:
  - https://raw.githubusercontent.com/doddgu/crank/sample/src/Microsoft.Crank.Jobs.Bombardier/bombardier.yml

jobs:
  server:
    source:
      repository: https://github.com/doddgu/crank
      branchOrCommit: sample
      project: samples/hello/hello.csproj
    readyStateText: Application started.

scenarios:
  hello:
    application:
      job: server
    load:
      job: bombardier
      variables:
        serverPort: 5000
        path: /

profiles:
  local:
    variables:
      serverAddress: localhost
    jobs: 
      application:
        endpoints: 
          - http://localhost:5010
      load:
        endpoints: 
          - http://localhost:5010

5.3. 启动任务

启动agent（打开放在一边）：

crank-agent --dotnethome "/usr/share/dotnet"

启动任务（另起一个新的Shell）：

git clone https://github.com/doddgu/crank.git
cd crank
git checkout sample
crank --config ./samples/hello/hello.original.benchmarks.yml --scenario hello --load.framework net5.0 --application.framework net5.0

然后我们等待片刻会输出以下结果

crank-agent：

crank：

| load                  |                |
| --------------------- | -------------- |
| CPU Usage (%)         | 39             |  CPU使用率
| Cores usage (%)       | 631            |  多核CPU使用率
| Working Set (MB)      | 35             |  内存使用率
| Private Memory (MB)   | 35             |  进程使用的私有内存量
| Build Time (ms)       | 4,853          |  构建应用程序需要多长时间（毫秒）
| Start Time (ms)       | 386            |  启动应用程序需要多长时间（毫秒）
| Published Size (KB)   | 66,731         |  已发布应用程序的大小 (KB)
| .NET Core SDK Version | 5.0.403        |  .Net Core SDK 版本
| ASP.NET Core Version  | 5.0.12+0bc3c37 |  .Net Core版本
| .NET Runtime Version  | 5.0.12+7211aa0 |  .Net运行时版本
| First Request (ms)    | 172            |  第一个请求耗时（这里请求是Get）
| Requests              | 2,086,594      |  总发送请求数
| Bad responses         | 0              |  糟糕请求数（响应状态码不是2**也不是3**）
| Mean latency (us)     | 1,833          |  平均延迟时间
| Max latency (us)      | 89,001         |  最大延迟时间
| Requests/sec          | 138,067        |  每秒支持请求数
| Requests/sec (max)    | 255,442        |  每秒最大支持请求数

当你能输出以上信息的时候，证明了你已经成功跑通了整个流程

在上面我们可以很清楚的看到场景hello下的测试结果，其中包含CPU使用率、多核CPU的使用率、内存使用率以及每秒执行的请求数等等指标

在这一刻是不是突然觉得这个crank挺强大的，虽然还不清楚具体是咋做到的，但是真的很赞！！在这一刻是不是对它来了兴趣，想知道它到底可以做什么，为什么可以输出以上的结果？

6. 结尾

为确保后续不会因更新导致按照文档操作不可用，源码从官方源Fork了一份，其中绝大多数来自官方提供的Sample、部分文件为了更好的满足个人习惯，会在一定程度上进行调整。

参考链接：

开源地址

MASA.BuildingBlocks：https://github.com/masastack/MASA.BuildingBlocks

MASA.Contrib：https://github.com/masastack/MASA.Contrib