标签：

1.概述

1.1目的

对阿里云迁移-API搜索服务进行性能测试，客观，公正评估API在云服务器上表现得性能状况。

1.开发正确、有效的性能测试脚本，测试新闻类接口，模拟客户方请求，作为此次测试有效实施的基础；

2．通过性能测试，评估当前云服务器测试环境下被测系统的各项性能表现；

3．验证被测系统的事务处理能力是否满足在高峰时期的性能要求，为被测系统提供参考依据。为性能瓶颈进行分析提供参考依据

1.2适用范围

适用于XXXX内部，运维组，项目组，开发组，测试组等

1.3测试阶段

2．测试方法

压测测试采用loadrunner性能测试工具，通过创建压力测试程序，对被测服务器与接口进行自动化压力测试，最后形成压力分析报告

2.1压测模型：

测试过程中对云OS服务器进行监控，观察并发用户时对服务器产生的影响。

2.2压力测试流程：

2.2.1测试环境：

阿里云服务器，SLB：http://141.215.174.22（这个只是模拟错误的SLB）

负载机，（CPU：core I5，内存8G，硬盘500G 7200转） *2台

测试软件：采用Mercury Interactive公司的LoadRunner测试及分析软件作为测试工具。

2.2.2压力模型定义：

本次压力测试主要选择DB类应用接口，没有涉及到其他在线服务调用。拟定压测接口为/audi/ws/news/browse/ url如下：http://141.215.174.22/audi/ws/news/browse/?channel=audi&uuid=22263&output=xml&sign=EFA4C76D7324A52198C6701B165B122C&from=telematics_monitor

2.2.3测试准备与标准

模拟并发1000用户，接口平均请求时间＜500MS，测试请求时间平均4个小时

2.2.4测试执行：

分阶进行压力测试，分析各阶段性能标准，排查相应问题。

2.2.5测试报告输出

测试结果确认有效后，将压测结果形成报告形式发出。

3.测试模型建立

由于不涉及用户场景，只考虑客户调用

每分钟启动100个用户，当达到1000用户时所有用户持续运行3分30

4.性能测试结果分析

4.1分析流程：

结果摘要à并发数分析à响应时间à每秒点击次数à业务成功率à系统资源

4.1.1

结果摘要：

摘要最后一次1000并发用户结果显示

该部分信息包括：测试时间，如下图所示在4小时29分钟，与场景计划中时间基本吻合

我们只是针对静态接口测试，所以每秒点击次数很能直观的看出被测服务器的处理能力，对于吞吐量，单位时间内吞吐量越大，说明服务器的处理能越好，而请求数仅表示客户端向服务器发出的请求数，与吞吐量一般是成正比关系

4．1.2并发用户

由于测试场景时，一台负载机挂了，所以导致在测试30分钟时，变成了500并发用户请求，不过虽然500并发用户请求也能分析服务器的性能标准

1000降到500并发图

800并发设计场景图

4.1.3平均事务响应时间图

800平均相应时间图

1000降到500

看完了“Average Time”，我们再看“90 Percent Time”，这个时间从某种程度来说，更准确衡量了测试过程中各个事务的真实情况，表示90%的事务，服务器的响应都维持在某个值附近，“Average Time”值对于平均事务响应时间变动趋势很大的情况统计就不准确了，比如有三个时间：1秒、5秒、12秒，则平均时间为6秒，而另外一种情况：5秒、6 秒、7秒，平均时间也为6秒，显然第二种比第一种要稳定多了。所以，我们在查看平均事务响应时间的时候，先看整体曲线走势，如果整体趋势比较平滑，没有忽 上忽下的波动情况，取“Average Time”与“90 Percent Time”都可以，如果整体趋势毫无规律，波动非常大，我们就不用“Average Time”而使用“90 Percent Time”可能更真实些。

4.1.4每秒点击次数

“Hits per Second（每秒点击数）”反映了客户端每秒钟向服务器端提交的请求数量，如果客户端发出的请求数量越多，与之相对的“Average Throughput (bytes/second)”也应该越大，并且发出的请求越多会对平均事务响应时间造成影响，所以在测试过程中往往将这三者结合起来分析。图1- 11显示的是“Hits per Second”与“Average Throughput(bytes/second)”的复合图，从图中可以看出，两种图形的曲线都正常并且基本一致，说明服务器能及时的接受客户端的请 求，并能够返回结果。如果“Hits per Second”正常，而“Average Throughput (bytes/second)”不正常，则表示服务器虽然能够接受服务器的请求，但返回结果较慢，可能是程序处理缓慢。如果“Hits per Second”不正常，则说明客户端存在问题，那种问题一般是网络引起的，或者录制的脚本有问题，未能正确的模拟用户的行为。具体问题具体分析，这里仅给 出一些建议。

1000

800

4.1.5业务成功率

800

1000-500

从图中可以看出，所有的Aciton都是绿色的，即表示为Passed，同时除了vuser_init与vuser_end两个事务，其他的事务通过数为 2163，也就表明在30分钟的时间里，共完成了2163次登录考勤业务操作。那么根据这些可以判断本次测试登录业务与考勤业务的成功率是100%，再次 更新测试结果记录表如表2所示

4.1.6系统资源

系统资源图显示了在场景执行过程中被监控的机器系统资源使用情况，一般情况下监控机器的CPU、内存、网络、磁盘等各个方面。本次测试监控的是测试服务器的CPU使用率与内存使用率，以及处理器队列长度

从图中可以看出，CPU使用率、可用物理内存、CPU的队列长度三个指标的曲线逗较为平滑，三者的平均值分别为：53.582%、83.456M、 8.45，而测试服务器总的物理内存为384M，那么内存使用率为（384-83.456）/384=78.26%，根据本次性能测试要求的：CPU使用 率不超过75%，物理内存使用率不超过70%这两点来看，内存的使用率78.26%大于预期的70%，故内存使用率不达标。根据Windwos资源性能指 标的解释，一般情况下，如果“Processor Queue Length（处理器队列长度）”一直超过二，则可能表示处理器堵塞，我们这里监控出来的数值是8.45，而且总体上保持平衡，那么由此推断，测试服务器 的CPU也可能是个瓶颈。同时在测试过程中，场景执行到23分半钟的时候，报出了错误！未找到引用源。的错误，意思是说被监控的服务器当前无法再进行计数器数据的获取了，所以，本次操作系统资源的监控只得到了场景执行的前23分半钟的数据。这样对本次测试结果有一定的影响。

接口性能测试报告样本-含分析内容

标签：

原文地址：http://www.cnblogs.com/BUGU/p/4739343.html