性能测试简单分析和调优

一， 目的：

通过编写性能测试分析及调优相关流程和方法，帮助研发工程师、性能测试工程师，测试研发工程师或者运维工程师快速开展性能测试，压力测试或稳定性测试，确定和定位产品系统业务链路瓶颈以及进行系统调整或优化。

二，适用对象：

需求提出方。
三，性能分析：

3.1， 前提：

性能分析的前提除了需要丰富性能测试监控（如客户侧监控、可使用granfana进行定位），还需要具备相关技术背景知识（包括但不限于：操作系统、中间件、数据库和开发等）

3.2， 流程：
多数情况下压测流量并没有完全进入到后端（服务端），在网络接入层（云化的架构，例如：SLB/WAF/高防IP，甚至是CDN/全站加速等）可能就会出现由于各种规格（带宽、最大连接数、新建连接数等）限制或者因为压测的某些特征符合CC和DDoS的行为而触发了防护策略导致压测结果达不到预期。
接着看关键指标是否满足目标要求，如果不满足，需要确定是哪个有问题，一般情况下，服务器端问题可能性比较大，也可能是客户端（数据入口）问题（该情况较小）。
对于服务器端问题，需要定位是硬件相关指标，例如CPU，Memory，Disk I/O，Network I/O，如果是某个硬件指标有问题，需要深入的进行分析。
如果硬件指标都没问题，需要查看中间件相关指标，例如：线程池、连接池、GC等，如果是这些指标问题，需要深入的分析。
如果中间件相关指标没问题，需要查看数据库相关指标，例如：慢查SQL、命中率、锁、参数设置。
如果以上指标均正常，应用程序的算法、缓冲、缓存、同步或异步可能有问题，需要具体深入的分析。

3.3， 可提升性能点：

硬件或规格上瓶颈：一般指CPU、内存、磁盘I/O问题，分为服务器硬件瓶颈、网络瓶颈（对局域网可以不考虑）
中间件上性能瓶颈：一般指的是应用服务器、web服务器等应用软件，还包括数据库系统。 例如：中间件weblogic平台上配置的JDBC连接池的参数设置不合理，造成的瓶颈。
应用程序上的性能瓶颈：一般指的是开发人员开发出来的应用程序。 例如，JVM参数不合理，容器配置不合理，慢SQL（可使用granfana定位），数据库设计不合理，程序架构规划不合理，程序本身设计有问题（串行处理、请求的处理线程不够、无缓冲、无缓存、生产者和消费者不协调等），造成业务系统大量用户访问时性能低下而造成的瓶颈。
操作系统上性能瓶颈：一般指windows、UNIX、Linux等操作系统。 例如，在进行性能测试，出现物理内存不足时，虚拟内存设置也不合理，虚拟内存的交换效率就会大大降低，从而导致行为的响应时间大大增加，这时认为操作系统上出现性能瓶颈。
网络设备性能瓶颈：一般指是防火墙、动态负载均衡器、交换机等设备。当前更多的云化服务架构使用的网络接入产品：包括但不限于SLB、WAF、高防IP、CDN、全站加速等等。 例如，在动态负载均衡器上设置了动态分发负载的机制，当发现某个应用服务器上的硬件资源已经到达极限时，动态负载均衡器将后续的交易请求发送到其他负载较轻的应用服务器上。在测试时发现，动态负载均衡器没有起到相应的作用，这时可以认为网络瓶颈。
3.4，方法：

CPU：CPU资源利用率很高时，看CPU消耗User、Sys、Wait哪种状态。

如果CPU User非常高，需要查看消耗在哪个进程，可以用top（linux）命令看出，接着用top –H –p 看哪个线程消耗资源高。如果是Java应用，就可以用jstack看出此线程正在执行的堆栈，看资源消耗在哪个方法上，查看源代码就知道问题所在；如果是c++应用，可以用gprof性能工具进行分析。
如果CPU Sys非常高，可以用strace（linux）看系统调用的资源消耗及时间。
如果CPU Wait非常高，考虑磁盘读写了，可以通过减少日志输出、异步或换速度快的硬盘。
Memory：操作系统为了最大化利用内存，一般都设置大量的cache，因此，内存利用率高达99%并不是问题，内存的问题主要看某个进程占用的内存是否非常大以及是否有大量的swap（虚拟内存交换）。

磁盘I/O：磁盘I/O一个最显著的指标是繁忙率，可以通过减少日志输出、异步或换速度快的硬盘来降低繁忙率。

网络I/O：网络I/O主要考虑传输内容大小，不能超过硬件网络传输的最大值70%，可以通过压缩减少内容大小、在本地设置缓存以及分多次传输等操作提高网络I/O性能。

内核参数：内核参数一般都有默认值，这些内核参数默认值对于一般系统没问题，但是对于压力测试来说，可能运行的参数将会超过内核参数，导致系统出现问题，可以用sysctl来查看及修改。

JVM：JVM主要分析GC/FULL GC是否频繁，以及垃圾回收的时间，可以用jstat命令来查看，对于每个代大小以及GC频繁，通过jmap将内存转储，再借助工具HeapAnalyzer来分析哪地方占用的内存较高以及是否有内存泄漏可能。简单点可以使用APM工具，例如阿里云ARMS。

线程池：如果线程不够用，可以通过参数调整，增加线程；对于线程池中的线程设置比较大的情况，还是不够用可能的原因是：某个线程被阻塞来不及释放，可能在等锁、方法耗时较长、数据库等待时间很长等原因导致，需要进一步分析才能定位。

JDBC连接池：连接池不够用的情况下，可以通过参数进行调整增加；但是对于数据库本身处理很慢的情况下，调整没有多大的效果，需要查看数据库方面以及因代码导致连接未释放的原因。

SQL：SQL效率低下也是导致性能差的一个非常重要的原因，可以通过查看执行计划看SQL慢在哪里，一般情况，SQL效率低下原因主要有：

四，调优：
4.1.1， 确定问题：
应用程序代码：通常情况下，很多程序性能问题都是写出来的，因此对于发现瓶颈模块，应该首先检查代码。
数据库配置：经常引起整个系统运行缓慢，一些大型数据库表结构需要DBA进行参数调整才能投产。
操作系统配置：不合理可能引起业务系统瓶颈。
硬件设置：硬盘速度、内存大小等都容易引起瓶颈原因，因此这些都是分析重点。
网络：网络负载过重导致网络冲突和网络延迟。
4.1.2， 分析问题：
当确定问题后，要明确该问题影响是响应时间吞吐量，还是其他问题？
是多数用户还是少数用户遇到了问题？如果是少数用户，这几个用户与其它用户操作有何不同？
系统资源监控结果是否正常？CPU使用是否到达极限？I/O情况如何？
问题是否集中在某一类模块中？
是客户端还是服务器问题？ 系统硬件配置是否够用？
实际负载是否超过了系统的负载能力？ 是否未对系统进行优化？
通过这些分析及一些与系统相关问题，可以对系统瓶颈有更深入了解，进而分析出真正原因。
4.1.3， 确定调整目标和解决方案：
高系统吞吐量，缩短响应时间，更好地支持研发。
4.1.4， 测试解决方案：
对通过解决方案调优后系统进行基准测试。（基准测试是指通过设计科学测试方法、测试工具和测试系统，实现对一类测试对象某项性能指标进行定量的和可对比测试）。
4.1.5， 分析调优结果：
系统调优是否达到或者超出了预定目标；系统是整体性能得到了改善，还是以系统某部分性能来解决其他问题；调优是否可以结束了。 如果达到了预期目标，调优工作可以先告一段落。
4.2， 调优注意事项
在应用系统设计开发过程中，应始终把性能放在考虑的范围内，将性能测试常态化，日常化的内网的性能测试+定期的真实环境的业务性能测试。
确定清晰明确的性能目标是关键，进而将目标转化为性能测试活动中压测场景并设置好需要的目标量级，然后视情况自动递增/手工调速的组合进行请求流量控制。
必须保证调优后程序功能运行正确。
系统性能更大程度上取决于良好设计，调优技巧只是辅助手段。
调优过程是迭代渐进过程，每次调优结果都要反馈到后续代码开发中。
性能调优不能以牺牲代码可读性和可维护性为代价。