AgileBpm 性能测试

有天发现有人居然压测了 test.agilebpm.cn 测试环境,那个服务器为1核的阿里云特惠机,很弱。所以我这里使用笔记本做一个简单的测试,旨在让您对AgileBPM系统性能有个基本的了解。

机器和环境

  • 华硕N550 i7 4代笔记本 12g 内存
  • 使用eclipse 起的 Tomcat 8 来运行项目(实在懒得打war单独跑)
  • jMeter 4 (局域网内另一台笔记本surfacebook2 i7 来使用该压测工具压测)
  • 本地mysql
  • visualVM 虚拟机监控软件

压测案例说明

使用了一个简单的表单进行“流程启动”的压测(压测三次共启动10w条流程)
此过程会创建流程实例,保存业务数据,维护AgileBPM相关的流程运行时数据

并发 200 压测结果

可以看出 在200并发下,CPU 已经成为性能瓶颈,吞吐量为1600/分钟,系统无任何异常

并发 300 压测结果

可以看出 在300并发下,CPU 早已成为性能瓶颈,吞吐量为5000/分钟,系统无任何异常

并发 400 压测结果

可以看出 在400并发下,CPU 已经沦陷,机器操作卡顿,吞吐量为3400/分钟,系统无任何异常

总结

并发300 压测时,笔记本CPU明显为性能瓶颈,吞吐量可以达到5000/分钟 ,系统无任何异常,性能表现还算可以。
并发400 下吞吐量明显降低,可以考虑分布式部署来解决单机高并发下带来的性能瓶颈

并发200的时候吞吐量基本稳定,并发300 和400 测试时间有点短,吞吐量还在上升,理论上突破100 TPS 是没问题的。

后记

后面把 mysql 刷盘 为每秒一次后,笔记本可以达到7000+吞吐量 innodb_flush_log_at_trx_commit=2
同一流程下单独调用 activiti 接口,无任何 AgileBPM 相关操作、吞吐量为 10000左右
基本可以说明 AgileBPM 做的操作对性能影响很少(涉及 业务数据 处理、表单权限处理、插件执行以及 AgileBPM 相关流程表数据维护)

目前我们支持 Activiti no history 模式 理论讲性能可以提升 30%