51Testing软件测试论坛

标题: 用loadrunner时大并发数100个并发登录系统时产生了疑问。 [打印本页]

作者: moyudong 时间: 2012-10-19 16:15
标题: 用loadrunner时大并发数100个并发登录系统时产生了疑问。
今天做一个项目的登录并发，但是登录的页面图片大小达到了1M左右。所以并发时间就很大
了。
于是我注释掉了EXTRARES后面的图片，再并发，发现平均响应时间小了3秒。
已注释图片的脚本：[attach]81813[/attach]

无注释图片的脚本：[attach]81812[/attach]
显然没有注释掉的响应时间较大。

然，我这里想问的是，这里的“100个并发用户的响应时间”是指①服务器同时处理这100个并
发用户登录的时间，还是指②在100个并发的情况下，处理1个用户登录系统的时间？

当我处理500个并发的时候，在无注释图片的脚本时，平均响应时间达到了50多秒。！！！

如果是第②种情况的话，那么是不是就说明实际操作中（真实用户使用过程中），如果你在登录的时候真的发生了500个并发的情况，那么是不
是就得等50几秒你才能完全登录到系统。

作者: s523082170 时间: 2012-10-21 10:25
好问题。我也不知道。坐等回复

作者: msnshow 时间: 2012-10-21 21:11
是指一个用户所用的时间，但这里是的值是指90%用户所用的时间

作者: moyudong 时间: 2012-10-22 11:21
回复 3# msnshow

能根据我的提问进行剖析么？
你说是指一个用户所用的时间，然后又说这里是指90%用户所用的时间，这个是什么情况，听起来有点儿矛盾，个人理解能力不是很好，麻烦说清点，谢谢！
PS：如果是500用户并发的时候要50几秒，用户体验不是很糟糕了么。。。

作者: perterliu 时间: 2012-10-22 11:29
一百个并发情况下，平均一个用户所用的时间。

作者: 狮王之盾 时间: 2012-10-22 11:32
问题1：你如果对登录没有做参数化的话，就是拿一百个同一个账号同时进行登录操作；
问题2：这个50多秒只是代表一个平均的时间，实际略有偏差

不知道我的回答是否正确，请高手指点

作者: moyudong 时间: 2012-10-22 12:47
回复 6# 狮王之盾

" 你如果对登录没有做参数化的话，就是拿一百个同一个账号同时进行登录操作"
这里的登录参数化是指？？我确实用同一个账号在进行登录操作。
这50多秒的前提条件还是100个用户并发呢！

作者: cooklood 时间: 2012-10-22 13:28
对于“平均响应时间”来说，理论上就是100个并发的情况下，处理1个用户登录系统的时间

作者: candyzc 时间: 2012-10-22 14:19
“平均响应时间”是，在这100个用户并发的过程中，1个用户的系统平均响应时间
如果500个用户，那就是在500个用户并发的过程中，1个用户的系统平均响应时间

你把一些EXTRARES的参数注释掉之后，响应时间会下降，这个属于正常范围，这部分的内容不影响功能的正常使用，只是不需要下载额外的资源，所以时间减少了

如果是500用户并发的时候要50几秒，那么用户体验一定不好，也就需要进行进一步的工作，找到系统的瓶颈，判断为什么时间这么长，到底是哪些原因造成的，这就是性能测试的难点与重点了！！

作者: 狮王之盾 时间: 2012-10-22 15:34
回复 7# moyudong

lr有个参数化的功能，可以模拟不同的用户登录系统

作者: 西风一任秋 时间: 2012-10-23 09:39
②

登陆页图片过大了，你分解响应时间再分析，估计传输耗费了不少时间

作者: moyudong 时间: 2012-10-23 10:14
回复 9# candyzc

嗯，+1，认同，哈哈。~~~
我还有个问题想问。
就是假如你是该系统的使用用户，当你点击了查询这个按钮功能时，，很巧的是也有499个人点击了，于是产生了并发查询了，那么。。。。是不是就说这个用户就真的要等待50秒左右才能看到查询结果？？？。。。

如果是真的话，那么我们现实生活中发生了这么大的并发可能性还真是少，又为什么要做并发测试呢？

作者: moyudong 时间: 2012-10-23 10:16
回复 11# 西风一任秋

服务器的CPU使用率低，18%左右！内存我没监控，不过我用cat /proc/cpuinfo后，看到有16个processor！！！top的load average只有第一个数值超过了1.00，后面2个的一直都是低于0.6.......

作者: xiaoshi_2011 时间: 2012-10-23 11:04
好问题，学习了

作者: oxygen001 时间: 2012-10-24 12:45
回复 12# moyudong

平均，50秒，每次都这样么？可能是某个用户响应比较长，而把这个平均值拉高了吧？

作者: msnshow 时间: 2012-10-24 22:46
回复 4# moyudong

就是取值的方式是90%用户的响应时间，但这个值是1个用户的值

作者: moyudong 时间: 2012-10-25 10:06
回复 15# oxygen001

用loadrunner分别跑了3次，都是50秒左右吧。而且那个是搭建的测试环境，做性能时没有其它的操作用户在使用的！
开发那边说是因为他们还没做优化，还有说是没有加“缓存”。这里的缓存我也不是很了解是啥情况。。！
嗯，你说的情况也很有可能，不过就算是某些个用户的响应时间较长，从而把平均值拉高了，但是，这里的“某些用户”也挺多的，这些“某些用户”的响应时间也是很高的。

作者: moyudong 时间: 2012-10-25 10:06
回复 14# xiaoshi_2011

嗯，哈哈~一起学习！

作者: moyudong 时间: 2012-10-25 10:09
回复 16# msnshow

因为平均响应时间是50s。
所以500个用户的90%=450个用户，假设这450个用户使用时间都是40-60波动咯（这样比较接近50这个平均值）。。。。那么剩下的50个用户呢？有的可能非常大100s都有可能，有的非常小10s都有可能。。。。
你的意思是这样么？

作者: Cathy_Xv 时间: 2012-10-25 13:16
学习一下，你们继续

作者: 高奕健 时间: 2012-10-28 19:28
我也来凑个热闹。
从上面几层楼的情况来看，楼主仅用一个账号进行多并发的测试方法存在着不足，并不能真实的评估被测系统的登录模块的性能。
有几个建议：
1、每个VU一个账号，使用LR的参数化实现即可。
2、将APP、DB两者单独部署，以便明确APP和DB的各自基础指标情况，如CPU、内存等。
3、初步猜测系统的DB存在应用上的瓶颈，可以采用部分屏蔽DB调用的做法，初步判断DB是否瓶颈。
4、应找出不同的并发数下APP、DB两者的CPU拐点，进一步分析系统瓶颈。

试一下，再把结果贴上来，大家一起讨论吧

作者: moyudong 时间: 2012-10-29 09:57
回复 21# 高奕健

哈哈~~是的DB和应用系统是部署在同一台机器上的，还有他们的应用程序是还没程序优化所以很多种原因。。！
不过我是没试过参数化VU...

作者: kingsang 时间: 2012-10-30 09:35
我的理解是这样的，这个时候有99个用户在同时登陆系统，此刻你也登陆系统的话，你登陆系统所用的时间就是那个响应时间，并且另外99个用户中有将近90%的人登陆系统所用的时间是那个响应时间；当然你的那种场景测试出来的结果可能不太符合真实的情况，因为可能你自身的服务器限制了系统的性能等

作者: kate_moss 时间: 2012-10-30 14:52
继续关注和学习，我认为没必要在200这一定有瓶颈了，因为响应时间已经超出2.5.8原则了，还有就是看下服务器的配置等。并发200也是很大的压力的

作者: kate_moss 时间: 2012-10-30 14:56
需要看下服务器的部署，架构是怎么做的。是web应用的系统，我个人认为应该在应用层，还没到数据库，说白了，他的登录就是查询了一遍注册表，而且是单表，这个应该数据库处理很快，刚他提到图片很大，然后看看web应用的tomcat的参数配置是不是最优的。

作者: ffwithvv 时间: 2012-10-30 15:31
我先来解释一下前面一些TX提到的90%的概念。这个90%也叫用户感受百分比，什么意思呢，就是说你采样的数据中有90%的数据比这个值小，有10%的数据比它大。举个例子，一组数据{1,3,4,6,5,7,8,2,9,10}，从小到大排序以后是{1,2,3,4,5,6,7,8,9,10}，这组数据中，第9大的数字是9，然后90%的这个值就是9.他的作用是来了解在某个响应时间内有百分之多少的用户。不知道这样解释，你是否明白

作者: ffwithvv 时间: 2012-10-30 15:51
在回答你提的一些问题：
那个平均时间，就是平均一个用户登录系统所需要的时间。
由于你在录制脚本的时候，有think time的存在，所以你运行场景的时候，think time 也必然是会运行，这样有可能导致登录时间变长，但有think time的存在，可以比较真实的还原用户登录这样一个场景。如果你仅仅是只要做负载测试，那么建议think time可以去掉。
还有，你在录制脚本的时候，建议把run-time-setting里面的Browser Emulation下的 download non html resources的勾去掉
最后，你提到做500个并发还有意义吗？这个问题其实是回到了性能测试的需求上来了，你做这次性能测试的目的是什么？是为了看一下你的服务器能承载多少个用户登陆而不崩掉，还是说，在一定的时间内，比如5秒内，最多可以并发多少个用户登陆？如果需求不明确的话，那么盲目的做性能测试是没有意义的。
有说的不对的地方，欢迎各位指正，谢谢

作者: 丁香 时间: 2012-10-31 15:23
报告结果中可以看到每个用户的登录时间的，即采集的各个用户登录时间。
“因为平均响应时间是50s。
所以500个用户的90%=450个用户，假设这450个用户使用时间都是40-60波动咯（这样比较接近50这个平均值）。。。。那么剩下的50个用户呢？有的可能非常大100s都有可能，有的非常小10s都有可能。。。。
你的意思是这样么？”这样推算，不如使用450个用户并发试一下。500个用户一般不会使用同一台客户端进行测试，可以考虑分散在几台客户端上进行测试。这样情况更接近真实情况。
再不行，可以考虑使用虚拟IP。

作者: moyudong 时间: 2012-10-31 16:26
回复 25# kate_moss

看来大家都比较有经验啊~~~说的都很技术性！
请问，你提到的258原则是什么？
还有“应该在应用层，还没到数据库，说白了，他的登录就是查询了一遍注册表，而且是单表，这个应该数据库处理很快，刚他提到图片很大，然后看看web应用的tomcat的参数配置是不是最优的。”

这句话听得不是很明白~~！例如，登录怎么会去查询注册表呢？我对各个方面的知识可能掌握得不是很全面和深入，希望解释得清点。thx

作者: moyudong 时间: 2012-10-31 16:28
回复 28# 丁香

一般并发用户数达到多少，我们就需要参数化用户或者虚拟IP？？？

作者: moyudong 时间: 2012-10-31 16:29
回复 28# 丁香

一般并发用户数达到多少，我们就需要参数化用户或者虚拟IP？？？
你说要我用450个用户并发试下，那只不过是90%的基数变了而已，我没看出这句话的意图是。。。。
请指教~~~~~

作者: moyudong 时间: 2012-10-31 16:33
回复 27# ffwithvv

嗯好的，首先我的性能需求就是要看系统能不能支持大并发数的访问，也就是500个用户，我测出来的数据，响应时间高，但是CPU使用率都是在10%以下的，系统承载能力可说是不错的吧！

再者，我一般做性能测试，无论是多少个用户，5、50、500个我都是把think time给注释掉的，因为没注释掉的话，时间真的话很高。！主要测的是客户端到服务器端的响应，不用考虑什么思考时间了。所以注释掉了。

最后，“建议把run-time-setting里面的Browser Emulation下的 download non html resources的勾去掉”，这个的作用是？

作者: moyudong 时间: 2012-10-31 17:07
回复 26# ffwithvv

不明白。。。

啊哈！

作者: ffwithvv 时间: 2012-11-1 10:18
回复 32# moyudong
如果把勾去掉，表示不会下载非html以外的资源

作者: qianwange 时间: 2012-11-1 11:31
回复 27# ffwithvv
非常赞同，性能测试一定要目的明确，明白期望的目标是什么，是响应时间，是系统支撑的最大并发数，还是达到一定的tps。做测试前，一定要有计划，场景是什么，为什么要设计这样的场景，针对不同的场景，采用不同的测试方法等等吧

作者: moyudong 时间: 2012-11-2 09:59
回复 34# ffwithvv

原来啊，就是字面意思啊~我以为啥，哈哈~~！！谢啦。
话说，非html一般是指啥，知识不是很过关。。。

作者: moyudong 时间: 2012-11-2 09:59
回复 35# qianwange

嗯，是的~~~我也赞同，aha

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)