性能瓶颈测试分析与调优实践指南
1 引言
1.1 编写目的
本文通过编写性能测试分析及调优相关流程和方法，帮助研发人员、性能测试人员或者运维人员快速地进行性能测试、瓶颈定位及调优。系统的性能是由很多因素决定的，本文很难面面俱到，但是可以作为分析系统性能的一个指导。
1.2 适用对象和范围
适用于使用性能测试进行性能测试项目性能分析及调优依据。预期读者为测试管理人员、测试实施人员、技术支持人员、项目质量管理人员、项目管理人员等系统技术质量相关人员。
2 性能分析
2.1 前提
性能分析的前提除了需要丰富的性能测试监控（如PTS自身的客户侧监控、基础类监控-阿里云监控、应用类监控-ARMS监控等），还需要具备相关的技术知识（包括但不限于：操作系统、中间件、数据库、开发等）。
2.2 流程
很多情况下压测流量并没有完全进入到后端（服务端），在网络接入层（云化的架构比如：SLB/WAF/高防IP，甚至是CDN/全站加速等）可能就会出现由于各种规格（带宽、最大连接数、新建连接数等）限制或者因为压测的某些特征符合CC和DDoS的行为而触发了防护策略导致压测结果达不到预期，详情请见相关QA。
接着看关键指标是否满足要求，如果不满足，需要确定是哪个地方有问题，一般情况下，服务器端问题可能性比较大，也有可能是客户端问题（这种情况非常小）。
对于服务器端问题，需要定位的是硬件相关指标，例如CPU，Memory, Disk I/O, Network I/O, 如果是某个硬件指标有问题，需要深入的进行分析。
如果硬件指标都没有问题，需要查看中间件相关指标，例如：线程池、连接池、GC等，如
果是这些指标问题，需要深入的 分析。
如果中间件相关指标没问题，需要查看数据库相关指标，例如：慢查SQL，命中率，锁、参数设置。
如果以上指标都正常，应用程序的算法、缓冲、缓存、同步或异步可能有问题，需要具体深入的分析。
具体如下图所示：
2.3 可能瓶颈点
2.3.1 硬件/规格上的瓶颈
一般指的是CPU、内存、磁盘I/O 方面的问题，分为服务器硬件瓶颈、网络瓶颈（对局域网可以不考虑）。
2.3.2 中间件上的性能瓶颈
一般指的是应用服务器、web 服务器等应用软件，还包括数据库系统。例如：中间件weblogic 平台上配置的JDBC连接池的参数设置不合理，造成的瓶颈。
2.3.3 应用程序上的性能瓶颈
一般指的是开发人员开发出来的应用程序。例如，JVM参数不合理，容器配置不合理，慢SQL（可使用阿里云APM类产品如ARMS协助定位），数据库设计不合理，程序架构规划不合理，程序本身设计有问题（串行处理、请求的处理线程不够、无缓冲、无缓存、生产者和消费者不协调等），造成系统在大量用户方位时性能低下而造成的瓶颈。
2.3.4 操作系统上的性能瓶颈
一般指的是windows、UNIX、Linux等操作系统。例如，在进行性能测试，出现物理内存不足时，虚拟内存设置也不合理，虚拟内存的交换效率就会大大降低，从而导致行为的响应时间大大增加，这时认为操作系统上出现性能瓶颈。
2.3.5 网络设备上的性能瓶颈
一般指的是防火墙、动态负载均衡器、交换机等设备。当前更多的云化服务架构使用的网络接入产品：包括但不限于SLB/WAF/高防IP/CDN/全站加速等等。例如，在动态负载均衡器上设置了动态分发负载的机制，当发现某个应用服务器上的硬件资源已经到达极限时，动态负载均衡器将后续的交易请求发送到其他负载较轻的应用服务器上。在测试时发现，动态负载均衡器没有起到相应的作用，这时可以认为网络瓶颈。
2.4 方法
2.4.1 CPU
CPU资源利用率很高的话，需要看CPU消耗User,Sys,Wait那种状态下。
如果CPU User非常高，需要查看消耗在哪个进程，可以用top(linux)命令看出，接着用top –H –p <pid>看哪个线程消耗资源高，如果是java应用，就可以用jstack看出此线程正在执行的堆栈，看资源消耗在哪个方法上，查看源代码就知道问题所在；如果是c++应用，可以用gprof性能工具进行分析。
如果CPU Sys非常高，可以用strace(linux)看系统调用的资源消耗及时间。
如果CPU Wait非常高，考虑磁盘读写了，可以通过减少日志输出、异步或换速度快的硬盘。
2.4.2 Memory
操作系统未了最大化利用内存，一般都设置大量的cache,因此，内存利用率高达99%并不是问题，内存的问题主要看某个进程占用的内存是否非常大以及是否有大量的swap(虚拟内存交换)。
2.4.3 磁盘I/O
磁盘I/O一个最显著的指标是繁忙率，可以通过减少日志输出、异步或换速度快的硬盘。
2.4.4 网络I/O
网络I/O主要考虑传输内容大小，不能超过硬件网络传输的最大值70%，可以通过压缩、减少内容大小、在本地设置缓存以及分多次传输等。
2.4.5 内核参数
内核参数一般都有默认值，这些内核参数默认值对于一般系统没问题，但是对于压力测试来说，可能运行的参数将会超过内核参数，导致系统出现问题，可以用sysctl来查看及修改。
2.4.6 JVM
jvm主要分析GC/FULL GC是否频繁，以及垃圾回收的时间，可以用jstat命令来查看，对于每个代大小以及GC频繁，通过jmap将内存dump,再借助工具HeapAnalyzer来分析哪地方占用的内存较高以及是否有内存泄漏可能。简单点可以使用APM工具，比如阿里云ARMS，下同。
2.4.7 线程池
如果线程不够用，可以通过参数调整，增加线程；对于线程池中的线程设置比较大的情况，还是不够用可能的原因是：某个线程被阻塞来不及释放，可能在等锁、方法耗时较长、数据库等待时间很长等原因导致，需要进一步分析才能定位。
2.4.8 JDBC连接池
连接池不够用的情况下，可以通过参数进行调整增加；但是对于数据库本身处理很慢的情况下，调整没有多大的效果，需要查看数据库方面以及因代码导致连接未释放的原因。
2.4.9 SQL
SQL效率低下也是导致性能差的一个非常重要的原因，可以通过查看执行计划看SQL慢在哪里，一般情况，SQL效率低下原因主要有：jvm调优参数

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。