1.jmeter允许多个线程并发取样，那么，多线程有上限、瓶颈吗？
按我的理解，实际压测过程中，是用4台压测机，一台机器50-100并发量，jmeter应该是可以做到并发无压力的，如果jmeter做不到并发100，可查看压测机器的性能，是否因为内存、网络、cpu占用导致的瓶颈。
[图片上传中...(image.png-e7c64b-1615542119203-0)]
2.区分qps tps?
TPS:事务数/秒 一个事务可能包含多个查询
QPS:查询数/秒 （每秒响应的请求数）
QPS（TPS）：每秒钟request/事务 数量
并发数： 系统同时处理的request/事务数
响应时间： 一般取平均响应时间
QPS（TPS）= 并发数/平均响应时间
3.top 90 95 99如何理解？
tp99:一段时间的压测中，将每一次的请求记录，按响应时间从小到大排序，第99%的那个时间点
4.如何大概计算数据是否准准确？
通过梯度加压，记录tps、响应时间、网络io、cpu、内存等指标，确认此次压测是否达到正常的变化曲线
5.如何确保不受网络因素影响？
--一般如果是网络因素，引起的现象：无论开多少个线程，QPS一直压不上去，服务器和数据库的性能指标（主要是CPU和内存）一直维持在很低的水平。
--故，需在压测前确认，带宽不影响压测结果，服务器和压测机之间，没有流量限制。
6.思考：如何贴近实际的业务场景从而保证压测的准确性？
采取真实的线上数据、峰值作为样本；
思考具体业务场景，单接口压测、复合接口压测、比例根据真实业务来调节；
7.有哪些情况会导致压力较低，qps起不来？
①未关限流，导致压力值起不来；
②Master 机硬盘文件写满，导致压力降低；
8.一般来说，服务器发出的数据和压测机接收的数据返回值，流量是大致相等的，什么时候会对不上呢？
①压接口时，服务器端可能还会请求别的接口的数据，导致又接收了一些数据量，使服务器和压测机的数据流量匹配不上；
② 压测脚本header 头部没有添加压缩的格式；
如何计算流量：估算一个返回值的大小*返回值数量=服务器发出的流量
9.大量报错可能哪些？
①大网关 CPU 负载较大时，导致大量603报错；
②Redis 被压垮；
10.运行jmeter脚本时出现问题，排错步骤：
跑测试脚本时（1个线程 + 1次），查看生成的 jtl 文件是否正常，出现错误时优先查看 jmeter.log 的日志（在你运行 jmeter 启动命令的那个文件夹）；
