记一次近期的性能项目，负载测试寻找TPS拐点的过程。由于环境限制，本次并没有进行压力测试、极限测试、稳定性测试。
按照步骤梳理如下：
1、通过跳板机登录到服务器（mac的跳板机和termius配置，后续整理）,启动每个负载机的jmeter-server
2、启动被测集群中，每个服务器上的serverAgent,用以收集服务端的CPU、内存、network I/O
3、基准测试
只用一台负载机，循环跑1000次，得到平均响应时间，作为基准RT。
4、小并发找拐点
因为目的是找系统处理能力饱和时的拐点，所以采用小并发逐渐增加线程数的方式。先用50个线程，无限循环，执行一段时间，记录RT和TPS；再用100，150，观察数据的大小，可在中间加些采样点。根据自己的服务不同，探索值要尝试很多次，这也是最耗时的地方，对于得到的拐点值，也要多跑几次，验证准确性。
得到的一组数据：
5、根据分析出的拐点值，考察下此并发数时的服务端性能，看是否达到饱和状态。这里通过linux自身的top快照，和perfmon的数据指标图一起验证。
top快照如下，CPU折算为约81%（4核）：
perfmon图如下内存稳定在27%，CPU稳定在80%，network I/O折算后为3.05M/s：
再看下负载机的性能曲线，内存为20%，CPU在最初达到80%，后续负载稳定后，降到20%，network I/O折算后为9.45M/s（master机收集被测集群中3台服务器的指标，与上面的数据能够对应）：
6、此时一个接口的拐点指标就找到了。如果环境支持，需要用大并发来找到系统支持的最大并发数，即响应时间90分位值小于阈值的点。
7、利用最大并大数，做压力测试，执行半小时看下效果。
8、80%最大并发数，进行稳定性测试，至少压4小时。