一、标题Jmeter常见问题解决
1.1 Jmeter如何针对https协议进行接口测试？
解决方法： 协议更改为：https，端口号更改为443；Jmeter默认的是：http协议，端口号是：80
1.2 Jmeter如何解决默认中文显示？
解决方法：
通过编辑jmeter目录/bin/jmeter.porperties文件，将其language的值更改为：zh_CN，然后保存，重启Jmeter即可。
1.3 Jmeter如何解决Sampler响应结果乱码？
原因：jmeter默认是ISO-8859-1编码，可以通过修改：jmeter.properties文件
解决方法：
将sampleresult.default.encoding=ISO-8859-1，将其修改为sampleresult.default.encoding=UTF-8；保存后，重新启动Jmeter即可。
1.4 Jmeter历史版本在哪里下载？
Jmeter历史版本下载： http://archive.apache.org/dist/jmeter/binaries/
1.5 Jmeter插件本在哪里下载？
Jmeter插件下载地址： https://jmeter-plugins.org/downloads/all/
对于JMeterPlugins-Extras-1.4.0.zip 和 JMeterPlugins-Standard-1.4.0.zip
解压这两个.zip包，分别取出\lib\ext目录下的，然后重启Jmeter
1.6 JMeter中引入外部的JAR包给bean shell 使用？
方法1：在测试计划中，通过浏览按钮，将需要导入的jar包引入
方法2：直接将需要引用的jar包放置到JMeter的lib目录，或者ext目录下
方法3：设置插件依赖路径，此时需要在jmeter.properties中添加依赖的路径，在dependencies中添加需要添加的jar包（推荐）
1.7 Jmeter进行http协议接口测试Json格式时注意事项
需要添加HTTP信息头信息：Content-Type=application/json ，否则会报错；
1.8 Jmeter 非GUI或GUI时生成不了html报告的原因？
jmeter.save.saveservice.output_format=xml，将该xml值更改为：csv即可；在使用上方的命令即可生成html报告，在生成testResult的文件夹,文件夹中有一个index.html文件,在浏览器中可以直接点开
二、标题根据在之前的压测过程碰到的问题，今天稍微总结总结，以后方便自己查找。
问题一
单台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比较多。
问题八
代理服务器提示网络不安全
解答：代理服务器提示网络不安全
持续记录整理。。。
—The End—
后续有好方法还会继续更新，欢迎大家一起交流互助。
如果对你有帮助请关注哦！