1.背景

在电商及互联网应用时代，用户和流量已成为应用核心竞争力，而随着数字化营销逐渐走进各个领域，线上的秒杀抢购、热点营销等活动也成为企业的必备营销手段，营销带来的大规模流量浪涌对系统来说是个巨大的考验，如何应对用户和流量激增的同时又能保障应用的稳定运行已成为各厂家必须解决的问题。本文将分享如何测试和分析电商类网站的性能瓶颈

2.测试工具选型

本次选择测试工具是华为云的

不采用开源和传统测试工具的原因是：

• 测试周期：压测环境搭建维护复杂，耗费的时间长。
• 使用门槛：Jmeter的学习成本还比较高，当企业出现人员交接的时候需要无法快速找到替代人员。
• 经济成本：专业性能测试工具license采购成本在上百万人民币，而当前华为云性能测试服务还属于免费阶段。
• 弹性按需：根据服务器吞吐量，资源按需扩容，提升资源利用率。

3.了解监控指标

• 并发用户数：在性能测试工具中，并发用户数一般被称为虚拟用户数。
• TPS：每秒成功完成的业务请求数量，是衡量系统性能的一个非常重要的指标，反映系统处理能力，越大越好。
• 不同行业不同业务可接受的TPS也是不一样的。一般互联网电子商务为10000TPS-100000TPS；互联网小型网站50TPS-100TPS；互联网中型网站100TPS-1000TPS。
• 平均响应时间：用户从客户端发起一个请求开始，到客户端接收到从服务器端返回的响应结束，整个过程所耗费的时间，反映系统处理能力。不同行业不同业务可接受的响应时间是不同的。一般情况下，互联网企业在500毫秒以下；金融企业1秒以下为佳；保险企业3秒以下为佳。
• CPU：查看性能测试的过程中CPU资源的占用率，反映系统处理能力以及应用是否稳定。
• I/O： 磁盘的使用情况，度量磁盘读写性能
• 内存：查看内存使用情况

4.前提条件

压测资源需提前准备好：已在云容器引擎服务中创建两台节点，一台2核4G，一台4核8G，这两台节点需要绑定弹性IP，以确保和被压测的应用网络互通。

5.测试目的

本次性能测试主要检测服务端处理能力，通过测试，将达到以下目的：

• 为上线提供指标参考:验证在现有软硬件环境情况下，获取网站性能指标，为系统上线提供指标参考。
• 系统的最大处理能力:在现有的软硬件环境情况下，网站能够支撑的最大处理能力。

6.测试建模

根据顾客的使用电商应用的行为数据分析，为找出现有网站能够支撑的最大处理能力。构建出3种测试模型，分别是单场景基准测试模型、单场景容量测试模型和混合场景容量测试模型。

单场景基准测试模型：测试环境确认之后，对测试模型中涉及的每个功能做基准测试。目的是检查网站本身是否存在功能缺陷。

单场景容量测试模型：针对本次网站性能测试涉及到的网站内容和用户行为轨迹，利用一定量的并发进行测试，获取其性能表现，并验证是否存在并发性问题。混合场景容量测试模型：针对本次平台性能测试涉及到的“内容/行为轨迹/搜索”利用一定量的并发递增进行测试，验证实际可能的高压力场景，较全面的检测系统的性能表现。获取其最大并发数、平均响应时间、系统资源作为衡量指标

单场景基准测试模型：

单场景容量测试模型：

根据现网的监控数据，按照访问量的比例，构建混合场景容量测试模型：

性能标准参考：

7.测试执行

步骤一：创建资源组和测试工程

工程名称：自定义名称，例如Web-test。描述：应用测试Demo。

步骤二：添加事务信息

根据上面的测试模型进行事务的定义，抢购活动的实际情况来看，用户抢购到商品，大概需要经历一下几个阶段：登陆>首页访问 > 搜索 > 商品浏览>加入购物车>下单>付款。期间还有网站对应的活动页面。因此需要定义7个事务：登陆>首页访问 > 搜索 > 商品浏览>加入购物车>下单>付款。

也可以根据需要构建串联场景，验证用户操作链的性能

步骤三：创建测试任务

华为云性能测试服务测试针对测试任务关联多个事务，并为事务分配不同的压力比例，以我当前测试的电商网站为例，单场景测试采用阶梯式压测模型（可以是递增的，也可以无规律的）快速找到压力瓶颈点：

而对于混合测试模型，则在混合测试任务下关联所有事务，并分配不同的比例：

步骤四：查看实时报告

任务启动后查看实时报告

首页访问，100并发用户数持续时间100s，可以看到在100并发时，都是正常返回。

当300并发用户数持续时间100s，已经出现了部分响应超时的现象。说明网站当前还无法支持300个并发访问用户的正常请求。当用户数达到500并发用户数持续时间100s，响应超时的数量高于正常返回的数量，出现异常。

查看对应的资源占用情况，CPU使用率，在性能测试的过程中，CPU的使用率长期超过90%，与业界标准比较，CPU的使用率超过了85%。内存使用率在12%以下，比较稳定。查看后端其中一个数据库节点的资源，资源的使用率较低，相较于前端，可得出性能瓶颈主要在前端的业务代码中。

然后根据定位情况进行优化后反复测试调优就行了。

步骤五：查看离线报告

也可以在无人值守的情况下完成测试后查看离线报告，内容与实时报告一致。

8.结果测试分析

1. 统计维度：报告的TPS，时延、并发等统计维度均为事务，如事务中有请求多个报文，只有在多个请求报文均正常返回会认为成功，时延也是多个请求报文的求和值
2. 响应超时：出现该情况下是在设置的响应超时时间内（默认5S），对应的TCP连接中没有响应数据返回，会将本次事务请求统计为响应超时，出现原因一般是被测服务器繁忙、崩溃、网络带宽被占满等
3. 比对失败：从服务器返回的响应报文不符合预期（针对HTTP/HTTPS默认的预期响应码为200），比如服务器返回404,502等。出现原因一般为高并发情况下被测服务无法正常处理导致的，如果分布式系统中数据库出现瓶颈、后端应用返回错误等
4. 解析失败：响应报文已全部接收完成，但是部分报文丢失导致整个事务响应不完整，这种情况一般需要考虑网络丢包
5. 带宽统计：报告统计的是性能测试服务执行端的业务数据包带宽，上行表示从性能测试服务发出的流量，下线表示接受到的流量。如果是外网压测场景，您需要关注执行机的EIP带宽是否可以满足上行带宽的要求。而下行带宽需要关注单台执行机是否超过1GB
6. TPS与并发用户及时延的关系：TPS是指云性能测试服务在统计周期内每秒从被测服务器获取到的响应事务实时统计，TPS=并发用户/平均响应时延。因此在测试过程中往往会发现并发用户增加了但是TPS没有增加，其原因是由于时延上升了
7. 如何判断被测应用优劣：根据应用本身定义的服务质量定义，最佳状态是没有任何响应失败、比对失败的情况，如果有，需要在服务质量定义范围之内，通常情况下不超过1%，同时响应时延越低越好（2S内体验较好，5S内可以接受，超过5S则需要考虑优化），TP90，TP99指标可以客观反映出90%，99%用户的体验时延