软件性能测试分析与调优实践之路---性能测试和性能分析的基础概念

1.1. 性能测试的基础概念

性能可以理解为一个系统实现其功能的能力，从宏观上可以描述为系统能够稳定运行，高并发访问时系统不会出现宕机，系统处理完成用户请求需要的时间，系统能够同时支撑的并发访问量，系统每秒可以处理完成的事物数等，从微观上可以描述为处理每个事务的资源开销，资源的开销可以包括CPU，磁盘IO，内存，网络传输带宽等，甚至可以体现为服务器链接数，线程数，JVM Heap等的使用情况，也可以表现为内存的分配回收是否及时，缓存规则的命中率等。

性能到底有多重要呢，我们可以举一个网站访问的例子来说明，一个网页的加载速度如果超过4-5秒，可能25%的人会选择放弃。百度的搜索结果响应时间慢0.4秒，一天的搜索量可能会减少千万左右。所以一个系统，一个网站的性能决定了其能够支撑业务的能力。

不同的群体对性能的理解可能会存在很大的差异，普通的用户更加关心响应时间和稳定性。

l 访问页面响应还要让我等多久才能加载出来？

l 为什么有时候会访问失败？为什么会出现502？

架构师和工程师可能更加关心架构设计和代码编写的性能

l 应用架构设计是否合理？

l 技术架构设计是否合理？

l 数据架构设计是否合理？

l 部署架构设计是否合理？

l 代码是否存在性能问题？

l JVM中是否有不合理的内存分配和使用？

l 线程同步和线程锁是否合理？

l 代码的计算算法是否可以进一步优化以减少CPU的消耗时间？

运维工程师可能更加关心系统的监控以及稳定性情况

l 服务器各项资源使用率在正常范围内吗？

l 数据库的链接数在正常范围内吗？

l Sql执行时间正常吗，是否存在慢查询日志？

l 系统能够支撑7*24小时连续不间断的业务访问吗？

l 系统是高可用的吗，服务器节点宕机了会影响用户使用吗？

l 对节点扩容后，可以提高系统的性能吗？

1.1.1 性能测试的分类

性能测试的类型通常包括如下几种：

l 性能测试：寻求系统在正常负载下的各项性能指标，或者通过调整并发用户数，使系统资源的利用率处于正常水平时获取到系统的各项性能指标。

l 负载测试：系统在不同负载下的性能表现，通过该项测试可以寻求到系统在不同负载下的性能变化曲线，从而寻求到性能的拐点。例如负载测试时，在只不断递增并发用户数时，观察各项性能指标的变化规律，找到系统能到达的最大TPS，并且观察此时系统处理的平均响应时间和各项系统资源和硬件资源的消耗情况。

l 压力测试：系统在高负载下的性能表现，该项测试主要为了寻求系统能够承受的最大负载以及此时系统的吞吐率，通过该测试也可以发现系统在超高负载下是否会出现崩溃无法访问以及在系统负载减小后，系统性能能否自动恢复。

l 基准测试：针对待测系统进行版本执行的测试，采集各项性能指标作为后期版本性能的对比。

l 稳定性测试：以正常负载或者略高于正常负载来对系统进行长时间的测试，检测系统是否可以长久稳定运行以及系统的各项性能指标会不会随着时间发生明显变化。

l 扩展性测试：通常用于新上线的系统或者新搭建的系统环境，通过先测试单台服务器的处理能力，然后慢慢增加服务器的数量，测试集群环境下单台服务器的处理能力是否有损耗，集群环境的性能处理能力是否可以呈现稳定增加。

1.1.2 性能测试的场景

性能测试的场景类型通常包含如下几种：

l 业务场景：通常指的是系统的业务处理流程，描述具体的用户行为，通过对用户行为进行分析划分出不同的业务场景，是性能测试时测试场景设计的重要来源。

l 测试场景：测试场景是对业务场景的真实模拟，测试场景的设计应该尽可能贴近真实的业务场景，有时候由于测试条件的限制，可以适当做一些调整和特殊的设置等。

l 单场景：指的是只涉及单个业务流程的测试场景，目的是测试系统的单个业务处理能力是否达到预期，并且得到系统资源利用正常情况下的最大TPS，平均响应时间等性能指标。

l 混合场景：测试场景中涉及到多个业务流程，并且每个业务流程在混合的业务流程中占的比重会不同，该比重一般根据实际的业务流程来设定，尽可能符合实际的业务需要，该测试场景的目的是为了测试系统的混合业务处理能力是否满足预期要求。并且评估到系统的混合业务处理容量最大能达到多少。

1.2. 常见的性能测试指标

衡量一个系统性能的好坏，在性能测试中会使用一些性能指标来进行分析和描述，以下是一些最常用的性能指标。

1.2.1 响应时间

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

下图是一次标准http请求可能经过的处理路径和节点，那么响应的时间的计算方式就是所有路径消耗的时间和每个服务器节点处理时间的累加，通常是网络时间+应用程序的处理时间。

1.2.1 TPS/QPS

事务：自定义的某个操作或者一组操作的集合，例如在一个系统的登录页面，输入用户名和密码，从点击登录按钮开始到登录完成跳转到页面并且新的页面完全加载完成，这一个操作我们就可以定义为一个事务。

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

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

1.2.2 并发用户

在真实的用户操作中，用户的每个相邻操作之间都会有一定的间隔时间（在性能测试中，我们称为用户思考时间），所以并发用户一般有绝对并发和相对并发之分，绝对并发是指某个时间点同时一起向服务器发出请求的并发用户数，相对并发是指一段时间内向服务器发出请求的并发用户总数。单就性能指标而言，系统的并发用户数是指系统可以同时承载的正常使用系统功能的用户的总数量。

针对并发用户我们举例说明，在京东购物网站上购买一件商品的流程包括登录，浏览商品，把商品加入购物车，去购物车结算，确认商品清单，确认收货地址信息，最后提交订单去支付。如果200人同时按照这个流程在购买一件商品，但因为每个人购买商品的步骤有快有慢，所以在同一时间点向服务器发出请求的用户是肯定不会有200个的，会远远小于200个，我们假设为20，那么上面说的200个用户就是相对并发用户数，而20就是绝对的并发用户数。

1.2.3 PV/UV

l PV：Page View的简写，即页面的浏览量或者点击量，用户每次对系统或者网站中任何页面的访问均会被记录一次，用户如果对同一页面进行多方访问，那么访问量会进行累加。PV一般是衡量电子商务网站性能容量的重要指标，PV的统计可以分为全天PV，每个小时的PV以及峰值PV（高峰1小时的PV）。

l UV：Unique Visitor的简写，即指系统的独立访客，访问系统网站的一台电脑客户端会称为一个访客，每天00:00点到次日00:00点内相同的客户端只能被计算一次，同样UV的统计也可以分为全天UV，每个小时的UV以及峰值UV（高峰1小时的UV）。

PV和UV通常是衡量Web网站的两个非常重要的指标，PV/s一般是由TPS通过一定的模型转化为PV，比如如果把每一个完整的页面都定义为一个事务，那么TPS就可以等同于PV/s。PV和UV之间一般存在一个比例，PV/UV可以理解为每个用户平均浏览访问的页面数，这个比值在不同的时间点会所波动，比如双11电商大促时PV/UV的比重会比平时高很多。

1.2.4 点击率

每秒的Hit点击数我们称之为点击率，该性能指标反映了客户端每秒向服务端提交的请求数，通常一个hit对应了一次http请求，在性能测试中，我们一般不发起静态请求（指的是对静态资源的请求，比如js，css图片文件等），所以hit通常是指的动态请求。在性能测试中，我们之所以不发起静态请求是因为静态请求一般是可以走缓存，比如CDN等，很多静态请求一般都不需要经过应用服务器的处理，要么直接走CDN缓存，要么直接请求到Web服务器就被处理完成了。

1.2.5 吞吐量

吞吐量是指系统在单位时间内处理客户端请求的数量，不同的角度，吞吐量的计算方式可以不一样。

l 从业务角度：吞吐量可以用请求数/s，页面数/s等来进行衡量计算。

l 从网络角度：吞吐量可以用字节/s来进行衡量计算。

l 从应用角度：吞吐量指标反映的是服务器承受的压力即系统的负载能力

一个系统的吞吐量一般与一个请求处理对CPU的消耗、带宽的消耗、IO和内存资源的消耗情况等紧密相连。

1.2.6 资源开销

每个请求或者事务对系统资源的消耗，用来衡量请求或者事务对资源的消耗程度，例如对CPU的消耗可以用占用CPU的秒数或者核数来衡量，对内存的消耗可以用内存使用率来衡量，对IO的消耗可以用每秒读写磁盘的字节数来衡量。在性能测试中，资源的开销是一个可以量化的概念，资源的开销情况对性能指标有着重要的影响，我们一般做性能优化时，都是尽可能让每一个请求或者事务对系统资源的消耗减少到最小。

1.3. 性能测试的基本流程

通常情况下，性能测试一般会经历如下阶段，这些阶段可以和很多性能测试工具对应起来，比如分析性能测试结果可以用Loadrunner的ANALYSIS工具来实现。

1.3.1 性能需求分析

l 熟悉被压测系统的基本业务流程，明确此次性能测试要达到的目标，与产品经理、业务人员、架构师、技术经理一起沟通，找到业务需求的性能点。

l 熟悉系统的应用架构、技术架构、数据架构、部署架构等，找到与其他系统的交互流程，明确系统部署的硬件配置信息，软件配置信息，把对性能测试有重要影响的关键点需要明确的列举出来，一般包括如下：

² 用户发起请求的顺序、请求之间的相互调用关系。

² 业务数据流走向、数据是如何流转的、经过了哪些应用服务、经过了哪些存储服务

² 评估被压测系统可能存在的重点资源消耗，是IO消耗型、CPU消耗型还是内存消耗型，这样在压测执行时可以重点进行监控。

² 关注应用的部署架构，如果是集群部署，压测时需要关注应用的负载均衡转发是否均匀，每台应用服务器资源消耗是否大体一致。

² 和技术经理一起沟通，明确应用的并发架构，是采用多线程处理还是多进程处理，重点需要关注是否会死锁、数据不一致，线程同步锁是否合理（锁的粒度一般不宜过大，过大时可能会影响并发线程的处理）等。

l 明确系统上线后可能会达到的最大并发用户数，用户期望的平均响应时间以及峰值时的业务吞吐量，将这些信息转化为性能需求指标。

1.3.2 制定性能测试计划

性能测试计划是性能测试的指导，是一系列测试活动的依据，在制定性能测试计划时需要明确系统的上线时间点、当前项目的进度以及所处的阶段、可以供调配的硬件资源和性能测试人员。一个完整的性能测试计划一般包括如下几个部分：

l 性能测试计划编写的目的：主要是作为整个性能测试过程的指导，让性能测试环境搭建、测试策略的选取、任务与进度事项跟踪、性能测试风险分析等事项有序的进行，同时也需要明确此次性能测试预期需要达到的标准以及性能测试完成退出测试的条件。

l 明确各个阶段的具体执行时间点以及对应的责任人：

预计由谁何时开始性能需求分析，何时结束性能需求分析
预计由谁何时完成性能测试方案的编写，何时结束性能测试方案的编写
预计由谁何时完成性能测试案例的编写，何时结束性能测试案例的编写
预计由谁何时开始搭建性能测试环境，何时结束性能测试环境的搭建
预计由谁何时开始准备性能测试需要的数据，何时准备完毕
预计由谁何时开始编写性能测试脚本，何时编写完毕，性能测试脚本的编写一般包含如下步骤：

² 按照性能测试场景，开始录制性能测试脚本或者直接编写性能测试脚本，此时可能用到的常见性能测试工具包括Loadrunner、BadBoy、Jmeter、nGrinder等。

² 根据准备好的测试数据，对性能测试脚本进行参数化，添加集合点，事务分析点等。

² 对性能脚本进行试运行调试，确保不出现报错，并且可以覆盖到测试场景中所有操作。

预计由谁何时开始性能测试的执行，何时完成性能测试的执行，此阶段一般需要完成如下事项：

² 完成每一个性能测试场景和案例的执行，记录相关的性能测试结果，明确性能曲线的变化趋势，获取性能的拐点等。

² 根据性能测试的结果，评估性能数据是否可以满足预期，从性能测试结果数据中分析存在的性能问题。

² 针对性能问题，进行性能定位和优化，然后进行二次压测，直至性能数据可以满足预期，性能测试问题得到解决。

² 完成性能测试分析报告的编写。

性能测试风险的分析和控制：评估可能存在的风险和不可控的因素以及这些风险和因素对性能测试可能产生的影响，针对这些风险因素需要给出对应的短期和长期的解决方案。性能测试风险一般包括如下：

² 性能测试环境因素：无法预期完成性能测试环境的搭建，这中间的原因可能是硬件引起也可能是软件引起，硬件原因一般可能包括性能压测服务器无法按时到位、服务器硬件配置无法满足预期（一般要求性能压测服务器硬件配置等同于生产环境，服务器的节点数可以少于生产环境，但是需要保证每个应用服务至少部署了两台节点服务器）。软件原因可能包括性能测试环境软件配置无法和生产环境保持一致（一般要求性能压测环境软件配置，比如软件版本、数据库版本、驱动版本等要和生产环境完全保持一致）。

² 性能测试人员因素：性能测试人员无法按时到位参与项目的性能测试，如果出现这样的风险，肯定会导致性能测试无法预期进行，需要立即向项目经理进行汇报，以确保可以协调到合适的人员，因为这是一个非常严重的风险。

² 性能测试结果无法达到预期：即系统的性能无法达到生产预期上线要求或者存在性能问题无法解决，性能调优其实本身就是一个长期不断优化的过程，此时可以看是否通过服务器的横向或者纵向扩容来解决，如果还是无法解决，那么也需要提前上报风险。

1.3.3 编写性能测试方案

在有了性能测试计划后，我们就需要按照性能需求分析的结果来制定性能测试方案，即按照什么样的思路和策略去测试、需要设计哪些测试场景以及测试场景执行的先后顺序、每个测试场景需要重点关注的性能点等，一般包括如下：

测试场景的设计

² 单场景设计

² 混合场景设计

定义事务：测试方案中需要明确定义好压测事务，方便分析响应时间（特别是在混合场景中，事务的定义可以方便分析每一个场景响应时间的消耗）。比如我们对淘宝网购买商品这一场景进行压测，可以把下订单定义为一个事务，把支付也定义为一个事务，在压测结果中，如果响应时间较长时，就可以对每一个事务进行分析，看哪个事务耗时最长。
明确监控对象：针对每个场景，明确可能的性能瓶颈点（比如数据库查询、Web服务器服务转发、应用服务器等）、需要监控的对象，比如TPS、平均响应时间、点击率、并发连接数、CPU、内存、IO等。
定义测试策略：

² 明确性能测试的类型：需要进行哪些类型的性能测试，比如负载测试、压力测试、稳定性测试等。

² 明确性能测试场景的执行顺序，一般是先执行单场景，后执行混合场景测试。

² 如果是进行压力测试，还需要明确加压的方式，比如按照开始前5分钟，20个用户，然后每隔5分钟，增加20个用户来进行加压。

性能测试工具的选取：

² 性能测试工具有很多，常见的性能测试工具有Loadrunner、Jmeter、nGrinder等，那么如何来选取合适的性能测试工具呢

l 一般性能测试工具都是基于网络协议开发的，所以我们需要明确待压测系统使用的协议，尽可能和被压测系统的协议保持一致或者至少要支持被压测系统的协议。

l 理解每种工具实现的原理，比如哪些工具适用于同步请求的压测，哪些工具适用于异步请求的压测。

l 压测时明确连接的类型，比如属于长连接还是短连接、一般连接多久能释放

l 明确性能测试工具并发加压的方式，比如是多线程加压还是多进程加压，一般采用的都是多线程加压。

明确硬件配置和软件配置：

² 硬件配置一般包括：服务器的CPU配置、内存配置、硬盘存储配置、集群环境下还要包括集群节点的数量配置等。

² 软件配置一般包括：

l 操作系统配置

l 应用版本配置：应用版本要和线上保持一致，特别是中间件、数据库组件等的版本，因为不同版本，其性能可能不一样。

l 参数配置：比如web中间件服务器的负载均衡、反向代理参数配置、数据库服务器参数配置等。

² 网络配置：一般为了排除网络瓶颈，除非有特殊要求外，通常建议在局域网下进行性能测试，并且明确压测服务器的网卡类型以及网络交换机的类型，比如属于千兆网卡或者交换机属于百兆交换机还是千兆交换机等，这对我们以后分析性能瓶颈会有很大的帮助，在网络吞吐量较大的待压测系统中，网络有时候也很容易成为一个性能瓶颈。

1.3.4 编写性能测试案例

性能测试案例一般是对性能测试方案中性能压测场景的进一步细化，一般包括如下：

l 预置条件：一般指执行此案例需要满足何种条件，性能测试案例才可以执行。比如性能测试数据需要准备到位、性能测试环境需要启动成功等。

l 执行步骤：详细描述案例执行的步骤，一般需要描述包括测试脚本的录制和编写、脚本的调试、脚本的执行过程（比如如何加压、每个加压的过程持续多久等）、需要观察和记录的性能指标、需要明确性能曲线的走势、需要监控哪些性能指标等。

l 性能预期结果：描述性能测试预期需要达到的结果，比如TPS需要达到多少、平均响应时间需要控制到多少以内、服务器资源的消耗需要控制在多少以内等。