一次失败的JAVA性能优化经历

  在一次性能优化中，作为方案的主要参与者，我做了如下分析：

  API(提供给其他模块调用）中操作都是单次，
  而这个API的DB操作如下：

   A.查询是否重复
   B.调用其他模块API检查数据合法性：
   C.取
   D.插入主表
   E.插入日志记录
  
基本上是五个DB操作，发现当这个API循环200次的时候耗时太多
采用单元测试的方式测试：

测试笔数：200笔
测试硬件：本地
方式：直接调用直连API函数，200笔循环增加，耗时121秒；
 

  然后按照上面的步骤
拆分5步骤做测试：
步骤A：耗时：33718毫秒，约33秒
步骤B：耗时：15327毫秒，约15秒
步骤C：耗时：15687毫秒，约15秒
步骤D：耗时：73810毫秒，约73秒
步骤E：耗时：7656毫秒，约7秒
合计约151秒左右。

采用预编译 + 批量提交的JDBC编程方式，可以大量提高提交的性能问题。这个方案就是预先设想的方式。测试的结果也证明了采用这种方式至少可以减少60%的时间。

但是，问题来。这个API是在所有流程中的一环，前面还有2步，后面还有一步，而最后的一步会最终决定所有环节中的事物，也就是是说中间任何一个环节出问题，所有的事物回滚。
如果在这个API环节修改成批量，那么在所有的环节中都要修改成批量，这就有可能造成事物过长，引起不可预知的后果；而且对于批量提交，如果有一条数据操作有问题，是否所有的都回滚？这个处理起来也会比较麻烦。所以这个方案最终遭到了其他模块的同事的反对，这样一个优化方案就死掉了。

  此系统的环境如下：UNIX  + JDK1.5 + DB2

评论

3 楼 scholers 2011-01-20  

finallygo 写道

你用的数据库不是mysql吧,如果是mysql的话,如果你没有做事务的话,是不能进行批量提交的
而且你说"最后的一步会最终决定所有环节中的事物",那不做事务的话,是怎么来实现这个的呢?
至于"如果有一条数据操作有问题，是否所有的都回滚"这个问题应该和你们的业务有关系吧,我觉得事务的划分,经常都是和业务紧密联系的
比如你这里的
D.插入主表
E.插入日志记录
操作,你的需求如果是只有插入成功才做日志记录,那就是一个事务,但是如果不管成功还是失败都要做日志记录的话,那这两个操作就不应该做在一个事务中

我的这个博客可能写的不是很清楚，这里的整个步骤只是给其他N个步骤调用的一环，整个步骤都是在一个事物的控制之下。
  文章里面的优化只是对我当时这个模块的优化。

2 楼 finallygo 2011-01-20  

你用的数据库不是mysql吧,如果是mysql的话,如果你没有做事务的话,是不能进行批量提交的
而且你说"最后的一步会最终决定所有环节中的事物",那不做事务的话,是怎么来实现这个的呢?
至于"如果有一条数据操作有问题，是否所有的都回滚"这个问题应该和你们的业务有关系吧,我觉得事务的划分,经常都是和业务紧密联系的
比如你这里的
D.插入主表
E.插入日志记录
操作,你的需求如果是只有插入成功才做日志记录,那就是一个事务,但是如果不管成功还是失败都要做日志记录的话,那这两个操作就不应该做在一个事务中

1 楼 smallbee 2010-05-27  

呵呵 万事开头难