性能测试调优一：
1.首先，看下选测交易的整个走向
纯系统内部交易：
选测交易如果是系统内的交易，每一步请求都和系统交互几次，访问了几个数据库，访问了数据库的那几张表？？
该交易走了那几台机器，这几台机器的网络连接情况是什么样的？？这几台机器是通过走的是哪些虚拟网卡，走了哪些路由器？？带宽是什么情况？？
该交易在这几台机器上消耗了多少CPU，内存，及其对磁盘做了多少次的访问？？
从方法层面，从该交易的发起到结束，起了多少线程，调用了哪些相关的方法以及接口，访问了哪些表？？？
跨系统交易：
该交易发起后，每一步请求在系统内走了几次，调用了哪些接口，调用了几次，访问了哪些数据库以及哪几张表？？
了解了以上内容后，才能准确的把握每个交易的压力点在哪里
在性能瓶颈分析时，从不同的层次去分析问题可能出现在哪一个具体的位置
2.合理的利用各种监控工具
系统资源监控，通常通过nmon来监控分析
应用层的监控，通常通过开源的工具如jprofile java自带的jconsole visualvm以及商业化的软件如dynatrace
数据库层的监控，通常利用数据库本身的DB Snapshot（DB2快照 DB2top Oracle的AWR报告） 或者 Spotlight on db2 oracle 等等
3.仔细检查系统的各项参数配置，确保这些参数在最优状态
应用线程池
应用的日志级别
数据库连接池
操作系统级别的参数：文件句柄、TCP连接数等等
各个机器的资源大小是否合理：cpu、内存、磁盘空间、网络情况等
某些特定应用自带的一些参数设置（ESB 大数据平台等）
发压端的机器配置（网路情况、CPU、内存等等）
发压脚本的参数化以及参数化取值的方式是否合理，发压脚本是否本身存在一些bug或者不合理的内容
4.根据遇到的具体问题发挥你聪明的大脑，逐层分析，验证性能瓶颈的怀疑对象，逐个排除
直到找到最终的问题所在
几种常见的问题分析：
压力上不去，不管怎么增加用户，系统的压力始终维持在一个点，且此时的资源消耗也很少，几乎可以忽略不记
查看系统日志，看是否有相关报错信息，如应用线程不足、数据库连接不足的情况，如果存在，调整后验证问题是否还存在
通常该情况是在某个资源的限制导致了压力传导不了后方，当然上述只是个人遇到的情况，也可能是其他原因造成的，需要根据实际
的情况去具体问题具体分析。
以下几种在后续在分析：
随着压力的上升，响应时间变长
随着压力的上升，TPS出现波动
并发过程中，大量报错，交易成功率过低
等等。-------未完待续
本人技术能力有限，还希望看到本文的大师多多指教，相互学习，共同提高
2018年8月
原文地址：https://www.cnblogs.com/vinnfung/p/9465401.html