引言
前提项目组里无用到SPRING进行事务的管理项目里以功能划分到每个人手里
形成了BODAOACTIONVIEW都是单人负责在DAO中每个动作都以
封闭式的形式存在
问题造成事务的不连贯性功能是做出来了性能问题迟早暴露
测试主要针对程序频繁请求数据库连接对WEB应用所造成影响做一个测试
先做必要的说明一步步引入正题先从性能瓶颈开始
性能瓶颈
所有的应用程序都存在性能瓶颈为了提高应用程序的性能就要尽可能的减少程序的瓶颈以下是在JAVA程序中经常存在的性能瓶颈
了解了这些瓶颈后就可以有针对性的减少这些瓶颈从而提高JAVA应用程序的性能
数据库连接池工作原理
关于连接池的实现原理测试方案
经过资料的收集与APACHE DBCP里连接池的查阅对现有的连接池工作原理有两种方式
数据库预先设置配置好的连接数待得到用户请求连接传出一个连接而后为了保持供应数再提前创建连接即提前预备连接数供请求比如
有个通行道代表最大激活的连接数最小个闲置连接数也就是说连接池里始终预备了个可随时提供的连接连接的创建开销是比较大的连接池的存在就是了能够最小化的解决创建所等待的时间
O
O
*
*
*
如上图当分配出去时由于池中连接数剩一个为保持最小闲置会自动创建一个新的连接以防止再次请求等待创建的时间这样确实减少了等待的时间但是数据库创建的开销方面并未得到解决如果把比喻成汽车那么这种情况下每量车都是一次性使用被请求后下一个连接将是来接替那么如何能够重复利用减少数据库开销于是引出第二种方式
回收使用完后的连接放回到池中进行循环利用这么做必须能保证点
一 使连接能够保持有效的回收
二 约束使用者使用释放的动作而不是直接把连接close
笔者使用的是APACHE DBCP里BasicDataSource的连接池基本实现
经过代码与测试结果显示其工作方式是基于二的
BasicDataSource测试用例
下面展示了一个测试用例
测试结果
第组数据:
并发应用数 模拟连接数
运行平均耗时
共使用个连接
运行平均耗时
共使用个连接
运行平均耗时
共使用个连接
运行平均耗时
共使用个连接
运行平均耗时
共使用个连接
第组数据共执行次;平均耗时为毫秒
平均使用个连接
第组数据:
并发应用数 模拟连接数
运行平均耗时
共使用个连接
运行平均耗时
共使用个连接
运行平均耗时
共使用个连接
运行平均耗时
共使用个连接
运行平均耗时
共使用个连接
第组数据共执行次;平均耗时为毫秒
平均使用个连接
第组数据:
并发应用数 模拟连接数
运行平均耗时
共使用个连接
运行平均耗时
共使用个连接
运行平均耗时
共使用个连接
运行平均耗时
共使用个连接
运行平均耗时
共使用个连接
第组数据共执行次;平均耗时为毫秒
平均使用个连接
每次测试的结果都可能不同但是所得到的结论是一致的数据显示不合理的请求使用连接严重的影响应用所能承受的并发数量响应的时间也因此受到影响
目前普遍存在的问题
没有把事务控制好一般会出现以下的情况
事务(){流程();流程();}
可以看出流程里都是单独创建连接并在自己的流程里完成操作
如果在流程里出现异常那么流程所做的操作是不可恢复的
如果能控制在事务范围内如
事务(){Connection con;流程(con);流程(con);conclose();}
那么数据库少提供一个连接事务的完成性也得到体现在并发数量大的时候效率上就有非常明显的区别
解决方案
尽量保持少的请求
如DAO中有update()方法则应再扩展一个方法update(Connection conn)
在业务逻辑事务里调用update(Connection conn)一般情况下调用update()
对于数据不变的情况采用缓存技术或部分缓存技术
可参照一些相关的开源的项目（JIVE）
