求助：模拟500用户一直并发，这样做正确吗？
现在要做nginx测试，录好一个简单的脚本，脚本中访问一个页面，无思考时间。然后设置500Vuser，时间设为10分钟，开始跑。CPU使用100%，没法运行了。请问要进行什么设置吗？怎么会这样，压测机配置挺好的，应该不至于啊。
测试的要求是模拟500个用户一直访问10分钟，看响应时间和TPS是否符合要求。
先谢过！ 好像云层大侠说过一个吃饭的事情：让你吃了早饭不休息直接吃午饭再不休息吃晚饭，你能吃得消吗？:lol
然后我理解要在runtime setting里设置个pacing time 500vuser，tps多少？应该符合要求了吧 tps都10000多了，是空的nginx反应速度非常恐怖，压测机都吃不消了。如果设置了pacing time会不会使TPS不准确？算TPS时把pacing time的时间也算进去，响应时间会不会也受影响？ 回复 2# xxllff2000
tps都10000多了，是空的nginx反应速度非常恐怖，压测机都吃不消了。如果设置了pacing time会不会使TPS不准确？算TPS时把pacing time的时间也算进去，响应时间会不会也受影响？ 我试了下加pacing time，CPU是下去了，可TPS也下去了，可开发要最重要的数据就是TPS。怎么办才好呢？ 你一个人不停的把三峡的水打到上游，你觉得你能测试出来三峡的下行并发量么？自己不累么？ 老师，能掰开来说么？不懂啊。给个方案好吗，谢谢啦。 我觉得lz讨论的性能指标这块有一些模糊，VUSer数量≠用户数量≠连接数量≠TPS，你设置了500个VUser希望能一直让服务器始终保持500个“并发”连接，测试它的并发能力，还是关注TPS，验证nginx空交易下的最大处理能力？
我一直认为VUser只是LR提供的一种并发手段，它很难代表前端用户数量（如果想要有一个数值转换，就需要估算前端用户的操作习惯，这个很难统计准确），而考虑到交易的处理速度，它也不能直接代表服务器端的并发连接数量，VUser唯一方便转换的就是TPS，如二楼说的，通过设置Pacing值可以让VUser和TPS之间有一个可控的转换，如并发下每笔交易响应时间都在1秒以下，Pacing设置为fixed 1秒，就可以让VUser与TPS是1:1的关系。
我比较推荐使用TPS方式进行测试，参考以响应时间。性能测试的大部分系统都应该能估算出上线后的日均、日峰、未来扩展的交易量，这样很容易换算成TPS，我们就以TPS为目标加压即可。对于不好预估的系统，TPS和响应时间同样也是衡量系统处理能力最准确的数值，假设一个系统最大TPS就是1k，而且系统很稳定不会崩溃，你并发500 VUser时响应时间0.5秒，并发1k VUser时响应时间1秒，并发1w时响应时间10秒了，再涨并发TPS不变响应时间上涨，这时你应该如何描述系统的处理能力呢？按最后的VUser数量描述？返回到上面说的，VUser代表能支持前端有多少用户？代表系统并发连接数？
可能也有人说我按2/5/8原则，记录响应时间到8秒时候的VUser数量，但2/5/8原则是什么时候提出的？是否还符合现在B/S架构的评估标准？是否符合你测试系统的时间标准？不可行也很难解释清楚。所以我建议弱化VUser的概念，弄清楚你测试的目的，尽量以TPS衡量。 测nginx用LR不合适 版主能详细说说吗 回复 9# dionysus
恩，学习了。可对于这个测试方法还是不太清楚。 回复 7# 云层
云层说话真是有意思~~:lol 正常的用户访问一个页面假如用2秒，那LR中的一个虚拟用户，若不加pace和思考时间的话，在2秒内或许能访问该网页10次或许还不止。所以，500个虚拟用户不能和500个虚拟vuser同等。
加上些pace或是思考时间，或许更真实些
另外，不考虑思考时间的话，可以先观察一下LR提供的资源图，在什么时候，TPS在不再增加且点击率趋于平稳，这或许是资源饱和的拐点。通过拐点上的某些数据，再结合一个vuser时的数据，推算出一个虚拟用户实际相当于多少个真实的用户。根据你们的需求，可以设计出合理的虚拟用户数，而非500虚拟用户。后面这段这是个人的美好设想。。。 路过，学习一下 多设计点case来做! 能说的直白点吗 回复 9# dionysus
学习了，谢谢
页:
[1]
