用loadrunner时大并发数100个并发登录系统时产生了疑问。
今天做一个项目的登录并发，但是登录的页面图片大小达到了1M左右。所以并发时间就很大了。
于是我注释掉了EXTRARES后面的图片，再并发，发现平均响应时间小了3秒。
已注释图片的脚本：
无注释图片的脚本：
显然没有注释掉的响应时间较大。
然，我这里想问的是，这里的“100个并发用户的响应时间”是指①服务器同时处理这100个并
发用户登录的时间，还是指②在100个并发的情况下，处理1个用户登录系统的时间？
当我处理500个并发的时候，在无注释图片的脚本时，平均响应时间达到了50多秒。！！！
如果是第②种情况的话，那么是不是就说明实际操作中（真实用户使用过程中），如果你在登录的时候真的发生了500个并发的情况，那么是不
是就得等50几秒你才能完全登录到系统。 好问题。我也不知道。坐等回复 是指一个用户所用的时间，但这里是的值是指90%用户所用的时间 回复 3# msnshow
能根据我的提问进行剖析么？
你说是指一个用户所用的时间，然后又说这里是指90%用户所用的时间，这个是什么情况，听起来有点儿矛盾，个人理解能力不是很好，麻烦说清点，谢谢！
PS：如果是500用户并发的时候要50几秒，用户体验不是很糟糕了么。。。 一百个并发情况下，平均一个用户所用的时间。 问题1：你如果对登录没有做参数化的话，就是拿一百个同一个账号同时进行登录操作；
问题2：这个50多秒只是代表一个平均的时间，实际略有偏差
不知道我的回答是否正确，请高手指点 回复 6# 狮王之盾
" 你如果对登录没有做参数化的话，就是拿一百个同一个账号同时进行登录操作"
这里的登录参数化是指？？我确实用同一个账号在进行登录操作。
这50多秒的前提条件还是100个用户并发呢！ 对于“平均响应时间”来说，理论上就是100个并发的情况下，处理1个用户登录系统的时间 “平均响应时间”是，在这100个用户并发的过程中，1个用户的系统平均响应时间
如果500个用户，那就是在500个用户并发的过程中，1个用户的系统平均响应时间
你把一些EXTRARES的参数注释掉之后，响应时间会下降，这个属于正常范围，这部分的内容不影响功能的正常使用，只是不需要下载额外的资源，所以时间减少了
如果是500用户并发的时候要50几秒，那么用户体验一定不好，也就需要进行进一步的工作，找到系统的瓶颈，判断为什么时间这么长，到底是哪些原因造成的，这就是性能测试的难点与重点了！！ 回复 7# moyudong
lr有个参数化的功能，可以模拟不同的用户登录系统 ②
登陆页图片过大了，你分解响应时间再分析，估计传输耗费了不少时间 回复 9# candyzc
嗯，+1，认同，哈哈。~~~
我还有个问题想问。
就是假如你是该系统的使用用户，当你点击了查询这个按钮功能时，，很巧的是也有499个人点击了，于是产生了并发查询了，那么。。。。是不是就说这个用户就真的要等待50秒左右才能看到查询结果？？？。。。
如果是真的话，那么我们现实生活中发生了这么大的并发可能性还真是少，又为什么要做并发测试呢？ 回复 11# 西风一任秋
服务器的CPU使用率低，18%左右！内存我没监控，不过我用cat /proc/cpuinfo后，看到有16个processor！！！top的load average只有第一个数值超过了1.00，后面2个的一直都是低于0.6....... 好问题，学习了 回复 12# moyudong
平均，50秒，每次都这样么？ 可能是某个用户响应比较长，而把这个平均值拉高了吧？ 回复 4# moyudong
就是取值的方式是90%用户的响应时间，但这个值是1个用户的值 回复 15# oxygen001
用loadrunner分别跑了3次，都是50秒左右吧。而且那个是搭建的测试环境，做性能时没有其它的操作用户在使用的！
开发那边说是因为他们还没做优化，还有说是没有加“缓存”。这里的缓存我也不是很了解是啥情况。。！
嗯，你说的情况也很有可能，不过就算是某些个用户的响应时间较长，从而把平均值拉高了，但是，这里的“某些用户”也挺多的，这些“某些用户”的响应时间也是很高的。 回复 14# xiaoshi_2011
嗯，哈哈~一起学习！ 回复 16# msnshow
因为平均响应时间是50s。
所以500个用户的90%=450个用户，假设这450个用户使用时间都是40-60波动咯（这样比较接近50这个平均值）。。。。那么剩下的50个用户呢？有的可能非常大100s都有可能，有的非常小10s都有可能。。。。
你的意思是这样么？ 学习一下，你们继续
页:
[1]
2
