51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 7526|回复: 18
打印 上一主题 下一主题

[原创] 事务响应时间过长

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2010-1-18 16:17:50 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
目前没有固定需求,只是想分析在多用户并发的情况下,事务响应时间以及CPU占用率。
测试点:查询的性能,此查询不需要输入查询条件,直接点“查询”按钮。
测试场景:并发20用户;每5秒增加2个用户;总共执行5分钟;
在脚本中去掉了思考时间
也没有设置迭代次数
用一台PC充当压力机
一台服务器server2003
测试结果:事务响应时间能够达到二三十秒。
求助响应时间过长,只有20个用户,实在是不明白。
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

该用户从未签到

2#
发表于 2010-1-18 16:35:20 | 只看该作者
把流量和服务器资源图表发上来,
大家看看
回复 支持 反对

使用道具 举报

该用户从未签到

3#
发表于 2010-1-18 16:40:28 | 只看该作者
thinktime是不能去掉的,要不然压力很大的,只是不要把thinktime放在事务里面就行了
回复 支持 反对

使用道具 举报

该用户从未签到

4#
 楼主| 发表于 2010-1-18 16:49:28 | 只看该作者

回复 3# 的帖子

好地,多谢,我先试下,如果有问题再来请教
回复 支持 反对

使用道具 举报

该用户从未签到

5#
发表于 2010-1-18 17:38:14 | 只看该作者
查看网页细分,看具体是什么耗费了时间
回复 支持 反对

使用道具 举报

该用户从未签到

6#
发表于 2010-1-18 17:41:57 | 只看该作者
thinktime是否去掉还是要根据你的测试目标,不能一概而定
回复 支持 反对

使用道具 举报

该用户从未签到

7#
 楼主| 发表于 2010-1-19 13:26:14 | 只看该作者

最新的测试结果,请大家帮忙分析

环境依然同上,并发10个用户,每5秒增加1个用户,持续时间5分
数据库中相关数据5万条左右,也就是从这5万条中进行查询,事务响应时间十分慢长。CUP占用率一度达到100%,内存没有过大。

因为目前没有固定需求,对于大数量级的测试,响应时间在多少左右属于正常情况,请各位帮助。另外,本系统WEB端主要做为后台管理员查询数据使用,不会涉及到过大的访问量,但数量级需求会很大。不知我的并发用户及时间是否合理。
在另外一个模块的查询性能中,因为库中对应的表中只有几十条数据,所以查询的事务响应时间以及各项指标都比较稳定,那一定是跟大数量级有关了。

[ 本帖最后由 bobdog520 于 2010-1-19 13:27 编辑 ]

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有帐号?(注-册)加入51Testing

x
回复 支持 反对

使用道具 举报

该用户从未签到

8#
发表于 2010-1-19 17:11:16 | 只看该作者
如果那个页面只有这个查询表单,那只有优化sql了
cpu100% 是应用服务器还是数据库服务器
回复 支持 反对

使用道具 举报

该用户从未签到

9#
 楼主| 发表于 2010-1-19 22:11:33 | 只看该作者
现在很不幸,由于项目组比较小,只有一台服务器,目前我们只能把ORACLE服务和系统布在一台机器上,我们知道这样做很不好,但是目前来说只能这样做,是不是需要在LR里配置一下来监控ORACLE的性能?另外请教,在LR中weblogic一般都监控哪些指标?非常感谢
回复 支持 反对

使用道具 举报

该用户从未签到

10#
发表于 2010-1-20 09:33:40 | 只看该作者
额。。在analysis中把think time去掉先。。

action的事务时间和你查询的时间差不多,就是一个很奇怪的问题
回复 支持 反对

使用道具 举报

该用户从未签到

11#
发表于 2010-1-20 10:18:54 | 只看该作者
跑的时候手动操作一下,看是不是很慢,如果是的话应该是sql的问题了
回复 支持 反对

使用道具 举报

该用户从未签到

12#
 楼主| 发表于 2010-1-20 11:02:22 | 只看该作者

回复 10# 的帖子

连云层老大都出现了,看来真是个问题
其实之间我把thinktime都去掉过,还是这样,ACTION和查询的时间差不多,觉得很是个问题
还是先让开发去优化SQL吧
回复 支持 反对

使用道具 举报

该用户从未签到

13#
 楼主| 发表于 2010-1-20 11:03:24 | 只看该作者
先谢谢各位了,我真是没啥性能测试经验,初学乍练,慢慢来吧
回复 支持 反对

使用道具 举报

该用户从未签到

14#
发表于 2010-1-20 11:04:54 | 只看该作者
去掉了也那么长,真的是蛮夸张的了,很少看到能做个查询做那么久的,我只是觉得你的负载有可能有问题,而不是系统真的有问题

因为如果是这样,你在负载下用手操作一下,就能知道是不是真的这么慢
回复 支持 反对

使用道具 举报

该用户从未签到

15#
 楼主| 发表于 2010-1-20 11:10:56 | 只看该作者

回复 14# 的帖子

是,我一直就怀疑我的负载哪里有问题,而不是本身系统的问题,但是我又不知道是哪些问题。现在在跑,我去访问WEB端,很慢,基本打不开页面。
而且同样类似的查询模块,数据量只是几十条的时候,和以上同样的负载条件,跑起来响应时间基本是没有超过半秒的。
回复 支持 反对

使用道具 举报

该用户从未签到

16#
 楼主| 发表于 2010-1-20 11:18:38 | 只看该作者
不是知道是不是我设置了HTTP超时时间的问题。我把运行时设置->选项里的HTTP超时时间那三项由120秒改成了600秒,才会出现这么长时间的响应,而且不会报失败的事务。
刚刚把这三项值改回120秒,并发20用户时基本就会出现失败的事务了。
回复 支持 反对

使用道具 举报

  • TA的每日心情
    开心
    2014-10-24 09:36
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    17#
    发表于 2010-1-20 11:46:47 | 只看该作者
    到页面细分去看一下,看你的配件事务下包括的页面,并分析这些页面中哪项占用时间最长
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    18#
    发表于 2010-1-22 12:17:55 | 只看该作者
    负载可能开的进程太多了!
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    19#
    发表于 2010-1-25 16:40:07 | 只看该作者
    优化SQL啰
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

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

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

    GMT+8, 2024-11-18 17:42 , Processed in 0.079110 second(s), 28 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

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