盘古BPM体验地址    盘古BPM交流群盘古BPM交流群号:963222735

flowable异步历史性能基准测试

分享牛 2602℃

摘要:flowable Asynchronous History,flowable异步处理,flowable实战

介绍

上周,我们发布了即将发布的Flowable6.3 版本的性能基准测试结果(flowable6.3功能以及性能基准测试报告)。这篇文章的结论很简单:与之前的版本相比,6.3.0引入的更改使其成为最快的版本。在这篇文章中,我们还暗示了这些还不是最好的结果。

要想取得更好的结果可以使用Flowable引擎的"异步历史"特性。让我们简要了解一下异步历史的含义,然后深入研究结果。

如前一篇文章所提到的,数字的重要性在于它们的相对差异而不是绝对值。更具体地说,我们在这里展示的是我们之前的基准测试中最好的结果和在相同的环境中启用异步历史功能之后流程之间的差异。

Asynchronous History?

“异步历史”功能是我们以前提到过的,但目前还没有得到太多关注。在6.1.0版本和文档中都有提到。它也被用于“Devoxx 2017”的演示,并在示例中展示。

相关文章:

Flowable消息队列实战

Flowable异步方式处理历史数据实战

Flowable异步方式处理历史数据

这一特性是在一些分析会话之后诞生的,它演示了处理“历史”数据的大量时间(它可能仍然是一个活动过程的数据)。顾名思义,基本思想是在稍后的时间以异步方式处理历史数据。历史数据没有将所有数据都刷新到数据库中,而是在数据库中存储未处理的数据。可以将未处理的数据连接到消息驱动的体系结构中(在引擎中有帮助类,用于与消息队列集成,检查下面的链接)。该引擎还保证,即使使用消息队列(常常被忽略),这也是完全正确的。

关于异步历史和它背后的实现的详细说明,请检查https://github.com/flowable/flowableexamples/tree/master/async -history/async-history-default-cfg#description。

它还被设计成可以轻松地从框中运行消息队列。要了解更多信息,请查看。

1、使用JMS消息队列运行异步历史记录

2、使用ratitmq消息队列Springboot器应用程序运行异步历史。

基本观点是:

1、在流程实例将其状态写入数据库之后,历史数据将被异步处理。用户可以更快地得到控制,这将导致更快的用户界面(如果没有用户,更快的机器与机器通信)。

2、减少网络往返,因为历史数据是相结合的。之前的性能基准测试表明,减少网络往返通常会导致更高的吞吐量。

3、它还意味着历史数据不能立即可用,但在查询时稍微延迟。对数据的实时性有要求的用户,对于该功能请慎重使用。

让我们把最好的结果再提高20%-96% !

同样的基准项目,在flowable6.3性能基准测试中,也在AWS上使用的相同的机器上执行,唯一不同的地方是现在启用了异步历史。在图表的左侧,显示了6.3.0的“基线结果”。为此,在上面的链接中描述的“远程数据库”设置场景是基准测试:这意味着AWS Aurora实例与真实的网络往返。“本地数据库”的运行更不合理,因为异步历史的目的是为了最小化网络往返和数据传输,这在本地设置中不太明显,在实际使用中不太现实。

请注意,同一版本的数字与上一篇文章的结果略有不同。即使是在同样环境下运行的AWS,也可以给出稍微不同的数字,这取决于我们发现的时间。为了更详细地描述基准中使用的流程定义,请阅读前面链接的基准博客文章。

记住,左边是最好的结果从6.3为基准的…所以如果你印象深刻的性能收益要这样!

第一个流程定义是最简单的:仅仅是一个启动事件,紧接着是结束事件:

为最简单的流程定义启用async历史可以使吞吐量增加32%(流程实例/秒)。

测试的第二个流程定义是具有10个顺序服务任务的直通流程:

启用异步历史可以使吞吐量增加96%(流程实例/秒)。最大的区别在于,在这里的一个事务中,需要持久化10个任务的历史。这样做会有很大的帮助。有趣的一点是,异步结果非常接近于上面的startToEnd,这是符合逻辑的,因为两者在运行时都保持相同数量的数据。唯一的区别是服务调用,它是快速的。

因此,寻找(微)服务编排的人注意到:异步历史特性有效地将所有的历史数据捆绑在一起,这极大地帮助了自动服务任务。

第三个流程定义的基准是包含50个流程变量和几个专用网关的流程:

启用异步历史可以使吞吐量增加21%(流程实例/秒)。这个百分比低于之前的结果(同时拥有更多的数据)的原因是,这里的结果实际上包含了三个事务(启动流程实例并提供20个变量,一个任务查询和一个包含30个变量的任务)。flowable引擎将在批量中插入相同类型的数据实体,实际上只有一个网络往返于数据库的20和30个变量。

第四个流程定义测试了并行和嵌套的子流程:

在这里启用async历史可以使吞吐量增加31%(流程实例/秒

第5个和最后一个流程定义测试使用一个terminate end事件来阻止流程实例在其执行过程中:

启用异步历史可以使吞吐量增加30%(流程实例/秒)。

结论

考虑到结果,断言异步历史是一个很好的特性,可以在真实的场景中提高可流引擎的吞吐量,这是非常安全的。当然,记住,基本性能没有异步历史已经很好,见我们的以前的文章…


转载请注明:分享牛 » flowable异步历史性能基准测试