[心得]性能测试在内容服务平台上的应用

前言

我们leader在离开前曾强调，性能测试可以在内容服务平台上更深入地做一做。这是唯一的工作上的交代。我们之前做过一部分性能测试，也发挥过一些作用。每次看到，业务研发们手忙脚乱应付线上流量高峰时，我在心里暗想，是该我们做一轮新的性能测试了。之前忙于应付其他工作上的杂事儿，现在可以放开手脚，好好花一番功夫做做性能测试。

现状

我们之前做的性能测试，主要集中在三个指标上：

就是满足99％的服务返回200的情况下，95％的服务请求响应时间在一个基线阈值以下。
qps并发数：计算机网络术语，是指同时访问服务器站点的链接数。
吞吐量throughput：对网络、设备、端口、虚电路或其他设施，单位时间内成功地传送数据的数量（以比特、字节、分组等测量）

主要的缺陷是：
1. 测试类型局限于负载测试
2. 并且性能测试机器数量不足，运行测试时间也不够长，有些内存泄露的缺陷还有待检验。

性能测试理论

性能测试是很重要的，因此必须遵从一些测试方法论。否则浪费时间不说，得出的结论还没有说服力。

以下理论部分整理自性能测试百科词条：http://baike.baidu.com/link?url=UisxpndZfnrp1_gAC_SktFruJj6DSrBDV9XR_C7wWAG_Ac6aPK2oAPlZ8PdWaR_qowVX5MqHAVZS8X535J1IN_0inlc596UWyningR18Oo-Ez0dkBLHp7Yk2cOb7gMU9

定义

性能测试是为描述测试对象与性能相关的特征并对其进行评价，而实施和执行的一类测试，如描述和评价计时配置文件、执行流、响应时间以及操作的可靠性和限制等特征。另一种定义是，性能测试，指通过自动化测试工具模拟多种正常，峰值，以及异常负载等条件来对系统的各项性能指标进行测试。

分类

性能测试按照施压点分为客户端、网络端和服务端。本文仅讨论服务端。

目标

性能测试的目的如下：
1. 评估系统能力，为扩容做一个参考
2. 找到系统瓶颈模块，预防线上服务雪崩
3. 系统调优，找出内存泄露等编程缺陷
4. 验证稳定性和可靠性

种类

性能测试的种类：
1. 负载测试：检验软件系统性能是否达到设计预期，比如并发数，请求出错率等
2. 压力测试，也要检验系统性能，但和负载测试的主要区别在于目的是看硬件系统是否达到了性能预期，因此观察的主要是硬件指标
3. 容量测试：最大承受量：并发数，存储量，吞吐量等

性能测试策略和工具选择受软件架构的制约，我们内容服务平台是一种基于C/S的分布式架构。

步骤

性能测试的步骤如下：
1. 制定目标，分析系统
2. 选择性能测试指标
3. 确定评估标准
4. 准备并验证测试环境可用
5. 准备搜集性能测试的工具和脚本
5. 运行性能测试
6. 整理结果并分析

了解系统组成，包括软件系统架构，硬件配置，系统功能，明确测试范围。
对各种性能测试工具进行评估，确定工具脚本方案。

场景

性能测试场景模型：
1. 线性投射，过去的，扩展的，或预测的输入
2. 分析模型：利用输入量预测响应水平
3. 模仿模型，又称场景回放
4. 基准模型，以前一个版本做基准进行对比

原则

性能测试的原则
1. 条件允许情况下，用另外一种性能测试工具测出的结果交互印证。
2. 查找瓶颈应层层深入：服务器硬件/网络瓶颈（跨网）－》应用中间件（数据库，web服务器参数优化）－》应用业务瓶颈（业务逻辑、算法、数据等）
3. 单参数对照实验调优
4. 每一步调优要记录在案
5. 多思考交流
6. 明确调优结束标准

性能测试具体方法

基准测试

关键是要获得一致，可再现的结果。
最初的一段时间，执行队列的长度为零，然后就开始以稳定的速度增长。这是因为系统中的负载在稳定增长，虽然最初系统有足够的空闲线程去处理增加的负载，最终它还是不能承受，而必须将其排入队列。
当系统达到饱和点，服务器吞吐量保持稳定后，就达到了给定条件下的系统上限。但是，随着服务器负载的继续增长，系统的响应时间也随之延长，虽然吞吐量保持稳定。

为了获得真正可再现的结果，应该将系统置于相同的高负载下。为此，与服务器通信的虚拟用户应该将请求之间的考虑时间设为零。这样服务器会立即超载，并开始构建执行队列。如果请求（虚拟用户）数保持一致，基准测试的结果应该会非常精确，完全可以再现。对于一次给定的测试，应该取响应时间和吞吐量的平均值。精确地获得这些值的唯一方法是一次加载所有的用户，然后在预定的时间段内持续运行。这称为“flat”测试。与此相对应的是“ramp-up”测试。ramp-up测试中的用户是交错上升的（每几秒增加一些新用户）。ramp-up测试不能产生精确和可重现的平均值，这是因为由于用户的增加是每次一部分，系统的负载在不断地变化。
因此，flat运行是获得基准测试数据的理想模式。

性能规划测试

找出在特定环境下，给定应用程序的性能可以达到何种程度。引入随机因子的目的是为了尽量模拟具有真实用户负载的现实世界应用程序。通常，具体的目标是找出系统在特定的服务器响应时间下支持的当前用户的最大数。
有几个问题需要考虑。首先，服务器的用户总数非常大。其次，每个用户的“考虑时间”即请求间时间是多少。这非常重要。再次，在现实世界中，通常难以确定用户的确切考虑时间。还要注意，在现实世界中，用户不会精确地按照间隔时间发出请求。

在设计负载测试时，就要确保请求间的时间为5×（1 +/- 20%）秒。此外，可以利用“调步”的理念向负载场景中引入更多的随机性。它是这样的：在一个虚拟用户完成一整套的请求后，该用户暂停一个设定的时间段，或者一个小的随机时间段（例如，2×（1 +/- 25%）秒），然后再继续执行下一套请求。

如何加载用户以模拟负载状态？最好的方法是模拟高峰时间用户与服务器通信的状况。这种用户负载状态是在一段时间内逐步达到的吗？如果是，应该使用ramp-up类型的测试，每隔几秒增加x个用户。或者，所有用户是在一个非常短的时间内同时与系统通信？如果是这样，就应该使用flat类型的测试，将所有的用户同时加载到服务器。两种不同类型的测试会产生没有可比性的不同测试。

由于我们内容服务的特殊性，一个推送出去将引入大量的瞬时高峰请求，因此flat类型更合适。

渗入测试

渗入测试所需时间较长，它使用固定数目的并发用户测试系统的总体健壮性。这些测试将会通过内存泄漏、增加的垃圾收集（GC)或系统的其他问题，显示因长时间运行而出现的任何性能降低。测试运行的时间越久，您对系统就越了解。运行两次测试是一个好主意——一次使用较低的用户负载（要在系统容量之下，以便不会出现执行队列），一次使用较高的负载（以便出现积极的执行队列）。

峰谷测试

兼有容量规划ramp-up类型测试和渗入测试的特征。其目标是确定从高负载（例如系统高峰时间的负载）恢复、转为几乎空闲、然后再攀升到高负载、再降低的能力。
实现这种测试的最好方法就是，进行一系列的快速ramp-up测试，继之以一段时间的平稳状态（取决于业务需求），然后急剧降低负载，此时可以令系统平息一下，然后再进行快速的ramp-up；反复重复这个过程。这样可以确定以下事项：第二次高峰是否重现第一次的峰值？其后的每次高峰是等于还是大于第一次的峰值？在测试过程中，系统是否显示了内存或GC性能降低的有关迹象？

吞吐量测试

吞吐量的测试方法是：在测试中以一定速率发送一定数量的帧，并计算待测设备传输的帧，如果发送的帧与接收的帧数量相等，那么就将发送速率提高并重新测试；如果接收帧少于发送帧则降低发送速率重新测试，直至得出最终结果。吞吐量测试结果以比特/秒或字节/秒表示。

最后附上支付宝的一个性能测试方案以飨读者：
http://www.infoq.com/cn/articles/performance-test-of-zhifubao