`
yhz851225
  • 浏览: 751 次
  • 性别: Icon_minigender_1
  • 来自: 杭州
最近访客 更多访客>>
社区版块
存档分类
最新评论

事务控制的问题

 
阅读更多
今天在做性能优化的时候发现了一些问题 我现在把自己的问题出现过程描述下:
测试机器用的是本人自己的可能会有点出入:
windows7 旗舰版64位
jdk : 64 1.6.0_27
cpu Inter Core i3-2310M CPU @ 2.10GHZ
内存 6G
tomcat已经调到最优支持2000个并发(这个是在自己的机器上 服务器的话会更高)
请求连接为/infows/rs/users/userinfo/101000000841 该链接包含2次数据查询操作和将数据转化为XML的操作非常复杂,大家可以看下没有缓存的结果:
并发量/请求数 成功/失败 吞吐 用户平均等待时间(ms) 服务器平均处理时间(ms)
1/1w 10000/0 91.68 10.908 10.908
100/1W 10000/0 154.31 648.047 6.480
300/1w 10000/0 159.92 1575.947 6.253
350/1w 10000/0 162.95 2147.933 6.137
400/1w 10000/0 162.12 2467.301 6.168
500/1w 10000/0 166.73 2998.872 5.998
1000/1w 10000/0 165.03 6059.647 6.060
2000/1w 10000/0 147.92 13520.773 6.760
非常惨 直接掉到350左右的并发 也可以理解
现在加上缓存(直接将XML结果缓存起来),且现阶段是全命中缓存,实际情况没这么理想:
并发量/请求数 成功/失败 吞吐 用户平均等待时间(ms) 服务器平均处理时间(ms)
1/1w 10000/0 146.99 6.803 6.803
100/1w 10000/0 311.98 320.528 3.205
300/1w 10000/0 258.62 1159.986 3.867
350/1w 10000/0 259.85 1346.947 3.848
400/1w 10000/0 254.74 1570.250 3.926
500/1w 10000/0 258.72 1932.611 3.865
600/1W 10000/0 255.50 2348.354 3.914
700/1W 10000/0 252.12 2776.499 3.966
1000/1W 10000/0 256.24 3902.623 3.903
2000/1W 10000/0 260.44 7679.439 3.840
蛋疼了才提高了200左右的并发,和自己想象中的出入比较大,why
是否从缓存中取出的网速限制,是否是连接数的限制•且缓存的内容是xml字符串不应该存在序列化上的问题 以上的问题都想过可结果都没有解决
我个人认为实际达到效果应该和TOMCAT的调优效果达到的并发量应该差不多 不该差那么多得 所以找原因 查了很多资料还是没解决 后来无意中试验了下在action层直接读取缓存结果让我非常惊讶,轻松支持
1700的并发量,都是同一个效果为什么到service层后差距会这么大,为了证明是service层的问题我简化了方法,写了和action层一样的方法结果发现和上面测试的结果一样非常让人失望,不过这倒让我非常兴奋找到了问题的入口,继续找和同事讨论了下,决定跟踪下方法的执行,发现进入方法前有大量的切面和反射相关的方法,思考````就是这些方法让整个测试结果改变了,想了下也就只有事务管理和上面的这个现象比较符合通过切面控制达到效果,所以觉得将类中的Tranction注解去掉测试,果然到家看下下面的结果:
并发量/请求数 成功/失败 吞吐 用户平均等待时间(ms) 服务器平均处理时间(ms)
1/1w 10000/0 394.30 2.536 2.536
100/1w 10000/0 2173.32 46.013 0.460
300/1w 10000/0 1587.71 188.951 0.630
350/1w 10000/0 1721.37 203.327 0.581
400/1w 10000/0 1513.23 264.335 0.661
500/1w 10000/0 1551.02 322.368 0.645
600/1w 10000/0 1433.20 418.644 0.698
700/1w 10000/0 1260.96 555.132 0.793
1000/1w 10000/0 1101.14 908.152 0.908
1500/1w 10000/0 883.19 1698.397 1.132
1600/1w 10000/0 848.20 1886.348 1.179
1700/1w 10000/0 770.25 2207.066 1.298
2000/1w 10000/0 704.68 2838.162 1.419

结果让人为之兴奋,这次测试出来的结果和自己所想的结果差不多,果然是事务控制的关系,但是这边就出现一个问题了,在事务配置中我们是将事务默认配置成readonly的 理论上说事务的消耗应该不会那么多,但是事实胜于雄辩,所以我建议将所有service中的注释注解全部注解到方法上不要注解到类上,且不需要事务控制的就干脆也不要才方法上注解了,只在需要事务控制的方法打上注解标记.
当然以上都是本人的一些观点可能原因什么的有差别 希望大家指出
分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics