用loadrunner时大并发数100个并发登录系统时产生了疑问。

moyudong · 发表于 2012-10-19 16:15:07

今天做一个项目的登录并发，但是登录的页面图片大小达到了1M左右。所以并发时间就很大
了。
于是我注释掉了EXTRARES后面的图片，再并发，发现平均响应时间小了3秒。
已注释图片的脚本：

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

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

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

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

moyudong · 发表于 2012-11-2 09:59:42

回复 35# qianwange

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

moyudong · 发表于 2012-11-2 09:59:17

回复 34# ffwithvv

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

qianwange · 发表于 2012-11-1 11:31:16

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

ffwithvv · 发表于 2012-11-1 10:18:54

回复 32# moyudong
如果把勾去掉，表示不会下载非html以外的资源

moyudong · 发表于 2012-10-31 17:07:24

回复 26# ffwithvv

不明白。。。

啊哈！

moyudong · 发表于 2012-10-31 16:33:26

回复 27# ffwithvv

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

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

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

moyudong · 发表于 2012-10-31 16:29:43

回复 28# 丁香

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

moyudong · 发表于 2012-10-31 16:28:24

回复 28# 丁香

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

moyudong · 发表于 2012-10-31 16:26:44

回复 25# kate_moss

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

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

丁香 · 发表于 2012-10-31 15:23:51

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

ffwithvv · 发表于 2012-10-30 15:51:11

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

ffwithvv · 发表于 2012-10-30 15:31:38

我先来解释一下前面一些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.他的作用是来了解在某个响应时间内有百分之多少的用户。不知道这样解释，你是否明白

kate_moss · 发表于 2012-10-30 14:56:31

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

kate_moss · 发表于 2012-10-30 14:52:07

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

kingsang · 发表于 2012-10-30 09:35:11

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

moyudong · 发表于 2012-10-29 09:57:39

回复 21# 高奕健

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

高奕健 · 发表于 2012-10-28 19:28:39

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

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

Cathy_Xv · 发表于 2012-10-25 13:16:39

学习一下，你们继续

moyudong · 发表于 2012-10-25 10:09:44

回复 16# msnshow

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

		自动登录	找回密码
密码			(注-册)加入51Testing

[求助] 用loadrunner时大并发数100个并发登录系统时产生了疑问。

本帖子中包含更多资源

相关帖子

站长推荐 /1