性能测试（2）--性能测试基本流程

一、性能测试基本流程

1.性能需求分析

• 熟悉被压测系统的基本业务流程，明确此次性能测试要达到的目标，与产品经理、业务人员、架构师、技术经理一起沟通，找到业务需求的性能点
• 熟悉系统的应用架构、技术架构、数据架构、部署架构等，找到与其他系统的交互流程，明确系统部署的硬件配置信息、软件配置信息等，把对性能测试有重要影响的关键点明确列举出来，一般包括：
  • 用户发起请求的顺序，请求之间的相互调用关系
  • 业务数据走向、数据是如何流转的、经过了哪些应用服务、经过了哪些存储服务
  • 评估被压测系统可能存在的重点资源消耗，是I/O消耗型、CPU消耗型，还是内存消耗型，这样在压测执行时可以重点进行监控
  • 关注应用的部署架构
  • 和技术经理一起沟通，明确应用的并发架构是采用多线程处理还是多进程处理，重点需要关注是否会有死锁、数据是否存在不一致、线程同步锁是否合理等
• 明确系统上线后可能会达到的最大并发用户数、用户期望的平均响应时间以及峰值时的业务吞吐量，并将这些信息转化为性能需求指标

2.性能测试计划

• 性能测试计划编写的目的
• 明确各个阶段的具体执行时间点以及对应的负责人
  • 预计由谁何时开始性能需求分析，何时结束性能需求分析
  • 预计由谁何时完成性能测试方案的编写，何时结束性能测试方案的编写
  • 预计由谁何时完成性能测试案例的编写，何时结束性能测试案例的编写
  • 预计由谁何时开始搭建性能测试环境，何时结束性能测试环境的搭建
  • 预计由谁何时开始准备性能测试需要的数据，何时准备完毕
  • 预计由谁何时开始编写性能测试脚本，何时编写完毕。性能测试脚本的编写一般包含如下步骤

    • 按照性能测试场景按照性能测试场景，开始录制性能测试脚本或者直接编写性能测试脚本，此时可能用到的常见性能测试工具包括LodRume. BadBoy. MeternGrinder等
    • 根据准备好的测试数福，对性能测试脚本进行参数化，添加集合点，事务分析点等。
    • 对性能脚本进行试运行调试，确保不出现报错，并且可以覆盖到刚试场景中所有操作。
    • 预计由谁何时开始性能测试的执行，何时完成性能测试的执行，此阶段一般需要完成如下事项:
      • 1、完成每一个性能测试场景和案例的执行，记录相关的性能测试结果，明确性能曲线的变化趋势，获取性能的拐点等
      • 2、根据性能测试的结果，评估性能数据是否可以满足预期，从性能测试结果数据中分析存在的性能问题
      • 3、针对性能问题，进行性能定位和优化，然后进行二次压测，直至性能数据可以满足预期，性能测试问题得到解决

      • 4、完成性能测试分析报告的编写

        • 性能测试风险的分析和控制
          • 性能测试环境因素
          • 性能测试人员因素
          • 性能测试结果无法达到预期

3.编写性能测试方案

• 测试场景的设计
  • 单场景设计:单一业务流程的处理模式设计
  • 混合场景设计: 多个业务流程同时混合处理模式的设计
• 定义事务:测试方案中需要明确定义好压测事务，方便分析响应时间
• 明确监控对象:
  • 针对每个场景，明确可能的性能瓶颈点(比如数据库查询、Web服务器服务转发、应用服务器等)、需要监控的对象，比如TPS、平均响应时间、点击率、并发连接数、CPU、 内存、IO等
• 定义测试策略
  • 明确性能明试的类型:需要进行哪些类型的性能测试，比如负载测试、压力测试，稳定性测试等
  • 明确性能测试场景的执行顺序，一般是先执行单场景， 后执行混合场景测试
  • 如果是进行压力测试，还需要明确加压的方式，比如按照开始前5分钟，20个用户，然后每隔5分钟，增加20个用户来进行加压
• 性能测试工具的选取
  • 性能测试工具有很多， 常见的有LoadRunner. JMeter. nGrinder 等，那么如何来选取合适的性能测试工具呢?
  • 一般性能测试工具都是 基干网络协议开发的，所以我们需要明确待压测系统使用的协议，尽可能和被压测系统的协议保持一致，或者至少要支持被压测系统的协议
  • 理解每种工具实现的原理， 比如哪些工具适用于同步请求的压测， 哪些工具适用于异步请求的压测
  • 压测时明确连接的类型，比如属于长连接还是短连接、一般连接多久能释放
  • 明确性能测试工具并发加压的方式，比如是多线程加压还是多进程加压，一般采用的都是多线程加压
• 明确硬件配置和软件配置
  • 硬件配置一般包括:服务器的CPU配置、内存配置、硬盘存储配置、集群环境下还要包括集群节点的数量配置等
  • 软件配置一般包括
    • 操作系统配置:操作系统的版本以及参数配置需要同线上保持一致
    • 应用版本配置:应用版本要和线上保持一致，特别是中间件、数据库组件等的版本，因为不同版本，其性能可能不一样
    • 参数配置:比如Web中间件服务器的负载均衡、反向代理参数配置、数据库服务器参数配置等
• 网络配置:一般为了排除网络瓶颈，除非有特殊要求外，通常建议在局城网下进行性能测试，并且明确压测服务器的网卡类型以及网络交换机的类型

4.编写性能测试案例

• 预置条件:一般指执行此案例需要满足何种条件，性能测试案例才可以执行，比如性能测试数据需要准备到位，性能测试环境需要启动成功等
• 执行步骤:详细描述素倒执行的步骤，一般需要描述包括测试脚本的承制和编写、脚本的调试，脚本的执行过程
• 性能预期结果:描述性能测试预期需要达到的结果

二、性能分析调优模型

• 性能测试除了为获取性能指标外，更多是为了发现性能瓶颈和性能问题，然后针对性做问题和性能瓶颈进行分析和调优，在当今互联网高速发展的时代，结合传统软件系统模型以及互联网网站特征，可以借助性能调优的模型

三、性能分析调优思想

• 分层分析
  • 分层分析- 般需要对系统的应用架构以及部暑架构的层次非常熟悉，需要熟悉请求的处理链过程。
  • 分层分析 极需要对每-层建立 checklist (检查清单)，然后按照每层的 checklist逐一进行分析
  • 分层分析来排查问题的效率虽然较低，但是往往能发现更多的性能问题
  • 分层分析可以自上而下，也可以自下而上
• 科学论证
  • 发现问题:指通过性能采集和监控，发现了性能瓶颈或者性能问题，比如并发用户数增大后TPS并不增加、每台应用服务器的CPU消耗相差特别大等
  • 问题假设:指根据自己的经验判断，假设是某个因素导致了出现瓶颈和问题
  • 预测:指根据问题假设，预测可能出现的一些现象或者特征
  • 试验论证:根据预测，去检查预期可能出现的现象或者特征
  • 分析:根据获取到的实际现象或者特征进行分析，判断假设是否正确，如果不正确，就重新按照这个流程进行分析论证
• 问题追溯与归纳总结
  • 归纳总结指根据经验的总结，在出现某种性能瓶颈或者性能问题时，根据以往总结的原因进行逐一排查。

四、性能调优技术

1.缓存调优，关键点如下

• 如何让缓存的命中率更高?
• 如何注意防止缓存穿透?
• 如何控制好缓存的失效时间?
• 如何做好缓存的监控分析?
• 如何防止缓存雪崩?
  • 要处理好现存数据全部丢失后，如何能快准把数据重新加载到缓存中
  • 缓存数据的分布式冗余备份，当出现数据丢失时，可以迅速切换使用备份数据

2.同步转异步推送

• 同步转异步主要解决同步请求时的阻塞等待题。一直处于阻塞等待的请求，往往会造成连接不能快速释放，从而导致在高并发处理时连接数不够用，通过队列异步接收请求后，请求处理方再进行分布式的并行处理，从而达到处理能力扩展，并且网络连接也可以快速释放

3.拆分

• 对于高并发的业务请求调用都单独拆分为单个的子系统应用
• 对于并发访问量接近的业务，可以按照产品业务进行拆分，相同的产品业务都归类到一个新的子系统中

4.任务分解与并行计算

• 目的是通过并行计算的方式来增加处理性能

5.索引与分库分表，常见的分库分表方式如下：

• 按照冷热数据分离的方式: 一般将使用频率较高的数据称为热数据、 查询频率较低或者几乎不被查询的数据称之为冷数据，冷热数据分离后，热数据单独存储， 这样数据量就会下降下来，查询的性能自然也就提升了，而且还可以更方便地单独针对热数据进行IO性能调优。
• 按照时间维度的方式:比如可以按照实时数据和历史数据分库分表， 也可以按照年分， 月份等时间区间进行分库分表， 目的是尽可能地减少每个库表中的数据量
• 按照一定的算法计算的方式:此种方式一般适用于数据都是热数据的情况