根据在之前的压测过程碰到的问题,今天稍微总结总结,以后方便自己查找。
一、单台Mac进行压测时候,压测客户端Jmeter启动超过2000个线程,Jmeter报OOM错误,如何解决?
解答:单台Mac配置内存为8G,可用内存最大为3.5G左右,启动一个线程将近需要1M内存,2000个线程,需要大概2G左右的内存;然后启动Jmeter,本身需要将近400M的内存,接着在运行过程中,Jmeter又使用了Respoonse Time、TPS、Thread等等的计数器也会占用额外内存;最后,Jmeter运行不到2分钟,导致Jmeter闪退,然后Mac OS重启,原因就是系统出现了Out Of Memory的错误。
建议:单台压测机器,启动线程不超过1000个,推荐500个左右,这样客户端性能比较好;如果要压测超过1000个线程,建议分成2台Mac机器进行压测,超过2000个,分成3台Mac机器压测,以此类推。
二、使用断言,是否特别消耗系统资源?
解答:使用Response Assertion 和Json Assertion这两种断言方式,不是太占用系统CPU资源;但是如果使用正则表达式进行断言,就会对系统的CPU有一定的消耗。这个好像使用SQL语句一样,使用Like进行查找结果,是模糊匹配,所以需要额外资源进行计算;如果使用x=y的条件,查询速度就会快很多。
现在我也找了很多测试的朋友,做了一个分享技术的交流群,共享了很多我们收集的技术文档和视频教程。
如果你不想再体验自学时找不到资源,没人解答问题,坚持几天便放弃的感受
可以加入我们一起交流。而且还有很多在自动化,性能,安全,测试开发等等方面有一定建树的技术大牛
分享他们的经验,还会分享很多直播讲座和技术沙龙
可以免费学习!划重点!开源的!!!
qq群号:1150305204【暗号:csdn000】
三、当压测线程500左右,没有使用集合点,TPS一直无法上到200以上,并且Error%率很低,不超过1%的错误率?
解答:Jmeter在脚本中,使用集合点-synchronizing point,计算TPS的算法跟脚本中没有使用集合点的TPS算法有区别;所以,当脚本中使用集合点,那么被集合点压测的接口TPS就会比没有被集合点压测接口的TPS高;所以,这个是设置的问题,不是服务器或者应用的问题。
四、页面性能需要压测吗?场景:多人反复登陆/退出/抢红包/多人提问/多人弹幕......
解答:其实页面的请求也是通过前端接口传递到后端接口,然后通过后端的接口拿到需要的数据,最后传给前端,让数据在前端页面展示;如果后端的接口响应慢,就必然会导致前端展示数据的速度慢;如果后端的响应速度快,前端的展示数据的速度仍然很慢,那么就跟客户端的机器CPU/内存/浏览器等配置相关,需要单独分析,不能一概而论。
建议:这个问题,一般都是前端的开发工程师提出来的,其实,前端的逻辑相对简单,主要是数据展示功能,数据的加工工程,都是放在后端来完成的;正常情况下,如果后端的接口响应很多,前端的接口响应速度应该不会慢。页面的展示功能,其实可以通过“分页加载”、“延迟加载”、“查询缓存而不是数据库获取数据”等等手段,都可以提高页面的响应速度,我就不班门弄斧了。
五、当使用Non-GUI模式运行Jmeter时候,TPS可以达到500-600左右,这个是啥原因?
解答:当压测客户端,使用命令行模式运行脚本,不是采用GUI模式运行脚本;如果GUI模式压测的结果是300TPS左右,当切换到命令行模式后,压测的结果是600TPS左右;这个一般是服务器的配置不一样、服务器的访问量不一样等等原因。正常来说,使用命令行运行脚本,压测客户端使用自己的资源会更少,但是,不会影响TPS的指标,因为,你压测的是服务器,不是你机器本身,跟客户端的资源没有半点关系。
六、并发线程数和并发用户数,是同一概念吗?
解答:对于loadrunner和jmeter之类常规性能测试工具来说,答案是肯定的;大家可以设置线程数100,循环1次,最后,总的请求数一定是:100。但是对于gatling比较特殊,用的是协程,比线程更小的单位,所以,并发线程数和并发用户数不能直接画等号。
七、TPS和QPS的区别是什么?
解答:TPS是每秒钟处理完的事务次数,一般TPS是对整个系统来讲的。一个应用系统1s能完成多少事务处理,一个事务在分布式处理中,可能会对应多个请求。每秒钟处理完请求的次数;注意这里是处理完。具体是指发出请求到服务器处理完成功返回结果。
对于衡量单个接口服务的处理能力,用QPS比较多。
最后,真心诚意地对每一个认真阅读我文章的人表示感激,你们的点赞、收藏和关注给予了我巨大的动力和勇气。在这个世界上,我们常常在奉献与回报之间徘徊,但我相信,礼尚往来并不仅仅是物质交换,而是一种情感的传递。