软件性能测试、分析与调优实践之路_读书笔记(一)

简介 ： 

     开始在CSDN记录自己性能测试方面的学习笔记和经验。这本性能测试的书已经看完，开始梳理记录里面的重要知识和实践经验，因为自己记忆力不是很好，总会忘记。

    感谢本书作者 ，前人栽树，后人乘凉 ！   

第一章 性能测试、分析与调优基础

1.1性能测试基础

性能的理解 

宏观 ： 系统能够稳定运行，高并发不会出现宕机、系统处理完成用户请求需要的时间，系统能够同时支撑的高并发数，系统每秒可以处理完成的事务数

微观 ：  处理每个事务的资源开销， 资源包括CPU、磁盘I/O、内存、网络传输等，还有服务器的连接数，线程数，JVM Heap，内存的分配和回收是否及时，缓存的命中率；

不同群体对性能理解有很大不同

测试工程师 ： 综合上面的三种不同角色对性能的理解，完整的考虑软件性能；

1.1.1 性能测试的分类

性能测试  负载测试 压力测试 基准测试 稳定性测试  扩展性测试 可靠性测试等，

分类原则是按照测试的目的不同，侧重不同；但是测试方法上基本相同，就是给系统大量的访问压力

1.1.2 性能测试场景

• 业务场景：指系统的业务处理场景，描述具体的用户行为，通过用户行为分析，以划分出不同的业务场景，是性能测试时场景设计的重要来源
• 测试场景：对业务场景的真实模拟，测试场景的设计应该尽可能贴近真实的业务场景，有时候由于测试的条件限制，需要对脚本调整，使得脚本模拟的场景尽可能贴近真实
• 单场景：只涉及单个业务流程的测试场景，目的是测试系统的单个业务处理能力是否达到预期，并且得到系统资源利用率正常情况下的最大TPS、平均响应时间等性能指标
• 混合场景：测试场景中涉及多个业务流程，每个业务流程按照不同的比重混合，尽可能符合实际业务的需要，测试混合业务处理能力能否满足预期要求，并且评估系统的混合业务处理容量最大能达到多少。

1.2 常见性能测试指标

1.2.1 响应时间

请求或某个操作从发出的时间到收到服务器响应的时间的差值就是响应时间，在性能测试中，一般统计的是事务处理的响应时间。

下图是一次HTTP请求可能经过的处理路径和节点

响应时间通常是网络时间+应用程序的处理时间

1.2.2 TPS/QPS

事务是自定义的某个操作或者一组操作的集合

TPS 是Transaction Per Second 的缩写，即系统每秒能够处理的交易和事务的数量，一般统计的是每秒处理事务数

QPS是 Query Per Second的缩写，是对一个特定的查询服务器在规定时间内，处理流量多少的衡量标准

1.2.3 并发用户数

用户思考时间 ： 用户的每个相邻操作之间都会有一定的时间间隔，定义为用户思考时间

绝对并发用户数 ： 某个时间点同时一起向服务器发送请求的并发用户数（服务器并发数）

相对并发用户数 ：某时间段内向服务器发出请求的并发用户总数 （业务并发数）

系统的并发用户数：在系统资源利用率达到允许的最大值时，可以同时承载的、正常使用系统功能的用户总数量

1.2.4 PV/UV

PV ： 页面的浏览量和点击量，用户每次对系统或者网站中的任何页面访问都会被记录一次， 如果用户对同一个页面多次访问，访问量会累加。PV是衡量一个电子商务网站的性能容量的重要指标，PV的统计可以分为全天PV，每小时PV以及PV峰值

UV ：指系统的独立访客，访问系统网站的一个终端被称为一个访客，记录每天的访问量，相同客户端被记录一次，统计系统有多少用户，为UV，可以记录全天，每小时的值

PV和UV是衡量Web网站非常重要的两个指标。

1.2.5 点击率

每秒页面的点击数称为点击率，反映了客户端每秒向服务器提交的请求数。 通常一个hit就是一个动态请求对应一次http请求。

1.2.6 吞吐量

吞吐量是指系统在单位时间内处理客户端请求的数量，可以通过请求数/s, 页面数/s, 字节数/s表现，同时吞吐量与服务器CPU，内存，带宽 IO等资源紧密相连。

1.3 性能测试的目标

• 了解系统的各项性能指标，通过性能压测来了解系统承受多大的并发访问量，系统的平均响应时间是多少，系统的TPS是多少等
• 发现系统中存在的性能问题，常见的性能问题如下 ：

1. 系统中是否存在负载不均的情况，并发情况下每台服务器的并发压力不均匀
2. 系统中是否存在内存泄露，内存泄露是指应用程序代码再每次执行完后，不会主动释放内存资源而导致内存使用一直增加，最终服务器内存会全部耗光，程序运行逐渐变慢，最终因为无法申请到内存而退出运行，内存泄露不易被发现，需要在高并发条件下执行一段时间观察，内存是不是持续增加，才能暴露出来问题；
3. 系统中是否存在连接泄露问题。连接泄露种类非常广泛，可以是数据库连接泄露，HTTP连接泄露或者TCP/UDP连接泄露，系统除了实际情况需要建立长连接外，一般短连接都应该用完就关闭和释放。
4. 系统中是否存在线程安全问题。 线程安全问题就是高并发访问的多线程处理系统中经常出现的问题，如果系统中存在线程安全问题，就会出现多个线程先后更改数据，造成所得到的数据全部都是脏数据，造成严重的系统问题。
5. 系统中是否存在死锁，死锁问题也是多线程系统中经常会遇到的一个经典问题，一般常见的有系统死锁和数据库死锁；
6. 系统中是否存在网络架构或者应用架构扩展性问题，扩展性问题是指在性能指标无法满足的情况下，通过横向或者纵向扩展硬件资源后， 系统性能无法按照一定的线程规律快速递增。
7. 发现系统中的性能瓶颈，优化系统的性能；

• 解决性能压测中存在的问题和性能瓶颈，通过不断的性能调优，使得系统可以满足预期的性能指标。

1.4 性能测试的基本流程

    性能测试的基本流程：

1.4.1 性能需求分析

• 熟悉被压测系统的基本业务流程，明确此次性能测试要达到的目标，需要与产品经理、业务人员、架构师、技术经理一起沟通，找到业务的性能点。
• 熟悉系统的应用架构、技术架构、数据架构、部署架构等，找到被测系统与其他系统的交互流程，明确被测对象的软硬件配置信息，集群部署方案，组网结构等，一般包括如下信息

1. 用户发起请求的顺序，请求之间的相互调用关系，异步响应还是同步响应，交互方式是http还是消息中间件
2. 业务数据流向，数据是如何流转的，经过了那些应用服务器，经过了那些存储服务
3. 评估被测试系统可能存在的重点资源消耗，是I/O 消耗型、CPU消耗型、还是内存消耗型，这样在压测时重点进行监控。
4. 关注部署架构，如果是集群部署，压测时要关注应用的负载分布是否均匀，每台服务器的资源消耗是否大致相同，单台服务器挂了，是否影响业务；
5. 明确应用的并发架构师多线程处理还是多进程处理，重点关注是否会死锁，数据是否存在不一致、线程同步锁是否合理，锁的粒度不易过大，过大会影响线程的并发处理
6. 明确系统上线后可能达到的最大并发用户数，用户期望的平均响应时间以及峰值时的业务吞吐量，并将这些信息转化为性能需求指标

1.4.2 制定性能测试计划

性能测试计划是性能测试活动的依据，在制定测试计划时要明确系统的上线时间点，当前项目的状态，可调配的硬件资源和测试人力资源，

性能测试计划的目的 : 性能测试环境的搭建，测试策略的选取，性能测试的任务与进度跟踪，性能测试的风险分析，性能测试的目标和明确性能测试完成的退出条件

• 性能测试的环境搭建 ： 明确性能测试的服务器类型，服务器内存和CPU，数据库类型和数据库大小，消息中间件，依赖的第三方服务等，整套性能测试环境的准备，明确由谁何时开始搭建测试环境，何时结束搭建测试环境。
• 明确各个阶段具体的执行时间点和对应的责任人

• 性能测试风险和控制： 评估可能存在的风险和不可控因素，以及这些风险和因素对性能测试产生的影响，这对风险提前采取解决措施，规避风险，风险一般包括如下

1. 性能测试环境因素 ： 无法预期完成性能测试环境的搭建， 这中间可能有多种原因，硬件原因一般可能是性能压测服务器无法按时到位，服务器硬件配置无法满足预期，一般要求性能压测服务器硬件配置(使用同一个linux镜像)等同于生产环境，服务器节点数可以少于生产环境，但是需要保证每个测试应用服务至少部署了两台节点服务器，而且组网与生产环境组网相同，软件原因可能包括性能测试测试环境的软件配置无法和生产环境保持一致，一般要求性能测试环境软件配置，数据库配置，中间件配置等要和生产环境保持一致
2. 性能测试人力资源 ：性能测试人员无法按时到位参与项目的性能测试，这样的风险需要及时向项目经理或者人力资源求助协调合适的人员，这是非常重要的风险
3. 性能测试结果无法达到预期 ： 系统的性能无法达到生产预期的上线要求或者存在性能问题无法解决，这种情况大部分都是以业务为主，性能调优是一个长期的过程，此时可能考虑扩充服务器能否解决，如果无法解决需要提前上报风险。

1.4.3 编写性能测试方案

  性能测试方案，按照什么样的思路和策略去测试，需要设计那些测试场景以及测试场景的先后执行顺序，每个测试场景需要关注的性能点等

  明确硬件配置和软件配置

• 硬件配置 ：服务器CPU配置，内存配置，硬盘配置，集群环境，负载均衡配置，Nginx配置，组网配置等
• 操作系统配置 ：操作系统版本，操作系统的参数配置保持与线上系统相同
• 被测应用配置： Java的JVM配置和tomcat的配置，消息中间件配置，数据库配置，业务开关的配置保持与线上环境一致
• 网络带宽配置 ： 一般为了排除网络瓶颈，除非有特殊要求，通常建议在局域网下进行测试，并且明确压测服务器的网卡类型以及网络交换机的类型，在比较大的压力下，网络也很有可能成为性能瓶颈(音视频媒体服务)，

  测试方案设计

• 测试场景设计 ：单一场景设计： 单一业务流程的处理模式设 ； 混合场景设计：多个业务流程同时混合处理模式的设计
• 定义事务 ： 明确定义好压测事务，方便分析响应时间，混合场景可能是多个连续操作，按照事务维度分析响应时间和TPS
• 明确监控对象 ： 针对不同场景和不同事务，分析可能的性能瓶颈点，需要监控的对象，比如TPS，平均响应时间，点击率， 并发连接数，CPU，内存，IO等。
• 定义测试策略 ： 需要那种类型的性能测试，比如负载测试，压力测试，稳定性测试等，压力测试的加压方式等，
• 明确性能测试场景的执行顺序 ： 一般先执行单场景，后执行混合场景测试。

性能测试工具的选取

• 性能测试工具的选取，首先要明确待压测系统使用的协议，一般网络请求是Http协议， 实际工作中有可能不是http协议，比如视频的rtmp协议，hls协议等
• 理解每种工具的实现原理，那些工具适合同步请求压测，那些工具适合用于异步请求压测，明确测试工具的加压方式；

1.4.4  编写性能测试案例

性能测试案例是对性能测试方案的细化，明确准备内容和细化操作方式

• 预置条件 ： 一般指执行此案例需要提前准备的条件，比如用户数据数据准备，性能测试其他必须数据，一般测试场景都需要提前准备数据
• 执行步骤 :  详细的执行步骤，要说明每一个步骤需要执行的操作，脚本如何执行，如何加压，每次加压多少，加压保持多久，需要观察的指标和记录那些性能指标；
• 性能检查点 ： 需要确认业务是否100%完成， 根据实际业务的检查点详细检查是否业务逻辑处理正常。在业务满足的情况下分析，性能要求是否达到了预期的要求

1.4.5 性能调优

 如果测试结果没有达到预期要求，需要分析性能阻塞在哪里，性能优化，再次进行性能测试，最终达到性能要求。