性能测试概念

性能测试入门知识

需求文档中，有一个性能测试需求，你怎么动手？

1. 先怀疑需求的准确性？---开需求评审会

2. 用生产运维的数据--来确定需求的正确性

3. 使用性能概念--确定性能目标

4. 多少在线用户： 在线，但是不请求； 在线，同时有请求

   行业中，一般，用在线用户的 5%-10%作为并发用户数

如何性能测试

• 性能测试概念

  性能： 用不同的角度、来衡量被测对象；给出一些数据，通过这个数据判断性能好坏；一般做后端服务器的性能测试，能普遍提升用户端的性能；用多用户发起请求；通过工具：找出或者获得系统在不同情况下的性能指标；

  找出或获得：

  1.第一次性能测试，得到数据找出性能数据；

  2.非首次测试，获取新的性能测试数据；

  数据：

  • 从不同的角度衡量服务器的性能数据

  • 时间： 平均响应时间数据

  • 同一时间有多少并发用户数请求： 并发用户数数据

  • 服务器每秒能处理多少个事务： TPS数据

  • 服务器在一段时间中，资源使用情况： 资源利用率数据

  • 网络： 吞吐量、吞吐率

  在线用户：1.在线不请求；2.在线同时请求；行业中一般用在线用户的5%-10%作为并发用户数

  二八法则：来源于前端性能测试，调用前端接口请求服务器（一个前端接口可能调用多个后端接口）

   

  负载测试：通过 逐步 增加并发用户量，来找出最大并发用户数区间；

  • 关键词： 逐步增加

  • 所以，在不知道系统的最大支持多少并发用户数，做性能测试时，先做负载测试，找出这个并发用户数；然后，再使用这个最大并发数，来运行性能测试，从而得到性能指标值

  • 一般而言，产品日均访问量大概在百万级别，你们的接口的并发，只有几十到小几百并发用户数

  • 怎么判断最大并发用户数区间

    • 看请求的结果是否有连续性报错出现

    • 平均响应时间，不超过1.5s(行业对接口的默认标准)

    • tps趋势，是否有明显下降

    • 总的请求数 = 并发用户数 * 频率 * 时间

    • 找具体值： 用区间下沿 与 区间上沿 再设计一个负载场景

      • 0-100区间逐步增加10用户数，测出30并发用户数出现拐点；则在用20-30区间步长为1；找出具体值

  压力测试：使用一定量的并发用户数，持续运行一段时间，看服务器稳定性

  • 关键词：持续运行一段时间（一般小时为单位）

  • 一定量并发用户数 产品的最大可接受的并发用户数 20% 80%并发数

  • 稳定性能： 80%最大可接受的并发用户数

  压测：

  企业中说，要你做一个压测

  • 首先，你知道用多少并发用户数吗？ --- 负载测试

  • 然后，最大可以接受的并发用户数做性能测试 --- 性能测试（得到性能指标值）

  • 如果环境有宕机请求，需要你去做一个压测，看看什么问题

    • 压测： 负载测试 + 性能测试 + 压力测试（时间长）

  容量测试：

  • 数据库的数据量级别；表数量在万级、十万级、百万级

    • 索引有关系

    • 性能环境用的数据库表量级别最好与生产数据级别一致或更高

  性能测试前提：

  • 核心功能

  • 架构调整

  • 重大缺陷修复

  • 性能指标量化

    • 产品出现需求，不一定专业

    • 需求重性能指标一定要量化为数字：多少并发数、平均响应时间、错误率、资源利用率、tps达到多少等等

  • 要有单独的性能环境 独立性能测试网络

  性能指标：

  • 并发：讲后端性能测试中，多用户并发。发起方多个用户一起做某件事情；它的源动力：并发用户（人）

  • 并行：同时处理什么事情（服务器）服务器，我们可以同时处理多个接口请求

  • 并发用户： 人 做性能测试的源动力。 后端服务器的性能测试，都是要使用多个并发用户同时发起某个请求

  • 在线用户数： 在线、但是不发起请求； 在线，同时有发起请求。

  • 系统用户数：注册用户和匿名用户（游客）

  • 事务：jmeter中，默认1个接口完成1次请求，当做1个事务。 也可以是多个接口请求，完成一个业务或一个功能。 事务控制器，就可以把多个接口合并成1个接口，统计响应时间

    • 举例： 下单接口进行性能测试（100个并发用户数）

      • 登录接口 + 下单接口 （场景设计：登录接口jmeter用仅执行一次控制器）

  • 响应时间 一个非常重要的指标

    • 从发起请求，经过网络传输到被测服务器，服务器内部处理，经过网络传输给发起方，这个过程所消耗的时间

    • 真实期望响应时间 = 服务器内部处理时间，所以，我们应该无限的减少 网络时间（局域网）

  • TPS 服务器最主要的指标

    • tps 事务每秒 服务器每秒能处理多少事务数

    • qps 每秒查询率 服务器每秒查询多少次；服务器的查询，不局限数据库的查询，也可以是文件查询；

      • 云服务器资源提供商，一般都会有监控平台，看到的数据更多是QPS

    • rps request 每秒请求率 发起方每秒发起多少请求

      • 1rps 可能对应 nQPS；

      • 1次请求 可能请求 1个接口 或者 多个接口；

    • hps hit per second点击率 每秒点击率 发起方， 而且是在前端性能测试中，才有的概念

  • 吞吐量 网络最重要指标

    • 网络中，每秒能传输多少个事务；若没有网络瓶颈--服务器的处理能力，就可以通过网络的事务数展示出来tps数值=吞吐量数值（并发用户数不变、无网络瓶颈）

    有网络瓶颈时候，我们 就不能把 吞吐量数值等于tps数值。

  • 资源利用率

    一般cpu、内存资源利用率 一般要小于80%（整体）

    监控

流程，性能测试流程

• 性能测试准备

  • 需求分析---熟悉业务、了解 软件功能、架构

  • 需求反复讨论，确认需求，明确性能指标（TPS、响应时间、错误率、业务量）

  • 指定性能测试计划、做好工作量评估

    • 工作量，同一个需求，性能测试时间，大概是功能测试2.5倍

  • 自己部署性能测试环境--性能测试独享

  • 确认接口协议（默认http）

• 搭建

  • 服务环境 + 数据库服务环境 + 网络环境 + 监控环境

  • 企业中性能问题，70%问题都与数据库有关；没有索引，数据库查询性能一定差；建索引，并不代表性能一定好

• 编写脚本

  • 工具选择（协议）：jmeter、loadrunner、locust等

  • 写脚本

  • 脚本性能转换

  • 性能场景设计

    • 简单单接口

    • 多接口混合场景

• 性能执行 =====时间是很长

  • 多轮测试，才能找到我们的并发用户数的具体值

  • 性能问题：定位分析

• 分析调优=====时间非常长

  • 分析思路：服务器硬件瓶颈 > 网络瓶颈 > 服务器os瓶颈(参数配置、数据库、web服务器) > 应用瓶颈(sql语句、数据库设计、业务逻辑、算法)

  • 有些我们可以调优，有些不行

• 性能报告与问题跟踪

 

测试步骤：

性能脚本编写：写脚本

性能场景设计：场景设计、环境搭建

搭建监控：

性能分析：性能测试执行、问题分析调优

• 性能测试思维

• 性能测试工具（jmeter、loadrunner、ngrinder、locust、wrk、ab）

  jmeter工具： 使用线程来模拟多用户

  loadrunner工具： 可以使用线程或者进程模拟多用户

  ngrinder工具： 使用进程+线程组合方式类模拟多用户

  loust工具： 使用的是协程来模拟多用户（python开发）

• 网络

网络协议知识

http、soap、jdbc、websocket、dubbo、MQ

网络通信

服务器知识

服务器硬件知识

linux操作系统知识（常见发行版本：Redhat、centos等）

linux软件、应用服务安装与搭建

linux性能分析工具

• 服务器的虚拟化技术

  • 单片机+VMware（虚拟操作系统）

  • 云服务器，就是在硬件上面，使用虚拟化技术，大量虚拟化操作系统，当这个数量级达到一定量

  • 架构虚拟，项目不断拆分（粒度）

  • 不断的拆分，涉及技术升级，使用一些技术

• 服务器：硬件+操作系统+服务。提供能力输出，我们才叫为服务器

数据库知识

• 关系型数据库： MySQL、oracle、postgresql、sqlserver

• 非关系型数据库：redis、MongoDB（bson）

• 时序数据库：根据时间顺序存储 influxdb、Prometheus

  按照时间顺序取出数据，这个数据，就是一条折线，所以，作为监控来使用非常适合

服务应用中间件知识

Tomcat知识

niginx、集群、负载均衡

docker

微服务

性能场景设计

运营数据

场景分析

场景分析

服务器监控知识

服务器监控

监控工具

监控平台

性能结果分析

结果监控

数据分析

问题定位

系统、应用调优

总结：性能测试方法论

• 性能测试的前期准备

  1. 分析业务场景 场景内容有哪些，范围较广，可与开发、产品，讨论确定本次测试的范围

  2. 分析测试策略 得到设计的测试场景有哪些

  3. 分析生产环境 搭建测试环境，建立一个小型相同的测试环境

  4. 选择测试工具 用什么方式来测试性能

• 性能测试的目的

  1. 性能测试则通过提前模拟场景压力，来发现系统中可能的瓶颈，提前修复这些bug，减少服务器宕机的风险。

  2. 性能测试还可以用来评估待测软件在不同负载下的运作状况，可以针对某些数据得到一些决策

• 性能下降曲线分析法

  1. 性能随用户数增长而出现下降趋势的曲线

  2. 性能主要指响应时间

  3. 分为：单用户区域、性能平坦区、压力区域、性能拐点

全链路性能测试

真正的全链路性能测试，一般的公司，没有这个技术，一般落地不了。
真正的全链路： 需要通过浏览回放的平台，把生产的流量-----完全可以真实的模拟出生产业务并发配比。  但是这个平台，暂时，还没有通用的平台，  都是公司自己内部研发，然后使用，个性化的定制，所以需要公司有比较强的测开能力
我们现在的办法，通过生产流量的监控，用jmeter模拟配比
发起性能测试， 现有的工具进行二次开发，与 流量回放平台结合----也需要有比较强的测开能力 
全链路的监控，我们的被测的服务器上的所有服务以及资源，都需要被监控，这些监控要能几乎实时的展示出来
serveragent、nmon、infludb、prometheus监控，可以做到，但是也需要集成，也有一个不足，监控粒度还有不足。这些没法监控到非常细的方法
全链路的分析, 监控的数据 + 服务器的知识 + 分析的经验的积累---也是要有专业人士
​
总的来说，真正的全链路 ，在中大型企业，或者是 测试技术非常牛的公司 才能真正落地。
我们中小微企业，真正要做到全链路
jmeter， 做到时候，先做单接口（把重点、核心接口，排接口优先级）
再做业务的性能测试， 再试多业务的性能测试
监控，也是要逐步这些服务都监控起来
所有的业务都有了性能测试脚本场景、所有的服务都有了监控======已经趋近于全链路
​
全链路：  所有有请求，我们的服务调用路径都被测试到
jmeter做性能测试，我们先做负载测试，找到接口的最大可接受的并发用户数
就可以用这个最大并发用户数，去做性能测试，得的性能指标值，就是我们要的性能指标
可能需要做压力测试-------有不稳定性的情况
但是混合场景，是很有可能要做的，因为，我们生产的环境，肯定是不同数量的人，对不同的业务发起情况，对你们的产品构成。如何知道用多少人、对哪些接口进行测试
这个来源，就要依据，生产的流量监控

• 如何开展

  • 1.分析生产用户流量

  • 2.各个业务接口性能测试脚本开发

  • 3.压测环境要模拟生产

  • 4.压测数据

  • 5.实时全流程监控

• 如何优化

  • 1.单系统优化

  • 2.关键点优化

  • 3.业务流程优化

• 性能场景设计

  • 普通性能场景

    • 线程数： 模拟多用户数， 你想要模拟多少人，填对应

    • 注意： jmeter本身是没有对线程数进行限制的，理论上可以无限人数；但是，我们jmeter放在电脑上，是一个程序，程序就会受电脑资源的限制

    • 启动日志：HEAP="-Xms1g -Xmx1g -XX:MaxMetaspaceSize=256m" java的堆栈配置信息；jmeter的默认启动占用内存是1g

    • 默认情况下，我们jmeter大概能产生 1500-200左右的并发用户数（http协议），在2000以上的并发用户数时，你的电脑默认可能产生不了。

性能场景设计

普通性能场景、负载测试性能场景、压力测试性能场景、面向目标、混合场景、时间规律性能场景

问： 性能测试概念时候，我说性能测试中，应该先进行什么性能测试，然后再做什么，再做什么？
 
**先做负载测试**   --------找出最大可接受的并发用户数
 
然后做性能测试  ------用这个最大可接受的并发用户数来进行性能测试，得到性能指标值，然后，通过这个指标值，来判断，是否符合我们的性能测试预期，如果符合，那么，我们可以直接写测试报告，如果不符合，进行性能问题定位、分析与调优。
 
然后如果有服务器稳定性能问题---做压力测试