51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 3192|回复: 2
打印 上一主题 下一主题

[原创] 影响性能的测试报告(数据库版)

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2007-5-29 16:19:00 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
<SPAN style="FONT-SIZE: 16px"><STRONG><FONT color=darkred>引言</FONT></STRONG></SPAN><BR>前提:项目组里无用到SPRING进行事务的管理。项目里以功能划分到每个人手里,<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;形成了BO,DAO,ACTION,VIEW都是单人负责。在DAO中每个动作都以<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;封闭式的形式存在。<BR><BR>问题:造成事务的不连贯性。功能是做出来了,性能问题迟早暴露。<BR>测试:主要针对程序频繁请求数据库连接对WEB应用所造成影响做一个测试。<BR><BR>先做必要的说明,一步步引入正题,先从性能瓶颈开始:<BR><BR><FONT color=darkred><B><SPAN style="FONT-SIZE: 16px">性能瓶颈</SPAN></B><BR></FONT><BR>所有的应用程序都存在性能瓶颈,为了提高应用程序的性能,就要尽可能的减少程序的瓶颈。以下是在JAVA程序中经常存在的性能瓶颈。<BR><BR><IMG title=点击图片可在新窗口打开 style="DISPLAY: inline; WIDTH: 500px; CURSOR: pointer" alt=image src="http://www.testage.net/attachments/2007/05/8_200705221440261.jpg" onload=javascript:imgLoad(this); border=0 resized="0"><BR><BR>了解了这些瓶颈后,就可以有针对性的减少这些瓶颈,从而提高JAVA应用程序的性能<BR><BR><B>数据库连接池工作原理</B><BR><BR>关于连接池的实现原理测试方案:<BR>经过资料的收集与APACHE DBCP里连接池的查阅,对现有的连接池工作原理有两种方式:<BR>1.&nbsp;&nbsp;数据库预先设置配置好的连接数。待得到用户请求连接,传出一个连接,而后为了保持供应数再提前创建连接,即提前预备连接数供请求。比如:<BR>有5个通行道代表最大激活的连接数,最小2个闲置连接数。也就是说连接池里始终预备了2个可随时提供的连接,连接的创建开销是比较大的,连接池的存在就是了能够最小化的解决创建所等待的时间。<BR><BR>1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;O<BR>2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;O<BR>3&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;*<BR>4&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;*<BR>5&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;*<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;如上图,当1分配出去时由于池中连接数剩一个,为保持最小闲置,会自动创建一个新的连接以防止再次请求等待创建的时间。这样确实减少了等待的时间,但是数据库创建的开销方面并未得到解决。如果把1-5比喻成汽车,那么这种情况下每量车都是一次性使用。1被请求后下一个连接将是6来接替。那么如何能够重复利用1减少数据库开销。于是引出第二种方式。<BR><BR><BR>2.&nbsp;&nbsp;回收使用完后的连接,放回到池中进行循环利用。这么做必须能保证2点<BR>&nbsp;&nbsp; 一.&nbsp;&nbsp;使连接能够保持有效的回收。<BR>&nbsp;&nbsp; 二.&nbsp;&nbsp;约束使用者使用释放的动作,而不是直接把连接close.<BR><BR>笔者使用的是APACHE DBCP里BasicDataSource的连接池基本实现,<BR>经过代码与测试结果显示,其工作方式是基于二的。<BR><BR><B><SPAN style="FONT-SIZE: 16px"><FONT color=darkred>BasicDataSource测试用例</FONT></SPAN></B><BR><BR>下面展示了一个测试用例<BR>测试结果:<BR><BR>第2组数据:<BR>并发应用数:100 模拟连接数:6<BR>运行平均耗时:2956<BR>共使用51个连接<BR>运行平均耗时:3391<BR>2共使用52个连接<BR>运行平均耗时:2616<BR>共使用47个连接<BR>运行平均耗时:3377<BR>共使用41个连接<BR>运行平均耗时:3673<BR>共使用46个连接<BR>第2组数据共执行5次;平均耗时为:3229毫秒<BR>平均使用47个连接<BR><BR>第3组数据:<BR>并发应用数:85 模拟连接数:9<BR>运行平均耗时:4830<BR>共使用53个连接<BR>运行平均耗时:3247<BR>共使用49个连接<BR>运行平均耗时:4116<BR>共使用40个连接<BR>运行平均耗时:4070<BR>共使用43个连接<BR>运行平均耗时:4053<BR>共使用54个连接<BR>第3组数据共执行5次;平均耗时为:4063毫秒<BR>平均使用47个连接<BR><BR>第4组数据:<BR>并发应用数:140 模拟连接数:3<BR>运行平均耗时:2076<BR>共使用47个连接<BR>运行平均耗时:3104<BR>共使用51个连接<BR>运行平均耗时:2048<BR>共使用43个连接<BR>运行平均耗时:2421<BR>共使用50个连接<BR>运行平均耗时:2751<BR>共使用50个连接<BR>第4组数据共执行5次;平均耗时为:2480毫秒<BR>平均使用48个连接<BR><BR>每次测试的结果都可能不同,但是所得到的结论是一致的。数据显示不合理的请求使用连接严重的影响应用所能承受的并发数量,响应的时间也因此受到影响。<BR><BR><BR><BR><B><SPAN style="FONT-SIZE: 16px"><FONT color=darkred>目前普遍存在的问题</FONT></SPAN></B><BR><BR>没有把事务控制好,一般会出现以下的情况:<BR><BR><PRE class=overflow>事务(){<BR>&nbsp;&nbsp;流程1();<BR>&nbsp;&nbsp;流程2();<BR>}</PRE><BR><BR>可以看出流程1,2里都是单独创建连接,并在自己的流程里完成操作。<BR>如果在流程2里出现异常,那么流程1所做的操作是不可恢复的。<BR>如果能控制在事务范围内,如:<BR><BR><PRE class=overflow>事务(){<BR>&nbsp;&nbsp;Connection con;<BR>&nbsp;&nbsp;流程1(con);<BR>&nbsp;&nbsp;流程2(con);<BR>&nbsp;&nbsp;con.close();<BR>}</PRE><BR><BR>那么数据库少提供一个连接,事务的完成性也得到体现。在并发数量大的时候,<BR>效率上就有非常明显的区别。<BR><BR><STRONG><FONT size=3><FONT color=darkred size=4>解决方案</FONT><BR></FONT></STRONG>1. 尽量保持少的请求<BR>如DAO中有update()方法,则应再扩展一个方法update(Connection conn)<BR>在业务逻辑事务里调用update(Connection conn),一般情况下调用update()<BR><BR>2.对于数据不变的情况采用缓存技术,或部分缓存技术。<BR>
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

该用户从未签到

2#
发表于 2007-11-12 15:38:57 | 只看该作者
有点看不明白,呵呵,还需要再琢磨琢磨
回复 支持 反对

使用道具 举报

该用户从未签到

3#
发表于 2007-12-5 15:00:24 | 只看该作者
看得有点晕。。得好好琢磨琢磨
回复 支持 反对

使用道具 举报

本版积分规则

关闭

站长推荐上一条 /1 下一条

小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

GMT+8, 2024-11-18 06:48 , Processed in 0.073281 second(s), 28 queries .

Powered by Discuz! X3.2

© 2001-2024 Comsenz Inc.

快速回复 返回顶部 返回列表