根据在之前的压测过程碰到的问题今天稍微总结总结以后方便自己查找。一、单台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进行查找结果是模糊匹配所以需要额外资源进行计算如果使用xy的条件查询速度就会快很多。三、当压测线程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比较多。最后下方这份完整的软件测试 视频教程已经整理上传完成需要的朋友们可以自行领取【保证100%免费】软件测试面试文档我们学习必然是为了找到高薪的工作下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料并且有字节大佬给出了权威的解答刷完这一套面试资料相信大家都能找到满意的工作。
根据在之前的压测过程碰到的问题今天稍微总结总结以后方便自己查找。一、单台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进行查找结果是模糊匹配所以需要额外资源进行计算如果使用xy的条件查询速度就会快很多。三、当压测线程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比较多。最后下方这份完整的软件测试 视频教程已经整理上传完成需要的朋友们可以自行领取【保证100%免费】软件测试面试文档我们学习必然是为了找到高薪的工作下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料并且有字节大佬给出了权威的解答刷完这一套面试资料相信大家都能找到满意的工作。
