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

新的测试报告，做性能前，最需要确认好测试环境，有的时候客户经理不太明白，性能测试是怎么回事，问测试要公网的测试报告，尤其是后台的性能测试，我们只能保证其内容效率，公网测试性能相当不严谨，难道移动联通哪天断网了也是我们得事情喽？，所以我认为所有的性能均应该在内网环境下进行，性能而是一个是验证其服务器峰值，一个是验证其服务器最优值的稳定情况。

报告如下：

 此次测试的为坐标偏转接口，验证了其峰值查看现存服务器的支撑情况，对运维提出相对意见

 

坐标偏转性能

测试报告

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

生效日期	2016-1-20	版 本 号		V1.1
版本状态	□草案    □定稿    ■发布版    □修订稿
编 制 人			编制日期	2016-1-20
审 核 人			审核日期
批 准 人			批准日期

 

 

 

文档履历

版本	修订日期	修订章节	主要修正	修订人	审核人/ 批准人
V1.0	2015-10-09	全部	创建坐标偏转服务性能测试报告v1.0
V1.0	2016-1-20	全部	创建坐标偏转服务性能测试报告v1.1

 

 

 

 

 

 

1.概述

1.1目的

对阿里云服务器-坐标偏转服务进行性能测试，评估坐标偏转服务的性能状况。

1.开发正确、有效的性能测试脚本，测试坐标偏转接口，模拟大量请求，作为此次测试有效实施的基础；

2.通过性能测试，评估当前云服务器在生产环境下TPS最大峰值，评估最优值，评估平均请求时间；

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

2.测试环境

2.1压测模型

测试过程中对应用服务器进行监控，观察压力情况下对响应时间的影响。

2.2测试环境

主机/ip环境	硬件配置	操作系统参数	测试环境
坐标偏转应用服务器 140.205.177.87 （VIP）	Inter Xeon E5-2430 CPU 2.20GHz（4核）*2(台) 内存:Total System Memory: 16G VM 硬盘:总大小500(GB)	Enterprise Linux Server release	ECS内网
施压机 100.69.209.55	8核一台 内存:16G 硬盘:总大小500(GB)	Windows 7	ECS内网

 

 

 

 

3.测试方法

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

3.1压测模型定义：

本次压力测试主要选择针对偏转服务接口，没有涉及到其他在线服务调用，拟定压测接口为ws/mapapi/coordinate/convert。

url如下：http://110.215.177.87/ws/123?coordinate=MTE123123NywzOS45OTE3Njk=&deviceid=test_forTM&channel=123&sign=A9FDD2512C872302ED863FF99A7435EE（内网URL估计你们也进不去、、。）

 

3.2需求分析

用户场景设计方案

1. 压测接口的选择，接近用户平时使用原则，选择了单坐标转换接口作测试。
2. 测试峰值使用VUser并发阶段500/450/350/300/200来推算两台云服务器支持的峰值，优值，随着测试时间不同评估考量服务器的性能概况，不同阶段测试内容和分析。
3. 并发数的估算，峰值估算根据500开始进行压力测试，持续1小时，监测服务器QPS,RT,CPU,MEN等参数状态，评估服务器负载能力
4. 并发持续时间，正常值和优值是根据服务器负载能力控制在30分钟
5. 此次性能测试方案是根据坐标偏转服务接口从而评定

方案一，峰值测试：持续并发测试1小时，500/450/个VUser时间持续 60分钟，其中测试过程前后以梯形形式递增/减少100USR并发，观察每个阶段参数请求，找到系统最大负载能力，如下图所示：

 

 

方案二，压力测试：持续并发测试，350/300个VUser时间持续 30分钟，测试直接进行压力，模拟高峰时段测试，观察系统稳定性，如下图所示：

 

 

方案三，低峰测试：假设高峰时段VUser为300，为80%用户请求时段，普通时段为20%用户，既VUser：88，直接进行压测，如图所示：

 

 

3.3测试模型建立

由于涉及用户场景，只考虑客户调用，分析了内网和测试公网的延迟，不考虑稳定性，值考虑并进行评估，如图所示：

内网对应用服务器的延迟：7MS

 

测试外网对应用服务器的延迟：32MS左右

 

4.测试数据记录

4.1分析流程：

结果摘要à并发数分析à响应时间àTPS(每秒事务处理量)à业务成功率

4.2数据记录：

500Vuser：

在2小时内产生共9,398,502点击量，其中1,335,816失败http 502均是由服务器down机引起，并且总体平均请求时间246MS,90%在367MS内，已经超出标准，失败事物达到总事物的七分之一，此并发值已经大大高于服务器的负载能力，且看CPU占用率及LOAD。

平均相应时间：246MS

 

事物统计：错误率14%

 

CPU，MAX最高99%，其中一台测试过程中down掉了：

 

Load也已经超出负载

 

450Vuser：

450Vuesr同500Vuesr，减少了50Vuesr，但同样在测试过程中跑down了服务器，故需要减持100Vuser用户查看峰值和服务器负载能力

 

350Vuesr：

当Vuesr减少到350时，30分钟内请求了4,577,445点击量，服务器运行稳定，且接口平均相应时间再也32MS/29MS，90%请求时间在41MS/37MS，事物错误率忽略不计。

350Vuesr平均请求时间：32MS

 

300Vuesr平均请求时间29MS，

 

事物错误率：0.003‰

 

TPS(每秒事务处理量):2428

 

CPU：69%，没有超过70%占用率，正处于负载

 

 

LOAD：load在350并发用户时，属于最满负载状态，任务与请求达到了约1:1

 

MEN：6%，内存不存在负载情况

 

80VUser:

模拟其余20%用户时间，88Vuser并发的请求时间在21MS，90%在24MS，完全满足＜200MS网络要求

 

 

5.测试结论

5.1测试总结

Vuesr	TPS	响应时间（MS）	CPU	LOAD	错误率	备注
500	1224	246	99%	4.5	14%	Down
450	1450	35MS	99%	4.4	40%	大量失败，服务器DOWN
350/300	2428	44	60%	3.6	0.003‰
88	703	21	24%	1.4	0%

 

1.经过多轮测试发现，每秒2500左右的事物处理量（TPS）是该服务测试服务器处理的峰值

2.接口调用偏转服务，当达到500/450Vuesr时，出现异常较多，约占总数的14-40%，TPS也没有增加。(HTTP 500失败以及所抓到的异常是data source request failure底层服务出现异常)，当前服务器此阶段测试处理能力较差，但底层服务对负载500-400并发时已经较为吃力。

3.再次经过多伦测试，此接口在300-350并发时错误大幅度减少，但350并发用户是TPS已经开始降低，所以在350并发用户可以满足测试标准的小于200MS，且TPS在2500左右。

4.由于是对无流量生产网测试，所以只对用户场景进行模拟，根据二八定律：80%的请求来自高峰时段。20%请求来自普通时代，所以模拟了高峰时段300并发的TPS在2500上下，30分钟产生400万请求量，模拟高峰期1小时，大约产生800W请求量，客户可评测800W请求量是否对应业务场景。

5.此次测试只评估内网基准，测试该服务程序性能，不确保公网性能。

6. 如果需要达到500Vuser，建议优化资源，服务器的核数都是4核，16G内存，对于CPU达到99%的情况，CPU是瓶颈，内存并没有占用太多，所以对于应用来说比较浪费，建议将机子升级为为8核CPU，或扩展机器资源，最好有备份，防止业务场景访问量过大情况。

7.由于不清楚服务器软件基础，且没有对数据库作测试，请相关技术人员评估测试结果对服务器产生的影响，参考测试过程结果产生的有效参数对服务器进行优化。

 

转载于:https://www.cnblogs.com/BUGU/p/5189289.html