XBPM4.0性能测试报告

1.概述
1.       
未持久化。流程图DemoForkJoinThree进行测试，
XBPM4.0串行执行、并行执行均无明显瓶颈，在60~120个消费线程时，串行执行TPS（与下文MPS含义相同）可达到理论上限的60%，并行执行可可达到理论上限的70%以上。其中并行执行时系统CPU消耗低于串行执行。继续加大消费线程时，瓶颈在napoli的machine端。结论分析：并行执行CPU消耗低于串行，是由于XBPM串行时，路由机制中多了判断逻辑和设置流转路径上下文逻辑，而节点停留时间使用的是sleep，sleep不占用cpu，因此更多的线程sleep并不会使cpu使用率上升。（注，理论上限计算方法为：以图DemoForkJoinThree为例A、B、C、D四个结点各停留8ms，串行时单线程TPS理论上限=1000/(8*4)=31.25）。
2.       
同步持久化。流程图DemoForkJoinThree进行测试，EDA框架的同步持久化与未使用框架时的同步持久化性能差别不明显，60个消费线程时TPS分别为791和797。
3.       
异步持久化。流程图DemoForkJoinThree进行测试，消费线程小于30个(测试过程中DBCP连接池大小为30)及以下时，使用EDA框架的异步持久化优于同步持久化，在30个消费线程时分别为704和522。消费线程过多时EDA框架异步持久化性能不及同步持久化，60个消费线程时分别为506和797。结论分析：线程个数小于数据库连接池配置，在sleep32ms的情况下，EDA方式TPS比同步方式高30%左右。由于EDA异步持久化时需要写入数据到Berkeley DB中，在压力过大时，Berkeley DB的数据出现堆积后需要写入到磁盘文件中，因此性能会出现下降，EDA异步持久化理论上比较是mysql和berkeleyDB之间存储的效率，在实际生产环境mysql数据库压力大(注：1个数据库对应多个应用服务器)的情况下，用EDA方式异步持久化，可以大大缩短用户响应时间。
4.       
稳定性。测试过程中异步持久化框架EDA与XBPM4.0本身均未发现明显的内存泄漏情况，CPU使用率也未出现异常波动情况。
5.       
脚本测试。使用脚本语言时，性能略低于Java方式，其中mvel和juel性能差别不大，60个消费线程时TPS可以达到Java方式的80%左右。其中mvel脚本资源CPU利用率要小于juel脚本的CPU利用率。（注：这里脚本指常用脚本表达式，不包含特殊复杂的脚本测试）。
6.       
与XBPM3.0或harbor比较。在与同样的8核环境测试，TPS相比XBPM3.0及harbor均有较大幅度的提升，
XBPM3.0、harbor、XBPM4.0在图DemoForkJoinThree上的TPS分别是1095、1401、1980。XBPM4.0并行处理时， CPU利用率大幅下降的原因是本次测试节点停留时间使用的是sleep方式，并未调用外部接口，因此CPU消耗较低。

2.建议配置
1).配置xbpm4.0并行执行时：PVM线程池大小>=(流程最大分支数-1)*执行流程主线程数（注：此场景中主线程数是napoli消费线程）；
2).配置EDA异步持久化框架时：执行流程的主线程数<=DBCP连接池大小(本例中是30)可以获得比同步持久化更好的性能；
3).异步持久化推荐bpm.db.transaction.flag=y，xbpmeda.store.invokeType=asynctrans， xbpmeda.bdb.transaction=false。配置含义为：业务中开启事务，EDA使用带事务可靠消息，且Berkeleydb消息存储不开启事务。
结论：开启BerkeleyDB事务比不开启BerkeleyDB事务慢20%。

3. 硬件部署及参数
3.1服务器硬件配置信息

主机/ip


硬件配置


操作系统及参数调整


10.20.149.83
mysq服务器


机型


实体机


2.6.9-78.ELsmp
64位操作系统
有两块硬盘，其中mysql数据盘信息如下：
Device: DELL     PERC
  6/i         Version: 1.22
Serial number: 006eb1a706b8ffa71200649f7d804e02
Device type: disk
Disk /dev/sdb: 2829.9 GB, 255 heads, 63 sectors/track, 344058
  cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes


CPU


Quad-Core AMD Opteron(tm) Processor 2378 * 8


内存


16G


网络


1000M


主机/ip


硬件配置


操作系统及参数调整


10.20.144.1
XBPM4.0所在应用服务器


机型


实体机


2.6.18-131.el5.custom
64位操作系统


CPU


Intel(R) Xeon(R)
  CPU           E5504  @
  2.00GHz * 8


内存


8G


网络


1000M


       3.2  软件部署及参数
            
应用服务器软件配置信息

主机/ip


软件名称及版本


关键参数


10.20.149.83
mysq服务器


mysql
  Server version: 5.1.59-alibaba-edition-log Source distribution



主机/ip


软件名称及版本


关键参数


10.20.144.1
XBPM4.0所在应用服务器


jdk1.6.0_18
jboss-4.2.3.GA
apache2.0.63
Napoli-1.4.11


-Xms2g
  -Xmx2g -Xmn512m -XX:PermSize=256m -XX:+DisableExplicitGC -XX:+UseParNewGC
  -XX:+CMSParallelRemarkEnabled -XX:+UseConcMarkSweepGC
  -XX:+UseCMSCompactAtFullCollection -XX:+UseCMSInitiatingOccupancyOnly
  -XX:CMSInitiatingOccupancyFraction=80 -XX:+UseFastAccessorMethods
  -XX:+UseCompressedOops




从上表可知：
1） 未使用框架的同步持久化与EDA同步持久化性能差异极小，60消费线程时TPS分别为797和791；
2） 消费线程数<30时，EDA异步持久化性能好于同步持久化，在30个消费线程时TPS分别为704和522，约为30%的性能提升；
3） 在节点停顿时间为8ms时，同步、asynctrans异步asyncrely异步性能依次为：asynctrans异步>asyncrely异步>同步；
在节点停顿时间为2ms时与8ms完全相反，同步、asynctrans异步asyncrely异步性能依次为：asynctrans异步<asyncrely异步<同步。原因见下方结果透析！
4） 消费线程数增大时，EDA异步持久化性能开始出现下降，消费线程数为60时，性能不及同步持久化，这是因为EDA异步持久化时需要写入数据到Berkeley DB中，在压力过大时，Berkeley DB的数据出现堆积后需要写入到磁盘文件中，因此性能会出现下降，EDA异步持久化理论上比较是mysql和berkeleyDB之间存储的效率，在实际生产环境mysql数据库压力大(注：1个数据库对应多个应用服务器)的情况下，用EDA方式异步持久化，可以大大缩短用户响应时间。
结果透析（30个消费线程）
情况一：休眠2ms的情况
性能从高到低依次是： 同步>asyncrely>asynctrans
原因解析：由于在性能测试环境下，mysql是单独的一台机器。在休息2ms的情况下，系统压力大。此时mysql的性能优于bdb数据库（注：测试环境为一个mysql只对一个应用服务器提供服务，线上是一个mysql对应用集群提供服务）。耗时环节分析如下：
同步：mysql+事务
asyncrely+bpm.db.transaction.flag=n：mysql+bdb（其中mysql耗时为异步方式，不会直接反应在响应时间中）
asynctrans+bpm.db.transaction.flag=y：mysql+bdb+事务（其中mysql耗时为异步方式，不会直接反应在响应时间中）
情况二：休眠8ms的情况
性能从高到低依次是：asynctrans>asyncrely>同步
原因解析：在性能测试环境下，mysql是单独的一台机器。在休眠8ms的情况下，系统压力小，此时bdb数据库优于mysql的性能，所以同步情况最慢。那么为什么asyncrely方式比asynctrans方式要慢呢？原因在于，asyncrely方式是马上将消息数据存入bdb中，同时将消息放入异步队列。而asynctrans方式是利用事务回调机制，等业务操作成功后，再将消息数据存入bdb中，同时将消息放入异步队列。这两种行为的差异在于，asyncrely方式会快速地将消息放入异步队列和存入bdb中，从而导致异步队列满，后续消息只存入bdb中，而消费这些异步消息需要mysql数据库连接，这些异步消息消费线程比消息生产线程慢的多，所以导致bdb中数据有大量的堆积，而运行在后台的bdb持久化线程会将积压的消息数据持久化到磁盘上，从而导致asyncrely方式较慢。带事务的asynctrans，由于有mysql连接的资源限制和等待，会慢慢地将消息放入异步队列和存入bdb中，使bdb中的数据不会快速堆积，消息的新增和删除能保持匀速进行。
结论：bdb中消息数据不能过多的积压，要保证消息消费线程和消息生产线程尽可能性能一致。在本例中，由于事务的关键资源数据库连接的存在，使得带事务的asynctrans测试场景满足了这条结论，因此在此场景下性能最快。