性能测试调优篇---未完待续

性能测试调优一：
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月