1. JMeter单机产生的压力不足，你会采用哪些具体的方法来解决这个问题？并且说明采用这个方法和工具的原因是什么？
答案一：https://blog.csdn.net/dboyII/article/details/80517830
JMeter集群测试架构
JMeter支持以集群的方式进行压力测试。一台机器资源有限，如果可以在多台机器上同时发出测试请求，则压测并发量可以增加很多，不用局限于一台机器的限制。JMeter采用控制机(Controller，或Master)-代理机（Agent，或Slave）的模式组成集群测试架构。控制机与代理机是一对多的关系，控制机上配置代理机的地址列表，以JMeter客户端的方式运行，将脚本远程发送给代理机执行，代理机上JMeter以Server的方式运行，代替控制机执行脚本，发送压测请求给测试机。如果压测脚本上ThreadGroup的并发用户数是10，那么在有三个JMeter代理机的集群中，最后压到测试机上的并发用户数将是30，以此类推，如果压测脚本中规定并发量是100qps，那么最终压到测试机上的并发请求将是300qps。代理机上执行测试请求之后，会将统计信息回传给控制机，由控制机在界面或者终端统一显示当前的测试汇总。
答案二：
分布式压测我理解的就是有一台主控机和几台压力机。主控机通过远程控制压力机启动测试，来实现系统不同级别访问量情况下的性能验证。
1、分布式测试中，选择一台作为管理机（Contorller），其他的机器作为测试执行的代理机（Agent）；
2、执行测试时，由Contorller通过命令行将测试脚本发给Agent，然后Agent执行测试（不需要启动GUI），同时将测试结果发送给Contorller；
3、测试完成，可以在Contorller上的监听器里面看到Agent发来的测试结果，结果为多个Agent测试结果汇总而成
为什么要使用分布式压测：
按照一般的压力机配置，jmeter的GUI模式下（Windows），最多支持500左右的模拟请求线程，再大的话，容易造成卡顿、无响应等情况，这是限于jmeter其本身的机制和硬件配置。
有时候为了尽量模拟业务场景，需要模拟大量的并发请求，这个时候单台压力机就显得有心无力。针对这个情况，jmeter的解决方案是支持分布式压测，即将大量的模拟并发分配给多台压力机，来满足这种大流量的并发请求场景
2. 基于线上正在运行的产品进行压力测试，会遇到什么具体问题，怎么解决？最好能举例子
https://www.sohu.com/a/275662999_371153
1、线上压测时间选择
线上压测有一个核心原则，就是不能影响真实用户的使用。因此时间都是选择每天业务最低峰，一般都是在0:00-6:00之间，这样对系统的影响最小，发出通告，进行压力测试。
2、线上压测数据准备
线上压测不能使用真实的用户数据，一般都是提前准备一批线上压测专用账号。这些账号往往都比较特殊，比如用户id都以xx开始，或者用户id的长度都是多少位等。根据业务不同，其他可能还需要一些业务数据。
如果涉及到一些金钱的操作，比如发短信，提前把开关关闭。否则后果很严重（别问我怎么知道的）
3、线上压测报备和预案
a> 压测前一定下报备，通知相关的责任人，如运维、DBA、研发、运营、测试团队等
b> 各团队必须有指定人员现场支持，出现紧急情况便于及时处理
c> 对业务系统压测前，要和开发和运维团队做好预案，比如系统宕机后，怎么恢复
d> 如果压测涉及到写库操作的，一定提前做好数据清理方案
4、线上压测执行策略
a> 起始并发一定要小一些，防止系统性能不好，直接崩溃
b> 压测时间不宜过长，除特殊场景外，一般3-5分钟即可
c> 压测时系统要做系统全链路监控，一旦出现异常情况，如机器负载高、报错率上升等，应立即停止压测，排查问题。
5、 数据清理
压测结束后，要根据提前制定的数据清理方案，将压测产生的垃圾数据清理掉，比如执行SQL。
6、会遇到的问题，
1、有安全机制，无法饶过，需要加一些白名单请求
2、没有大量的真是用户数据去模拟
3.服务器以及系统响应慢怎么定位
一般从三个方面定位问题，服务器，代码，数据库
1、我们公司产品使用阿里云服务器和香港代理服务器，首先排查阿里云服务器，阿里服务器有自己的监控面版。
第一步：登录后台服务器/监控平台，查看系统资源是否达到上限，例如：CPU、内存、磁盘、I/O、网络带宽等，
如果是这些问题，先将这些问题逐一解决：
如果是CPU的问题，则需要查看一下CPU占比比较高的进程，然后使用jstack命令生成进程的堆栈信息，看是否发生频繁Full GC，如果是的话，还需要看一下内存快照，分析一下内存情况（可以使用java自带的或第三方工具）；如果是磁盘空间满了，及时清理磁盘；如果是带宽问题，联系网络工程师解决。如果以上这些问题都没有，则进行第二步。
第二步：检查应用服务器（Jboss/Tomcat）的线程池配置是否合理，看一下请求的排队现象是否严重，如果严重则需要重新设置合理的线程池。同样，检查一下数据库的连接池设置是否合理，增大连接池设置，同时检查一下是否有慢sql，如果有慢sql，则进行优化（优化方案是查看执行计划，设置合理的索引等）。
第三步：查看访问慢的服务的调用链，查看一下调用链中的每一步响应时间是否合理，如果不合理，则联系相关系统的负责人进行排查和解决。
第四步：检查web服务器的请求日志，看一下是否存在Doss攻击，如果有Doss攻击，则将攻击者的IP添加到防火墙的黑名单里。