Nutflow

Appearance

升级至1.5.0 ​

重要

  • 升级flowable至6.7.2。flowable在6.7.x中优化了分页逻辑，大量提升了查询速度。具体可查看flowable更新日志。
  • 重构了待办/待签/已办/办结/我的请求列表的查询逻辑，大量提升了查询速度。

pom.xml(cloud请忽略) ​

修改flowable版本号为6.7.2

application.yaml(cloud请忽略) ​

yaml
#flowable配置
flowable:
  activity-font-name: \u5B8B\u4F53
  label-font-name: \u5B8B\u4F53
  annotation-font-name: \u5B8B\u4F53
  check-process-definitions: false
  database-schema-update: true # 升级flowable 表自动更新
  async-executor-activate: false # 定时任务
  app:
    enabled: false
  cmmn:
    enabled: false
  idm:
    enabled: false
  dmn:
    enabled: false
  form:
    enabled: false
  content:
    enabled: false
  eventregistry:
    enabled: false
  custom-mybatis-x-m-l-mappers:
    - org/springblade/plugin/workflow/process/mapper/WfProcessDefinition.xml

升级之后的查询速度 ​

DANGER

群里有几个老哥对插件进行了测试，数据从10w开始列表卡顿。但在实际情况中当流程结束时，runtime中的数据会被删除，来保证进行中的流程查询速度不会变慢。下面有两个实际使用中的例子：

  • 群主服务过的某雪糕销售商，全国业务员2000+，近半年所有流程数量在4000条左右。
  • 群主所在集团6000+人，近半年内代办数量大约在5000条。

我不确定以上场景是否超过了群里几位老哥的实际场景，但积压流程超过10w条的情况基本不存在。

本测试基于，实际结果可能因硬件/软件/网络问题不同。 ​

  • 型号：MacBook Pro(14-inch, Late 2021)

  • CPU/GPU：M1 Max

  • 内存：64GB

  • BladeX：2.9.0

  • Mysql：5.7

具体列表速度，以下每个列表数据均为738580条 ​

  • 待办列表 4.5s
  • 待签列表 4.8s
  • 我的请求 1.6s
  • 我的已办 2s
  • 流程运维 运维调度 0.7s
  • 流程运维 所有流程 1.6s

速度慢的原因 ​

  • 待办与待签列表速度慢的原因: ACT_RU_IDENTITYLINK表中数据影响。
  • ACT_RU_IDENTITYLINK表中的数据变多后也会影响到发起流程列表。