7个常见的Jmeter压测问题总结

根据在之前的压测过程碰到的问题，今天稍微总结总结，以后方便自己查找。

单台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的条件，查询速度就会快很多。

当压测线程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比较多。

最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取