一、基准测试
1、单并发循环看响应时间 ，找出超过200MS(或超过目标响应时间)的请求
2、对响应时间慢的请求，理清完整的调用链路，通过日志逐步对响应时间的拆分，定位主要消耗点。
3、可以借助工具定位，比如skywalking，可以明确定位，时间消耗位置。(可以明确定位到在服务啊，redis啊，数据表啊)
二、基准测试问题优化后，再发现并发问题
并发测试
1、看tps曲线，正常曲线是随着并发线程的逐步增加，tps达到最高点时，再增加并发也基本保持最高点，响应时间逐步增加
1.1、忽高忽低问题(定时任务或命中策略)
1.2、开始很高，压力持续后，逐步下降(数据表数据量增加，无索引)
1.3、看总的处理能力，如果服务器配置还不错，资源使用上不去，tps非常低，那么就是代码逻辑有问题（线程锁、等待等）。
cpu消耗高，tps较低
如果较简单的逻辑，几十tps就有问题
三、内存曲线是否平稳
1,上升过快，说明在大量消耗内存，分析是否合理
2,忽高忽低，说明在频繁gc,太频繁不合理，影响性能
3,内存使用率迅速上升持续高位后，导致服务重启，可能存在内存泄露。
四、增加查看请求队列值，太大说明用户在排队，势必拉长响应时间，降低总tps,如果资源应用较低，队列较大。--新增监控
五、查看磁盘IO是否正常，IO使用率太高会影响性能。
六、查看网络IO是否正常，结合自身带宽。
七、查看数据库IOPS
其他如果某些场景有问题，又不知道问题位置，
场景比对，可以通过不同的场景策略对比，或增加或减少场景，逐步缩小问题定位点。
