流程引擎性能调优报告.docx

流程引擎性能调优报告1.目的由于流程引擎属于平台基础模块，不可避免的需要在性能上达到较高的标准。目前，流程引擎的功能以及完成大半，已经可以抽调资源来进行性能调优的前期研究。一方面可以解决一些实际存在的性能问题，另一方面也可以积累经验，为今后的深入性能调优做好技术储备。2.调优范围 由于目前仍然以功能需求为主，在性能调优上可以投入的时间和人力都十分有限。所以此次性能调优只针对流程启动和待办查询两个方面。3.现状n 经过多线程并发测试，简单流程启动需要消耗700ms，复杂流程(第一个节点为会签节点)启动消耗2000msn 在大数据量(50000左右待办)并发测试下，待办查询评价消耗时间4000ms4.分析及解决方案4.1流程启动现状及分析： 流程启动时，遇到第一个任务节点，需要执行UserTaskBehavior中的execute方法。在方法中，需要向Task中存入待办变量，而存入之前，先要将从数据表中加载现有变量到缓存中，这个动作称之为初始化缓存，每次初始化缓存均需耗时400ms左右，会签节点中每个子节点以及子流程节点的初始化均会消耗相应时间。 进一步查知，该动作执行SELECT * FROM activiti_test.act_ru_variable where task_id_ = ？;脚本，而where字句中的task_id_没有建立索引，此时表 act_ru_variable中数据已达100000条。解决方案： 1)建立索引，提升单次查询速度 2)缓存初始化时，判断如果task为新建立，则无需从数据库中加载数据结果： 只实行了第一条改进措施，执行后，简单流程启动缩短为20ms左右，复杂流程启动缩短为60ms左右4.2待办查询分析及方案： 由于目前架构，待办查询分为三个主要部分：activiti引擎待办查询、业务待办二次封装以及json object转换。所以调优也要从上述三个方面分别考虑： Activiti引擎待办查询a) 在大数据量(50000条)下，activiti查询待办需要消耗500ms左右时间，进一步跟踪发现时间完全被mybatis消耗。最终发现activiti利用了mybatis默认分页方式，即将数据全部加载到内存中，然后分页，这种方式势必造成存储上的压力以及时间上的冗长。最终，决定利用mybatis的动态sql技术，在查询语句中插入limit字句，利用数据库自带的分页技术。经测试查询时间可以降低到100ms以内b) 由于分页需要，待办查询需要获知满足条件的待办总数，于是需要执行 select count语句，但是经测试 select count语句需要耗时150ms左右，即使加入物理分页技术也无法提高。由于待办查询中，条件主要为assignee，及执行人，所以在assignee字段上建立索引。在建立索引后，select count 语句执行时间缩短为 3050ms，但是主查询语句的执行时间却增加到600ms。经查,activiti在待办查询语句中有 select distinct *字样，将 distinct去掉，主查询语句消耗时间降到100ms以内。 业务待办二次封装由于业务需要，我们需要对查询出的原生待办进行二次封装，加入必须的元素。优化前，封装单个对象需要耗时200多ms，如果返回10个对象，就需耗时2000多ms。经调查，在封装中，包括：封装基本待办字段、封装待办扩展字段(如果为会签)、获取流出的流转线、获取流程变量、判断当前待办是否为被驳回待办、判断当前待办是否可以驳回到发起人、获取可以驳回的节点、封装催办信息、获取绑定表单、获取绑定的权限等。如此多的操作集中在待办封装方法中，必然造成效率低下。而待办列表的查询结果只需要基本字段即可，所以我建立了新的封装方法，只包括：封装基本待办字段、获取流程变量、封装催办信息等操作。另一方面，建立了相关的索引。经测试，单次待办封装时间可以降低到10ms左右。 Json object转换通过以上两方面的性能调优，已经可以将单次的待办查询时间减低到200ms以内(50000条数据量，10线程并发)。但是，从rest客户端调用时，如果单线程多次调用，结果尚算正常，如果多线程并发，则性能急剧下降，单次查询耗时可达1000ms以上。经调查，rest application中调用的 ProcessEngineFactory类中的getProcessEngineByName方法为static方法，且有synchronized前缀，此处在并发状态下必然会造成性能下降。与此类似，工具类 DateUtil 的方法中也存在synchronized前缀。将这两处去掉后，性能数据回升，10线程并发的情况下单次查询（通过rest）为100多ms。5总结通过以上分析，对于今后的引