mysql 数据仓库 性能_数据仓库性能测试阶段总结

1.    压测前的准备工作

1).为什么要做性能测试？

性能验证：验证某系统在一定条件具有什么样的能力。

性能规划：如何使系统达到我们要求的性能能力。

应用程序诊断：比如资源分配不合理，内存溢出和内存泄漏等问题，通过功能测试很难发现，但通过性能测试却很容易发现。

性能调优：满足用户需求，进一步进行系统分析找出瓶颈，优化瓶颈，提高系统整体性能。

2).明确的性能需求和测试方案

在进行性能测试的工作时，如果么有一个明确的目标，很容易在压测过程中进行很多无用功，或者起不到很好的压测的作用。

明确的性能需求能够帮助我们进行有目的性的压测场景设计，例如是需要验证工程所能达到的最大性能指标，还是寻找工程资源配置的最优配比等，这些都需要在测试方案中体现出来，对后续的性能压测工作将起到指导性的作用。

在方案设计的过程中经常通过引导式研讨会和头脑风暴方式进行压测场景的设计收集。

3).对压测对象的深入理解

确定压测对象工程，清楚该工程中存在多少输入输出流，各实时流之间的逻辑关系，是否存在去重逻辑，数据输出的过滤条件，以及该工程涉及到的Hbase、mysql等维表，包括维表里面的数据是否满足压测要求。

4).压测数据的准备工作

在压测工作开始之前还需要提前准备好压测数据，根据每个工程预期能力的不同，需要准备的数据量也不同。一般情况下需要准备2000W以上的数据量， 另外还需要考虑对于压测数据有特殊要求的场景，可能需要利用脚本构造压测数据。

附：常见的几种性能压测类型

性能测试: 系统在正常负载的情况的各项性能指标,即通过调整,找到合适的负载,使系统的资源的利用率处于中等的情况下,采集系统的各项指标

负载测试: 系统在不同的负载的情况的性能表现,可以得到系统在不同负载下的性能变 化趋势，寻求性能的拐点。例如其他条件相同，分别测试系统在20,50,100 并发用户下的各项性能  指标，找到其变化的规律，找到系统的能达到的最大 TPS，统计对应的响应时间和资源消耗。

压力测试: 系统在高负载的情况下的性能表现，寻找系统能够承受的最大负载以及对应的系统吞吐率

基准测试： 针对确定的测试系统，代码版本执行的测试，采集性能指标，作为后期的版本对比

稳定性测试: 以正常负载或者稍高于正常负载施加于系统，进行长时间的测试，检测统能够稳定的运行，以及系统的各项性能指标会不会随着时间发生变化。

扩展性测试: 通常用于新系统，新环境的搭建，通过先测试单台服务器的处理能力,然后逐渐增加服务器数量，测试集群环境下的单台服务器的处理能力是否有损耗。

2.    常见性能瓶颈分析及对应场景设计

1).硬件上的性能瓶颈

一般指的是CPU、内存、网络I/O等方面的问题。

分为服务器硬件瓶颈、网络瓶颈、中间件瓶颈(Kafka平台的资源限制)

线性分析法

对于此类性能问题的验证，我们一般是采用的通过有控制性的改变整体资源配置的方法来进行场景设计，这种场景设计的思想是最基础的。

由于一般测试环境的资源配置很难达到真实生产环境那么大的规模，因此需要通过将资源进行线性比例调整的方式来进行压测，根据结果的对比和线性分析，从而估算出真实环境下的压测情况。

举例：

对于dfp_eagle_spes日志(storm程序)的消费能力，通过对服务器，worker和excutor配置的线性增加，来观察消费能力的变化趋势。

2).应用软件上的性能瓶颈

一般指的是应用到一些软件，如Hbase、Mysql，redis等软件性能的限制。

单一变量控制法

对于程序涉及到的一些应用软件，有可能因为本身的吞吐能力问题，而导致整体性能不理想。如Hbase的读写能力和mysql中数据的读写等。

我们需要通过针对该性能点设计单一变量的形式，来验证是否存在性能瓶颈。

举例：

对于某自定义路径树这个工程，存在着其中一个将输入数据中路径树所有节点遍历查询Mysql进行匹配的逻辑，为了验证匹配命中程度对整体性能的影响，我们设计了以下几个场景：

1.资源配比为18C36G，mysql中数据量为50条，与生产者中的数据全匹配且满足起始页面的匹配规则

2.资源配比为18C36G，mysql中数据量为50条，与生产者中的数据全匹配且满足结束页面的匹配规则

3.资源配比为18C36G，mysql中数据量为50条，与生产者中的数据全匹配且满足起始页面和结束页面的匹配规则

4.资源配比为18C36G，mysql中数据量为50条，与生产者中的数据完全未匹配

5.资源配比为18C36G，mysql中数据量为50条，使用真实生产数据(随机匹配)

3).程序本身的性能瓶颈

开发人员开发出来的程序本身，也可能是造成性能的主要瓶颈之一。

例如，程序本身设计有问题，程序中串行、并行的进程线程配置比例不合理，程序代码实现方式冗余等。

深入代码层面的假设分析法

如果以上外部因素所造成的影响都已排除，那么就需要从程序本身进行分析了。

首先需要清楚的了解程序内部的代码处理逻辑，了解一条数据从开始进入程序处理过程，到输出的整个流程，对代码单元中每个关键的处理节点进行假设分析，假设是这个节点的问题，那么我通过改变其进程的方式进行验证。

举例：

对于某Flink程序，其内部处理节点主要有souce、flatmap和sink三个节点组成，其中source为拉取数据节点，map为中间计算节点，sink为输出节点。那么可对其进行如下场景设计来进行验证。

4).一般性能调优的步骤

第一步：确定问题

硬件或平台限制：CPU利用率、内存大小，kafka平台资源限制等都是容易引起瓶颈的原因，因此这些都是分析的重点。

数据库配置：有时候程序中会存在大量的关联逻辑，例如与Hbase ，Mysql等进行关联，在压测过程中都是需要对其吞吐能力进行实时监控的。(比较常见)

应用程序代码：在通常情况下，很多程序的性能问题都是写出来的，因此对于发现瓶颈的模块，如果以上问题经过核实都不是主要原因，那么应该从代码本身进行分析。(比较常见)

网络：网络负载过重导致网络冲突和网络延迟。

第二步：确定调整目标和解决方案

第三步：验证调整之后结果是否达到预期目标