电商推广平台_电商平台测试

                                                                    性能测试报告

1. 概况

A3Mall是一个电商系统平台，是一个面向B2B、B2C的电商平台。

1.1测试背景

A3Mall电商平台通过体验用户反馈业务市场调研及分析，项目部门与业务部门进行交流沟通，确保用户反馈后的有效需求说明书，参照用户需求绘制产品规格书。

1.2测试目的

编写本文档的目的是用于指导A3Mall 1.3系统的性能测试。

    主要从测试环境、测试工具、测试策略、测试具体执行方法、任务与进度表等事先计划和设计。 

1.3测试范围

本次测试主要是对A3Mall电商系统的性能测试。

1.4测试指标

详细文档可参考：

2.测试工具及环境

2.1基本配置

2.2测试工具 

a.压测工具：jmeter、loadrunner、云性能测试服务 CPTS

b.监控工具：Nmon工具

2.3人力安排

2.4项目工作量

3.测试内容

3.1单场景基准测试模型

描述测试场景秒杀

3.2单场景容量测试模型 

描述测试场景秒杀。

3.3混合场景容量测试模型 

描述测试场景秒杀团购。

1. 测试结果与分析

会出现的问题：

1、高并发下大量报错：

出现该类问题，常见的原因有短连接导致的端口被完全占用以及线程池最大线程数配置较小及超时时间较短导致。

优化方案：

短连接问题：修改服务节点的tcp_tw_reuse参数为1，释放TIME_WAIT scoket用于新的连接；

线程池问题：修改服务节点中容器的server.xml文件中的配置参数，参数如下：

最大线程数，服务端可以同时响应处理的最大请求数

maxThreads=”200″

Tomcat的最大连接线程数，即超过设定的阈值，Tomcat会关闭不再需要的socket线程       

maxSpareThreads=”200″               

所有可用线程耗尽时，可放在请求等待队列中的请求数，超过该阈值的请求将不予处理，返回Connection refused错误

acceptCount=”200″                 

等待超时的阈值，单位为毫秒，设置为0时表示永不超时

connectionTimeout=”20000″

2、并发数不断增加，TPS上不去，CPU使用率较低

出现该类问题，常见的原因有：SQL没有创建索引/SQL语句筛选条件不明确、代码中设有同步锁，高并发时出现锁等待；

优化方案：

SQL问题：没有索引就创建索引，SQL语句筛选条件不明确就优化SQL和业务逻辑；

同步锁问题：是否去掉同步锁，有时候不仅仅是技术问题，还涉及到业务逻辑的各种判断，是否去掉同步锁，建议和开发产品同事沟通确认；

4.1单场景容量测试模型

a.测试结果数据

b.测试问题及结果分析

 Cpu占用率100% 差

内存占用率98%  差

事务通过率98% 轻微隐患

吞吐量 26.5 优秀

分析优化：

合并图片或压缩图片

把图片替换成图标

分离冷热数据，对于大内存访问频率低的数据适当分离

提高缓存命中率，命名问题

4.2混合场景压测模型

1. 测试结果数据

1. 测试问题及结果分析

Cpu占用率100% 差

内存占用率70%  良好

事务通过率98% 轻微隐患

吞吐量 13.5 良好

分析优化：

合并图片或压缩图片

把图片替换成图标

分离冷热数据，对于大内存访问频率低的数据适当分离

提高缓存命中率，命名问题

5.测试结论

A3Mall商城性能测试：

Cpu的占用率较高需要去进行增加cpu核数来进行优化

以及 服务器内存数量不足，应扩展服务器内存数量，以便服务器运转收放自如。

修复以上问题，性能数据优化完毕

1    性能测试常用指标概念

1.1    并发用户

概念

并发用户是指同一时刻对系统进行访问的多用户，必须注意是同时且多用户。这些用户的最大特征是和服务器产生了交互，这种交互既可以是单向的传输数据，也可以是双向的传送数据。

并发用户数性能监控的指标

并发用户数是衡量一个系统性能是否达标的一个重要指标。并发用户数越大，则系统承受的压力也就越大。并发用户数是通过业务量大小来进行评估的。

并发用户数公式：TPS*响应时间。并发用户数作为系统能力的参考，但是不能作为指标，因为从公式上可以看出影响并发用户数的有响应时间。

1.2    响应时间

概念

响应时间是指从客户端发一个请求开始计时，到客户端接收到从服务器端返回的响应结果结束所经历的时间。

广义的响应时间(包含服务端处理时间、路径传输时间和终端处理时间的总和)：用户发起交易请求指令(如在界面上点击交易请求按扭开始)，到交易成功(如在界面上看到交易成功的提示信息或直接进入下一步操作)截止所花费的时间。

并发用户数性能监控的指标：

Ø  90%响应时间

把事务每次运行的响应时间从小到大排序，其中90%的请求的响应时间都在这个范围之内

• 平均响应时间

事务运行时间总和除以运行次数，得出来的事务平均响应时间

• 最大响应时间

事务运行中，最大一次运行所需的时间作为该事务的最大响应时间

• 最小响应时间

事务运行中，最小一次运行所需的时间作为该事务的最小响应时间

1.3    TPS

PS每秒钟系统能够处理的交易或事务的数量，它是衡量系统处理能力的重要指标。TPS是重要的性能参数指标。

不同行业不同业务可接受的TPS也是不一样的。一般互联网电子商务为10000TPS-100000TPS；互联网小型网站50TPS-100TPS；互联网中型网站100TPS-1000TPS。

1.4    吞吐量

吞吐量（Throughput）指在一次性能测试过程中网络上传输的数据量的总和。

对于交互式应用来说，吞吐量指标反映的是服务器承受的压力，在容量规划的测试中，吞吐量是一个重点关注的指标，因为它能够说明系统级别的负载能力。

1.5    思考时间

思考时间是指模拟正式用户在实际操作时的停顿间隔时间。

从业务的角度来讲，思考时间指的是用户在进行操作时，每个请求之间的间隔时间。

在测试脚本中，思考时间体现为脚本中两个请求语句之间的间隔时间。

1.6    CPU

查看性能测试的过程中CPU资源的占用率，反映系统处理能力以及应用是否稳定。

1.7    I/O

磁盘的使用情况，度量磁盘读写性能。

1.8    内存

查看内存使用情况。

1.9  调用链

1 调用链跟踪、记录业务的调用过程，可视化地还原业务请求在分布式系统中的执行轨迹和状态，用于性能及故障快速定界。下图所示是在华为云APM拓扑图发现异常后查询调用链追踪异常的过程：

2   性能标准参考

3   测试报告分析

华为云性能测试服务为用户提供专业性能测试报告，包括事务并发、TPS、吞吐量、响应时延、资源使用、调用链跟踪等多维度统计。测试报告有在线和离线两种，用户可以在无人值守的情况下完成测试后查看离线报告，内容与实时报告一致。

下面将华为云性能测试服务作为本次的测试工具，当测试任务结束后提供的报告进行分析。

1. 统计维度：报告的TPS，时延、并发等统计维度均为事务，如事务中有请求多个报文，只有在多个请求报文均正常返回会认为成功，时延也是多个请求报文的求和值

2.  响应超时：出现该情况下是在设置的响应超时时间内（默认5S），对应的TCP连接中没有响应数据返回，会将本次事务请求统计为响应超时。

存在部分响应超时：

a)     服务器繁忙，如某个服务节点CPU利用率高

b)     网络IO超过VM/EIP带宽

c)     等待后端微服务、数据库的超时时间设置过长

运行一段时间后全部响应超时或者检查点校验不通过：

a)     大压力导致系统中某个微服务奔溃

b)     后端数据库无响应

3.   比对失败：从服务器返回的响应报文不符合预期（针对HTTP/HTTPS默认的预期响应码为200），比如服务器返回404,502等。出现原因一般为高并发情况下被测服务无法正常处理导致的，如果分布式系统中数据库出现瓶颈、后端应用返回错误等

4.       解析失败：响应报文已全部接收完成，但是部分报文丢失导致整个事务响应不完整，这种情况一般需要考虑网络丢包

5.       带宽统计：报告统计的是性能测试服务执行端的业务数据包带宽，上行表示从性能测试服务发出的流量，下线表示接受到的流量。如果是外网压测场景，您需要关注执行机的EIP带宽是否可以满足上行带宽的要求。而下行带宽需要关注单台执行机是否超过1GB

6.       TPS与并发用户及时延的关系：TPS是指云性能测试服务在统计周期内每秒从被测服务器获取到的响应事务实时统计，TPS=并发用户/平均响应时延。

TPS未随着并发数增长而上升：

a)  系统性能到达瓶颈，持续并发加压过程中响应时延增加（可观察响应区间统计）

b)  可通过进一步加压是否会出现非正常响应验证

1. 如何判断被测应用优劣：根据应用本身定义的服务质量定义，最佳状态是没有任何响应失败、比对失败的情况，如果有，需要在服务质量定义范围之内，通常情况下不超过1%，同时响应时延越低越好（2S内体验较好，5S内可以接受，超过5S则需要考虑优化），TP90，TP99指标可以客观反映出90%，99%用户的体验时延

TP90响应时延较短，TP99时延高：

a)     系统性能接近瓶颈

b)    可通过进一步加压是否会出现非正常响应验证

4   通用优化建议

1)      扩容，链路中的某一应用可能出现cpu使用率较高或者连接池资源不够用(rpc、jdbc、redis连接池等)但本身对于拿到连接的请求处理又很快，这一类需要横向扩展资源。

2)      应用逻辑优化，比如存在慢sql、 逻辑的不合理如调用db或者redis次数过多、没有做读写分离造成写库压力过大。

3)      超时时间的合理设置，对于应用之间的rpc调用或者应用与其他基础组件之间的调用，均需要设置合理的超时时间，否则过长的等待将造成整个链路的故障。

4)      缓存的应用，请求尽可能从前端返回，而不是每一个都要让后端应用处理后再返回，减轻后端应用及数据库压力，提高系统吞吐能力。

5)      限流，对于超出承载能力的QPS或并发，可以进行拦截并直接返回提示页面。

6)      降级，对于非核心链路上的应用，允许故障关闭而不影响核心链路

7)      扩容和优化也是有限度的，在评估容量内，保障核心交易链路正常是重中之重，对于非核心功能模块考虑降级场景

今天的文章电商推广平台_电商平台测试分享到此就结束了，感谢您的阅读，如果确实帮到您，您可以动动手指转发给其他人。