zeebe性能测试方案

一、背景

流程自动化（项目的一个模块）使用了Zeebe框架，该功能是为了帮助营销人员进行自动化的客户交互、线索培育、客户跟进，大大提高工作/营销效率。因为流程自动化会在流量较多的系统中作为一个常用模块，所以对性能有一定的要求。

其功能流程：创建包含多个条件组件的流程 => 用户满足开始条件 => 用户满足组件的条件 => 系统执行对应的动作 => 直至流程结束。

二、概念

• 流程
  一个流程就是一个bpmn文件
• 流程实例
  当有用户满足了一个流程的“开始”条件，进入到流程时，就会创建一个流程实例。这个流程实例理论上在变成“完成”状态时，就会被回收
• 事件
  bpmn工作流程中的开始、结束、定时器、消息、基于事件的网关（分为作品事件、外部事件）
  常用事件见《xxx》（保密，不贴出；大致就是业务人员的一些常用的营销方案所需要的事件）
• 动作
  bpmn工作流程中的服务任务（应该也分为作品动作、外部动作）
• 图示

事件和动作

• 版本
  一个流程可以有多个版本。刚创建是版本1，编辑保存后是版本2（bpmn文件中有个版本字段）。
  用户1在版本1阶段进入了流程中但未执行完毕，此时该流程编辑成版本2。那么用户1会还存活在版本1中，所以版本1还会占用资源

三、目的

希望通过对几种经典的流程进行性能测试后，可以得到以下数据：

• 新创建流程实例的性能（个/秒）
• 发布事件的性能（个/秒）
• 执行动作的性能（个/秒）
• 一个流程对磁盘存储空间的占用需求
• 一个流程实例结束后，该实例的空间回收情况（理论上为完成状态时就被回收）

四、压测对象

• 分析
  1.一个流程并不是原子性的，是由多个事件 / 动作组成，并且每个事件会有对应worker进行监控，每个动作则根据条件进行触发。所以一个流程的流程：流程的创建 => 满足准入条件生成流程实例 => 多个事件执行 => 多个动作触发 => 流程结束
  2.流程当中的每个步骤，都需要有接口请求暴露出来，这样才能进行性能测试。压测对象就是这些接口，按照流程的组件顺序发送请求，推进一个流程的运行
  PS.worker和Zeebe是独立的，每个worker相当于一个server。worker和流程中对应的事件建立起长连接，当满足了条件后，事件会发送一个请求给对应的worker。当出现比如100万个事件需要处理，但成功不够100万个时，就需要查看下对应的worker是否处理了这么多个请求，问题是出现在worker还是zeebe
• 接口
  【等待接口文档】

五、方案

准备工作：

1.创建几个典型的流程，跑通
2.准备好流程中的所有接口，按顺序跑通
3.登录进项目所在服务器，以便监控服务器情况（zbbix或nmon）
4.流程数据文件存储所在文件夹的地址
5.打开ES监控平台，以便查看实例的进度情况
6.压测服务器中进行测试工作【暂不知道压测服务器情况】
7.查看日志文件，比如查看各个worker处理了请求的个数（和后端商讨日志埋点的位置）

一、流程整体性能（多个典型流程）

• 先跑几种不同的典型流程，看看一个流程从创建、生成实例、执行事件/动作、结束这一系列的整体性能情况
  1.进行常规的递增压测，查看压测报告的常规数据【不同流程】
  2.监控服务器：CPU（nmon工具+htop命令）
  3.跑完毕后，ES监控平台查看是否是所有的流程实例都变成“完成”状态
  4.对比逻辑复杂程度不一样的组件之间的性能差距

二：单接口性能（多个典型流程）

• 接口一：创建流程接口
  1.进行常规的递增压测，查看压测报告的常规数据【不同流程】
  2.监控服务器：CPU、流程数据文件存储所在的文件夹大小变化【不同流程】
  3.含有组件不同，逻辑复杂程度不一样的流程的创建，创建速度是否存在明显的差异【不同流程】
  a.先跑一定并发的流程一的创建接口
  b.删除掉所有创建好的流程一，然后再跑新的流程二的创建接口
  c.如果有多种明显差异的流程，则重复步骤a-b
  d.对比这些流程的创建接口的性能情况
  4.是否会出现随着磁盘空间的变小，创建流程的速度变慢的情况【相同流程】
  a.磁盘空间空时，先跑一定并发的该接口
  b.磁盘空间被占用一定量后，再跑一次同样并发的该接口
  c.两种情况进行对比
  5.相同流程，创建不同版本时的性能对比：空间占用、创建速度等【相同流程】
  6.查看ES监控平台：此时左上角会显示当前流程的id以及版本号，暂无实例【不同流程】

• 接口二：生成流程实例接口（满足流程开始要求的请求）
  1.进行常规的递增压测，查看压测报告的常规数据【不同流程】
  2.监控服务器：CPU（nmon工具+htop命令）【不同流程】
  3.注意看是否会出现随着已存在的实例数目的增加，创建实例的速度变慢的情况【相同流程】
  a.先跑一定并发的该接口
  b.多次跑同样并发的该接口
  c.对比，看是否有明显差距
  4.查看ES监控平台：在对应的流程中会生成对应数量的实例，并且这些实例都处于开始处【不同流程】

• n个中间的接口【根据流程的事件、动作而定】
  1.1-3步骤和上面的接口二一样
  2.区别是第4点，需要在ES监控平台看是否真正执行了对应的事件/动作，是否有相同数量的实例执行了对应步骤
  3.注意是否真正执行了动作（收到消息等）

• 结束接口：流程结束的接口，一个流程可以有1个以上该组件
  1.进行常规的递增压测，查看压测报告的常规数据【不同流程】
  2.监控服务器：CPU（nmon工具+htop命令）【不同流程】
  3.注意看是否随着已存在的实例的减少，流程结束接口的速度会变快
  a.先跑一定并发的该接口
  b.多次跑同样并发的该接口
  c.对比，看是否有明显差距
  4.查看ES监控平台：对应的流程中，是否出现对应数量的实例变成了结束状态（理论上此时会被回收）

• 系统稳定性
  条件允许下，取一个最有可能长期的并发量，对系统进行稳定性测试。即长时间使用该并发量对系统进行压测

三：不同流程同个事件的性能差异（同时进行）

• 同个流程的同种组件和不同流程的同种组件，面对同样的并发压力的性能表现
  1.首先对同个流程同个组件进行一定量并发
  2.然后对不同流程，同个组件，进行同样量的并发
  3.对比两种情况

四、横向扩容

前提：经过前面的测试，得到了一定配置的机器的性能瓶颈。然后部署两台或多台同样配置的服务器，再次进行一次性能测试（经典流程），看此时得到的性能瓶颈是否和此时的机器数量相匹配。

五、功能方面

• 生成足够多的数据后，暂不删除数据，待前后端对接完毕。需要看页面的请求是否会出现超时、无法加载出来、加载出的页面显示不正确的情况

六、测试结果

• 施压机器
  参数：
• 系统服务器
  参数：
• 结果概况
  情况1：
  情况2：

七、注意点

1.优先获取到服务器最优的处理情况下的QPS
2.由于实际情况的时间不会如此充足，以供完成所说的全部的测试工作，所以先获取到常用流程的QPS，然后加以优化