[精华] 性能测试学校理论课之一：性能测试入门
1. 性能测试入门
本文主要是跟大家约束和定义一些性能测试常提到的概念、名词。这样大家在讨论性能测试相关问题的时候可以方便有效的沟通。另外，本文还包括了一些实现原理和数值计算的知识。这些理论在今后大家动手执行测试的时候，可以起到指导作用。
这部分内容已经制作成性能测试入门（语音版），授课时间控制在1个小时内，适合对不稳定团队经常性的组织培训。该理论课程配合实验课：一个简单的性能测试工具httpload源代码，一套《测试数据统计表模板》和《沙盒一性能测试报告模板》，一份《沙盒一操作指引》。从理论，到工具模板，到执行实践，有一个很好的结合——这将是性能测试新人培训的全部内容。
1.1. 基本概念和方法
性能测试的概念主要包括两部分：一些测试方法，一些评价性能的指标。测试方法会告诉你用什么样的套路去执行测试；性能指标是告诉你如何用数值来描述你的测试对象的性能。
1.1.1.常用性能指标
【吞吐量】 固定时间间隔内的处理完毕事务个数。通常是1秒内处理完毕的请求个数，单位：事务/秒（tps）。
【平均吞吐量】一段时间内吞吐量的平均值。无法体现吞吐量的瞬间变化。
【峰值吞吐量】一段时间内吞吐量的最大值。是用来评估系统容量的重要指标之一。
【最低吞吐量】一段时间内吞吐量的最小值。如果最小值接近0，说明系统有“卡”的现象。
【70%的吞吐量集中区间】通过统计15%和85%的吞吐量边界值，计算出70%的吞吐量集中区间。区间越集中，吞吐量越稳定。
【响应时间】一次事务的处理时间。通常指从一个请求发出，到服务器进行处理后返回，再到接收完毕应答数据的时间间隔，单位：毫秒。
【平均响应时间】 一段时间内响应时间的平均值。无法体现响应时间的波动情况。
【中间响应时间】一段时间内响应时间的中间值，50%响应时间，有一半的服务器响应时间低于该值而另一半高于该值。
【90%响应时间】一段时间内90%的事务响应时间比此数值要小。反应总体响应速度，和高于该值的10%超时率。是用来评估系统容量的重要指标之一。
【最小响应时间】响应时间的最小值。反映服务最快处理能力。
【最大响应时间】响应时间的最大值。反映服务器最慢处理能力。
【CPU占用率】1-CPU空闲率，表示CPU被使用情况，反映了系统资源利用情况。
1.1.2.常用测试方法
【压力测试】一般提到性能测试，大家最常用到的代名词就是压力测试。实际上，压力测试分成两种：【暴力测试】和【稳定性测试】。
【暴力测试】对系统产生过载的压力，让系统产生一系列致命而无法提供服务的问题。目的是评估这个系统超负载后带来的风险。
【稳定性测试】系统负载未过载情况下的一种压力测试。分两种测试方法，一种是【可靠性测试】，主要是持续一定长的时间提供一定量的负载，暴露系统的缺陷。缺陷暴露的几率与负载的大小成正比。解决系统缺陷后，才能进行【容量测试】。另一种是【稳定性测试】，在稳定的负载下，看系统各个性能指标在一段时间内是否稳定。倘若系统性能不稳定，获得的数值则不适合用来做容量评估。
【基准测试】狭义的性能测试，获得系统在某种特定的条件下（包括特定的负载条件下）的性能指标数据。
【负载测试】通过不断增加对系统的负载，获得系统在不同负载下的性能指标。一般通过并发连接数调节负载。并发连接数取值一般以CPU核数的倍数为佳：1、2、4、8、16、32、64、128。如此取样得到的数据最有参考价值，测试效率也最高。记录每种负载情况下的系统性能，包括：吞吐量（平均值，峰值）、90%响应时间和资源利用率（CPU占用率）。
【容量测试】容量测试主要采用负载测试方法获取数值，继而分析评估系统容量。这个过程包括对系统性能瓶颈的定位，性能调优，使资源利用率最大化，给出系统最优情况下能承载的最佳性能指标。
【并发测试】根据手段可以分为几种。【基准测试】：大量并发连接，看服务处理的响应时间是否正常；【稳定性测试】：被测系统在频繁建立和释放连接情况下系统是否能持续提供服务；【可靠性测试】：并发用户在一定高负载下同时访问临界数据，暴露系统缺陷；【暴力测试】：获取导致系统暴露缺陷的并发连接数。
1.1.3.什么是性能测试？
狭义的性能测试指的是基准测试，广义的性能测试把以上所有与性能相关的测试统称为性能测试。这些既是测试类型也是测试方法，也叫测试策略。一般提到性能测试，大家最常用到的代名词就是压力测试。大家理解的压力其实就是负载，负载就是压力。以上众多的测试方法无外乎是通过某种手段以某种规律改变系统负载然后记录系统的表现。虽然各种方法目的不同，但归结为三个：暴露缺陷，量化基准，调优性能。
1.1.4.后台性能测试实现原理
众多的测试方法无外乎是通过某种手段以某种规律改变系统负载然后记录系统的表现。如何改变被测系统的负载呢？
需要有一个测试工具。这个测试工具唯一的作用就是尽可能快的发出请求包。连续的两次请求操作不能有任何的Think Time，收到被测服务的响应后随即发送下一次请求。这样的结果就是被测服务处理多快，我们的测试工具就能请求多快。
当一个连接建立后，发送出去的一次请求在处理时，这个连接是处于一直等待中。这个时候吞吐量和响应时间是成倒数的。因此，提高测试工具并发连接数可以提高发包速度，继而达到调节被测服务负载的效果。
测试工具实现并发连接后最终效果一般是Ramp-Up的方式，即会有一段很明显的负载上升期，然后逐渐趋于稳定，测试结束时会有一段时间的负载缓慢下降。因为客户端并发请求间一点细小的时序差别，经过服务器处理后，往往会被放大。Flat方式是指同时并发发出请求，这样做的效果会是吞吐量曲线呈现如海浪般的波峰与波谷，然后趋于平缓。要想单台机器单个网卡从真正意义上实现Flat方式的并发访问比较困难，从微观上来看，数据包总是按顺序一个接一个发到远端的。更重要的是，这种Flat的访问方式并不符合一般真实的访问行为，不适合作为容量测试的测试手段，但可以作为可靠性测试暴露系统缺陷的手段，这种方法也叫峰谷测试。
1.2. 数据处理和展示
1.2.1.指标数值的获取和处理
最直接反应被测服务的处理性能，可以通过被测服务在每处理完一次请求后打印一行日志：精确到秒的时间戳|成功失败标志|处理耗时。有了这个原始的数据我们就能计算出每一秒该服务的处理请求数，这就是吞吐量。
有时候因为实现简便，往往在客户端对吞吐量进行统计。然而需要注意的是，在客户端统计的吞吐量是受到客户端自身处理性能以及网络情况等因素影响的，当这些因素影响不大时才可以通过客户端去统计吞吐量数值。
被测服务的处理耗时也属于响应时间。然而有时候我们更关心调用服务用户端的响应时间。这个响应时间包括：客户端发包处理耗时+发包网络传输耗时+被测服务处理时间+回包网络传输耗时+客户端收包处理耗时。这个响应时间就可以在客户端进行搜集和统计。
为了更精确的统计，需要丢弃测试开始ramp-up上升和测试结束吞吐量下降这两部分数据，只取得测试执行比较稳定后发包和回包相当随机时的数值。
在搜集数据时，同样的测试最好执行多次，简单一点就是取平均值，或者取某一次比较有代表性的数据。
当系统连续几次执行结果差别很大时，排除掉不应该引入的网路不稳定等因素，这个系统大多是存在缺陷的，这样的数据对于评估系统容量来说无太大参考价值，可以对其先做稳定性测试，排除掉导致系统不稳定的缺陷。
1.2.2.数值的计算
90%响应时间：假设有100个不同大小的响应时间数值，把它们从小到大排序，那么第90个数值就是90%响应时间。如果把这个值设置为超时阀值，那么超时率就是10%。如果系统允许5%的超时率，那么就最好计算95%响应时间。表示的是有95%的几率在这个时间内返回。
70%的吞吐量集中区间：通过统计15%和85%的吞吐量边界值，计算出70%的吞吐量集中区间。这样计算可以排除掉+-15%的噪点。并且通过观察区间大小（集中度）可以不需要绘制图表也能判断这段时间内的吞吐量是否稳定。
1.2.3.原始数据统计
在还没有得出结论前，我们需要将搜集到的原始数据用表格方式统计出来。
原始数据统计表：
|
BEGIN |
END |
CASE |
TOTAL |
FAIL |
TPS MAX |
TPS MIN |
TPS AVG |
TPS 70% |
RSP MAX |
RSP MIN |
RSP AVG |
RSP 90% |
RemoteCPU |
RemoteIOWait |
LocalCPU |
|
测试开始时间 |
测试结束时间 |
用例名称 |
发包总数 |
失败总数 |
最大吞吐量 |
最小 |
平均 |
通过统计15%和85%的吞吐量边界值，计算出70%的吞吐量集中区间 |
最大响应时间 |
最小 |
平均 |
90% |
被测服务器cpu空闲 |
被测服务器iowait |
测试机器cpu空闲 |
拿到数据后，首先仔细检查是否有明显不正确的数据：有没有失败的情况，数据不全的情况，不符合正常规律的数值变化，测试运行的时间、发包总数是否与预期一致。
1.2.4.常用图表的画法
因为每种测试方法的执行方式不同，测试目的不同，所以测试结果的表述也会不同。我们会采用不同的图表，包含不同的性能指标数值去描述这次性能测试的结果。
好的图表可以清晰简明的表述系统情况。数值得全，以备后续分析，避免无谓的重新测试；但必须去掉任何没有价值的数据，数据太多了问题往往不能被轻易发现。
1.2.4.1. 性能曲线图表
数据表和图的配合可以方便我们执行容量测试时找到评估系统容量的数值。
1.2.4.2. 吞吐量曲线图
可以直观表示在不同负载下，系统处理性能的稳定性。稳定性测试，基准测试常用。
1.2.4.3. 响应时间分布图
可以直观表示响应时间的分布情况，容量测试、基准测试常用。
1.3. 结果分析
1.3.1.容量测试结果分析
如上图所示：
横轴是负载，一般通过调节压测工具的并发数来控制；紫红色线表示90%响应时间。蓝色线表示资源利用率，通常通过观察CPU占用率（1 - CPU idle%）来判断；绿色线表示平均吞吐量，随着负载增加，吞吐量一直增加，高负载区吞吐量持平微升，吞吐量达到饱和点后，负载过载，甚至开始下降。一般资源利用率和平均吞吐量的走势是一致的。
这几条线的运行规律：
单连接下，吞吐量和响应时间乘积是1。被测服务的最快处理时间是固定的，那在低负载时响应时间就是固定值，吞吐量也是固定值。要提高服务器的吞吐量，只能靠提高客户端的并发连接数来实现，并发越多，单位时间发包总数越多。如图所示，低负载区，当被测服务非常空闲的时候，响应时间近似不变，吞吐量的增加与并发数的增加成正比，比值k1近似为1.当被测服务高负载的时候，这个k越来越小，近似为0.从图上来看，就是吞吐量保持水平线的这个区域（高负载区）。这个时候响应时间与单并发的吞吐量乘积还是1.因此响应时间的增长会与客户端的并发连接数增长成正比，斜率为k2近似为1。当系统过饱和后，吞吐量甚至会减少，那么提高并发连接数，会导致响应时间的增长速度K2=1/K1*并发数N的平方，就出现了响应时间激增的情况。
具体推导公式为：
由 K1=吞吐量/N => 吞吐量=K1*N
再由 吞吐量=1/响应时间
=> K1*N=1/响应时间
由 K2=响应时间/N => 响应时间=K2*N，代入以上等式，可得： => K1*N=1/(K2*N) => K1*K2=1/(N*N)
绘制这幅图，主要是为了清晰的帮助我们定量评估系统的容量。低负载区和高负载区的分界点的负载下，系统的峰值吞吐量和90%响应时间就是系统的容量。
1.4. 下集预告
性能测试学校理论课之二：《性能测试基础》（相关KM文章：性能测试结果分析方法）主要通过案例给大家讲述如何对测试结果进行分析。测试数据是否正确？系统瓶颈在哪？系统是否有缺陷？如何下结论？敬请期待。
思考题：为什么吞吐量要用集中区间的算法去计算，而不像90%响应时间那样计算呢？
评论 (16)
-
1楼 2010-10-19 19:20 aimeejin非常精彩的ppt，赞~表情 | 更多功能（内容已超过200字，将会自动使用富文本回复）
-
2楼 2010-10-19 19:25 dylanzhang测试同学必学入门课程表情 | 更多功能（内容已超过200字，将会自动使用富文本回复）
-
3楼 2010-10-20 09:13 baronli正在学习ing，很详尽的备注~多谢jinni表情 | 更多功能（内容已超过200字，将会自动使用富文本回复）
-
4楼 2010-10-27 09:08 kerrydong学习表情 | 更多功能（内容已超过200字，将会自动使用富文本回复）
-
5楼 2010-10-29 16:08 alandai精致！表情 | 更多功能（内容已超过200字，将会自动使用富文本回复）
-
6楼 2010-10-29 16:42 rowanluo嗯，不错，针对server系统的性能测试介绍的很清晰表情 | 更多功能（内容已超过200字，将会自动使用富文本回复）
-
7楼 2010-10-29 17:01 andytao有图有表有数据，收藏了表情 | 更多功能（内容已超过200字，将会自动使用富文本回复）
-
8楼 2011-02-17 09:54 costaxu思路很清晰，学习了。 对服务器开发的同事也很有帮助哈表情 | 更多功能（内容已超过200字，将会自动使用富文本回复）
-
9楼 2011-02-17 11:40 fieldsxie文章写的跟人一样漂亮表情 | 更多功能（内容已超过200字，将会自动使用富文本回复）
-
10楼 2011-02-17 16:41 anniema有些看了还不是很明白。收藏先，以后边实践边学习~表情 | 更多功能（内容已超过200字，将会自动使用富文本回复）
-
11楼 2011-02-24 16:35 wenfeipeng不错，介绍很详细，声音很动听！表情 | 更多功能（内容已超过200字，将会自动使用富文本回复）
-
12楼 2011-03-07 16:42 sli深入浅出，写得很好表情 | 更多功能（内容已超过200字，将会自动使用富文本回复）
-
13楼 2011-11-08 17:06 albertzhangding,学习下表情 | 更多功能（内容已超过200字，将会自动使用富文本回复）
-
14楼 2012-03-22 16:54 alenzhou赞。表情 | 更多功能（内容已超过200字，将会自动使用富文本回复）