1.前提概念
平时常用的性能测试：api性能测试+场景性能测试；今天就说一说api性能测试
2.如何进行性能测试？
需求：对某api进行性能测试，看看最大承受的并发数，分析下图表
分析：
错误思路：当我们接到这个需求的时候，很多人不管三七二十一，先把接口写起来，然后给他个1000个并发，压倒报错为止，但是实际上你知道怎么去压测么，怎么分析TPS么？怎么找到最大并发数？怎么分析报错请求？那我们到底怎么分析呢
分析思路：
- 首先，api测试嘛，我先把api脚本给调试好，
- 然后加各种图表分析报告
- 之后设计各种场景，例如：设计场景1：并发20个用户，每秒增加2个用户，请求2000次；场景2：分析TPS，并发200个用户，每秒增加20个用户，请求2000次。。。。。。。依次类推
3.性能指标
在我们实战前，先了解一下性能指标：
通常情况下，一般我们可能不会添加其他插件的前提下，都会添加一个监听器->聚合报告，那么聚合报告到底用来做什么的呢？
我们可以看见：average(平均响应时间) median,90% 95% min (最小) ，max(最大) 都是跟时间有关系，所以我们可以侧面理解为，聚合报告，大部分就是监控整个访问时间
其他：
sampler:一共完成了多少请求
Throughput:吞吐量，默认情况下标识每秒处理的请求书，可以指服务器处理能力，tps越高说明服务器处理能力越好
4.实战
1.准备脚本
场景1：并发20个用户，每秒增加2个用户，请求2000次，
线程组：相当于并发多少用户
Ramp-UP: 每秒增加2个用户, 20/2=10 ,所以填10，意思是1秒内往上加2个用户
循环：请求2000次；计算：20000/线程组（20）= 100
2.脚本分析
分析一波：
首先右上角：3/20 : 当前线程往上加，最大并发数是20，3是当前线程数
看下报告：
1.sampler:当前一共2000个请求
2吞吐量远远大于20个线程组数，tps很高，说明服务器完全能承受；
3.场景二脚本分析：
场景：并发200个用户，每秒增加20个用户，请求20000次
分析：
1.首先错误率很高，就能看出很多了
2.吞吐量小于当前并发数，说明200个并发数不适合，已经不能够承受了
3.为了找到最合适的并发数。可以设计不同场景，例如用二分法，100个并发用户，150个并发用户之类，
5.总结
其实性能测试远远不止于这些，但是从基础的吞吐量，以及并发数，我们就可以分析很多问题了，如果设计服务器上监控，那么又是一个概念了。我觉得从这篇文章至少我们可以坚持api性能的最合理的并发数，以及tps. tps越高说明性能越好。若压测的机器性能很好，出现吞吐量小于并发数，说明并发数不能再增加了，可以慢慢减下来，找到合理并发数
ps: 有错误欢迎指出来，虚心请教。