1、在测试之前，先看架构，具体到细节，知道数据交互路径。可以细分出每一部分的耗时。
调优先调参数，等参数全都健康了，再看代码逻辑sql等。因为调优系统配置，代价最小，提升最大。
2 测试核心：证据链。
最基本的通用方法是根据cpu等资源消耗定位代码。举些例子：
代码问题：cpu高➡️通过top命令查到进程➡️通过top itp等工具命令查出线程➡️通过jstack命令查看栈➡️定位代码。
数据库问题：若根据cpu高➡️查看进程是mysql➡️查mysql 执行日志➡️找出耗时最多的语句。
应用资源配置问题：cpu高➡️看进程是java➡️查看jvm的监控➡️发现堆内存使用率高，jvm 内存配置小➡️改大一点，直到趋势图呈波浪形，能触发垃圾回收，就是合适的大小。如果设置过大，会导致gc回收周期长，且上下文切换cs的值很高。正常的上下文切换状态，是波浪线，即周期触发垃圾回收。（比如jvm，tomcat中，使用值 = 设置值，说明设置的不够用）
推断过程中，除了会查各种软件日志，如应用日志、数据库日志等，也要会查看操作系统日志。（如linux的日志在var目录下，名字是dmesg）
3 具体测试：
3.1 性能测试只关注tps和响应时间。而响应时间：需要看架构每一步的耗时。
3.2 正常的系统不会有拐点，只会出现性能趋势衰减。性能衰减：总tps除以vu数的值降低了，就说明衰减了。
3.3 用户递增时，梯度不能断。不需要区分负载，压力等场景。用户递增建议速度：若响应时间<100ms，vu增加速度可设置为5~10;小于50ms可设置为1；大于1s可设置为10~20。
3.4 tps计算：所有工具计算tps，都是用所有线程事务数之和，除以总时间。
3.5 VU : 它只是线程数量，不是用户数量。比如5vu的运行结果是100Tps，说明系统能承受每秒100人同时访问，而不是5人。
3.6 操作系统中，多个指标占用率高，要先从慢的模块分析，如IO。
3.7 top命令看到si软中断若超过5%，则性能一定会下降。
3.8 性能问题中，网卡驱动、虚拟化等硬件问题比代码难。举个例子，从操作系统中IO高定位到线程，最后发现硬盘从ext3升级为4，IO运行原理改为先缓存，再写入disk硬盘，这会导致监控的IO使用率是满的，但diskIO的数值为0。
3.9 若cpu、IO产生了队列，则必然有性能问题。
4.0 数据热块 ： 参数化不合理导致反复用同一数据；
4.1 倾斜度：描述某一块被操作了多少次。
建议：
1、linux不够精通
2、对监控结果报告的数值不够敏感
性能问题的解决重在思路。