性能测试数据

在软件性能测试过程中，测试数据的准备是一个非常系统化、工作量非常庞大一项工作。如何准备支持不同业务操作、不同测试类型的大量测试数据来满足负载压力测试的需求是性能测试过程中经常面对的一个重要话题。

性能测试需要准备的数据种类

在执行负载压力测试前，一般需要准备三类数据：初始化数据、铺底数据（历史数据）和参数化数据。
初始化数据准备:
业务系统安装部署完成后，并不能马上进行相关业务的负载压力测试，需要对系统进行初始化操作，系统初始化主要对增加系统中的基本角色信息、机构信息、权限信息、业务流程设置等数据，这些数据是业务系统能够开展相关业务的基础。初始化数据是为了识别数据状态并且验证用于测试的测试用例的数据，需要在业务系统搭建完成后按照系统实际运行要求实施导入，供测试中使用。
铺底数据(历史数据):
当业务系统刚刚上线的时候，由于数据库中数据量相对较少，系统整体响应时间很快，用户使用体验较好。但随着业务的持续开展，业务系统数据库中的数据量会成倍的增加，业务系统的相关操作响应时间会因为数据库中业务数据的快速增长等而变的越来越长，用户使用体验会变得很难忍受，因此，在性能测试时，需要加入相当规模的铺底数据，来模拟未来几年业务增长条件下的系统相关操作的性能表现。例如：要测试并发查询业务，那么要求对应的数据库和表中有相当的数据量以及数据的种类应能覆盖全部业务。
参数化数据:
在负载压力测试过程中，为了模拟不同的虚拟用户操作的真实负载情况，同时由于业务系统中大部分业务操作的交易数据不能重复使用，因此，需要为不少用户输入信息准备大量参数化数据，以保证正常实施负载压力测试。参数化测试涉及的范围很多，例如，模拟不同用户登录系统，需要准备大量用户名及相应密码参数数据；模拟纳税人纳税申报，需要准备大量的纳税人识别号、纳税人内码或纳税人系统内部识别号等参数数据，这类数据准备要求符合实际运行要求并且保证数据表之间的关联关系。

性能测试数据主备的常用方法

从前文可知在执行负载压力测试前，我们需要准备三种数据类型，不同数据类型准备方法不同。
初始化数据:
对于业务系统的初始化数据一般采用手工创建和数据导入的方式来完成，其中新建系统或者新旧系统差异较大的这类系统需要手工创建，而具有遗留系统的升级系统很大一部分可以通过数据导入的方式完成数据初始化工作。
铺底数据(历史数据):
铺底数据的准备通常数据翻倍的方式来完成，数据翻倍需要采用找出数据库之间的表结构关系，弄清楚数据库里面主表和附表之间的关系是一对多或多对多，对于一对多关系的要推算一张主表的一条记录大概对应附表的几条数据，并据此把数据翻倍。具体实施数据翻倍时可以利用 CPU 的运算能力高效率地生成的数据，并导入数据库，从而产生出所需的铺底数据。或者通过编写和执行存储过程来完成。准备铺底数据要注意以下几个原则：

• 数据库中的数据量要比生产大上若干倍；
• 数据在准备的时候，要保持原表的约束关系；
• 每张表的数据量要符合真实情况。

参数化数据:
参数化数据准备一般采用从数据库提取现有数据或者人工添加数据的方式来完成。

• 针对并发要求不高，且修改影响不大或只读的场景，可以直接使用数据库现有真实数据。
• 人工添加准备数据，创建的方式有多种，当数据量需求较少的，可以编写小程序或接口自动化场景去自动生成，当数据量需求较大时，我们可以采用数据库后台对可用数据进行数据翻倍的方式来完成（即采用sql方式直接插入数据）。

性能测试监控

在性能测试的整个流程当中，监控起着至关重要的作用。因为在性能测试开始执行之后，需要实时的去观察性能测试的各个指标是否正常，包括应用服务器、数据库、中间件等方面。一旦发现异常情况，及时修正，保证性能测试的顺利进行。而且在监控当中，也可以发现系统的瓶颈，适当制止性能测试的继续运行，保证避免重复的工作。

性能测试监控阶段

性能测试监控应该分为三个阶段去做，它们分别为：
性能测试执行前:
环境搭建的时候，监控确定性能测试环境的纯净性，没有其他资源在使用。CPU、MEM、LOA、I/O的初始值是否正常。
性能测试执行中:
监控内容包括虚拟用户执行情况、场景状态、事务响应时间、服务器资源使用、操作系统和硬件的监控，此外最重要的还有测试机的运行情况，包括CPU、MEM等。是否满足当前性能测试种类的要求，比如性能测试、压力测试、负载测试等。
性能测试执行后:
性能测试执行完成后，需要查看性能测试监控的相关资源指标是否正常释放、合理。

性能测试监控指标

在性能测试的整个流程当中，我们需要关注的常见的监控指标主要分为如下几种：
服务器:
性能测试中常见的服务器监控项为：CPU、Memory、Load、I/O等相关监控项。
数据库:
性能测试中常见的数据库监控项为：缓存命中、索引、单条SQL性能、数据库线程数、数据池连接数。
中间件:
性能测试中常见的中间件监控项为：线程数、连接数、日志。
网络:
性能测试中常见的网络监控项为：吞吐量、吞吐率。
应用:
性能测试中常见的应用监控项为（如java）：JVM内存使用和回收、JAVA内存使用、Full GC频率、JAVA类装入和卸载、日志、线程运行状态（阻塞、等待、正常运行）。
监控工具:
性能测试中常见的监控工具的监控项为：用户执行情况、场景状态、事务响应时间、TPS、Load、CPU分析图表等。
测试机:
性能测试中常见的测试机资源的监控项为：CPU、Memory、网络、日志输出、磁盘空间、负载生成器评估等。

性能测试监控工具介绍

性能测试中监控是必不可少的，针对不容的监控对象，可选择的监控工具非常丰富，我们常用的监控工具有两种，一种是基础资源类监控，一种是链路监控。基础资源类监控一般采用Prometheus来进行监控，链路监控工具一般采用Skywalking 来进行监控。具体使用方法请见相应的使用手册文档。

性能测试分析

性能测试需要结合对应的测试结果和监控信息进行结合分析，需要研发、运维等相关人员协助一起定位到系统性能的瓶颈及对应的原因。

性能测试分析流程

性能测试结果分析流程一般由外到内,有表到里,层层深入。一个应用系统性能开始出现下降的最直接表现就是系统的响应时间变长。于是系统响应时间成为分析性能的起点。任何复杂的系统都可以分为网络和服务器两个部分,虽然性能分析是个常复杂的过程，但一样有规律可循。一般分析流程如下：
判断压测流量是否完全进入了后端:
在网络接入层（云化的架构，例如：SLB/WAF/高防IP，甚至是CDN/全站加速等）可能就会出现由于各种规格（带宽、最大连接数、新建连接数等）限制或者因为压测的某些特征符合CC和DDoS的行为而触发了防护策略导致压测结果达不到预期。
查看关键指标:
看关键指标是否满足要求，如果不满足，需要确定是哪个地方有问题，一般情况下，服务器端问题可能性比较大，也有可能是客户端问题（这种情况非常小）。
服务端分析:
对于服务器端问题，需要定位的是硬件相关指标，例如CPU，Memory，Disk I/O，Network I/O，如果是某个硬件指标有问题，需要深入的进行分析。
中间件分析:
对于中间件问题，需要查看中间件相关指标，例如：线程池、连接池、GC等，如果是这些指标问题，需要深入的分析。
数据库分析:
对于数据库问题，需要查看数据库相关指标，例如：慢查SQL、命中率、锁、参数设置。
应用分析:
对于应用问题，需要查看应用各类、各方法的内存、耗时等进行查看和分析。
性能测试分析流程一般如下图所示：

常见的可能瓶颈点

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

指标分析方法

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工具，例如Skywalking。
线程池:
如果线程不够用，可以通过参数调整，增加线程；对于线程池中的线程设置比较大的情况，还是不够用可能的原因是：某个线程被阻塞来不及释放，可能在等锁、方法耗时较长、数据库等待时间很长等原因导致，需要进一步分析才能定位。
JDBC连接池:
连接池不够用的情况下，可以通过参数进行调整增加；但是对于数据库本身处理很慢的情况下，调整没有多大的效果，需要查看数据库方面以及因代码导致连接未释放的原因。
SQL:
SQL效率低下也是导致性能差的一个非常重要的原因，可以通过查看执行计划看SQL慢在哪里，一般情况，SQL效率低下原因主要有：