性能测试 PTS 销售指南| 学习笔记

开发者学堂课程【云原生中间件产品销售红宝书：性能测试 PTS 销售指南】学习笔记，与课程紧密联系，让用户快速学习知识。

课程地址：https://developer.aliyun.com/learning/course/629/detail/9888

性能测试 PTS 销售指南

内容介绍：

一、双11来临，如何保障业务系统稳定性?

二、PTS 产品简介

 

一、双11来临，如何保障业务系统稳定性?

1、大促像阿里巴巴，做双十一大促已经是第十一年，从刚开始会经过很痛苦的血泪史，比如刚开始会胸有成竹的准备一场活动，像秒杀或者抢购之类的活动，会带来多少营收，用户量会增加多少，但是在运行时往往会发现，比较多的情况是会提示活动太火爆，过一会再来试试，甚至整个页面都打不开，本来是准备一场希望用户能够赞美的产品或者玩的很嗨的一次活动到，最后会迎来比较多的投诉。

2、事例，参加秒杀活动最后无法付款，举报是因为做虚假活动，账号有问题，还要求赔付金额，从过程上来看大促期间悲痛的历史都是因为应对的准备不足，刚开始把整个过程都想的理想化，最终的结果造成经济上的损失，前期的运营投入已经做很多，但是后面并没有完美的运营的效果，品牌的形象会受到损失，被认为品牌的形象都是骗人，秒杀活动也是骗人的，直接的结果造成客户的流失甚至是有客户的投诉。

3、因为不好的过程或者血泪史总结为什么大促会失败？

大促失败原因：

（1）缺乏意识

只知道准备资源，不知道要准确的准备资源，没有压测的意识。

（2）没有按照流程准备

简单的进行了单次测试，没有系统化的准备、操作、优化、验证。登陆，查看，提交订单，与支付宝支付的环节。

（3）用错工具

自己使用了开源的工具，不能模拟真实的流量来源进行压测。秒杀会有损失的峰值，类似于淘宝双11时峰值就是在前两分钟，一瞬间用户量就会非常的大，希望模拟出真实的流量进行一次压测，和实际场景匹配。

（4）不知道如何定位优化

没有详细的报告，不知道瓶颈点在哪里，没来得及优化。

有了意识，按照流程操作，选对的工具，最后也发现希望有一百万人来访问，只有五十万，不知道原因是什么，没有进行优化是因为没有详细的报告或者没有统计的数据，面对压测结果的场景很茫然，所以基本上大促失败会由这些原因组成。

4、为什么要做性能测试

从技术和品牌或者运营产品的角度一共分成四部分。

（1）品牌

由于对大流量的准备不足,导致给企业带来直接经济损失或者品牌形象受损的事情经常发生。

在产品上市时品牌形象就是打入市场最重要的指标，客户对品牌的第一印象是非常重要的，很难的争取到市场的预算，运营的预算，做一次大的活动，在活动一开场时就崩盘会导致的品牌形象大大的受损。

（2）体验

产品核心功能的体验,特别是日常峰值下的性能表现尤为重要。大量数据表明,每0.1秒的核心体验响应时间延长会导致1%的营收下降。用户体验包含两部分，第一部分是日常的用户体验，第二部分是大促活动的用户体验，类似于在打开网站时首频超过一秒都不能渲染完成，大多数人不会再打开网站，网站的首页三秒之内不能渲染完成，用户90%就不会再来这里，所以用户体验也非常重要。

（3）成本

不同业务模型下容量配比不同,如何基于精准的流量模拟来完成最低成本的容量预估。成本包括人力成本和实际能够承受容量的资金的成本，所以做容量评估或者性能准备时需要最低的人力成本或者最低的资源成本完成。

（4）不确定性

分布式系统复杂度和业务发展的不确定性,导致需要经常性检查系统的瓶颈点。

技术或者业务上的不确定性，现在的系统都是分布式的系统，各种上云或者弹性计算或者混合云，分布式系统的复杂度是非常高的，再加上移动互联网时代，业务发展具有不确定性，比如爆款的活动，子弹短信就是新型的业务，会有突增的不确定性，所以需要经常性的检查系统的瓶颈点在哪里，通过性能测试方式检查哪里有问题，需要如何做。

5、理想大促-活动准备环节

以前做大促时类似滑锁过河，特别的刺激，就是惊险的度过，但是里面的隐患是非常大的，像滑锁一样没有安全感，期望的状态就像港珠澳大桥一样能够顺滑安全非常通畅的度过一次大促。所以在准备大促时理想的大促活动准备环节是，对业务架构或者技术架构进行梳理，比如方在做淘宝大促时涉及到的业务点是什么，业务点涉及到的技术点是什么，都需要进行梳理。第二步梳理完业务之后就要开始做压测的准备，分为环境的准备和数据的准备。第三步准备好数据，梳理好业务之后，真正的开始做压测，平静点的检查，容量的验证甚至是预案的验证。第五步需要根据的压测结果定位的平均点，发现问题做容量的微调或者预值的更新或者配置的更新，甚至是简单的扩容，再次验证，最后在活动时需要正常的活动保障，以及在活动结束之后的总结。所以理想的大促环节应该是有序的，理想状态下有序的完好的进行，才能对大促有好的准备过程。

6、客户案例介绍-某X利(全球直销品牌)

它是经典电商大促的场景，它要在中秋和国庆时做一次电商的大促，8月份时已经做过一次大促，按照传统的有惊有险的方式准备，大促之后发现电商营销失败，很多用户网站打不开，要买的东西买不到，所以他们开始考虑要做性能测试，第一个看重的是来阿里云寻找产品，他们的业务场景经典的，就是官网的电商大促包括秒杀，登录支付，提交订单场景，项目的背景在8月份，中秋是9月份，中间的时间非常少，所以面临着时间很紧迫，系统又很复杂，整个任务会很繁重，因为他们之前有一次失败的经验所以不能再失败，再失败对后面产生影响，用户看中性能测试服务之后开始做事情，对用户最终的收益就是秒杀业务，能够真正提前验证好完成，特殊的是它们对地域或者运营商的来源，客户会有群体的效应，大一点的业务或者业务场景都会有诉求，比如有一部分用户是来自杭州，有一部分用户是来自广东，还有一部分来自移动，有一部分来自联通，会有地域的诉求，他们的业务场景里面，最后它们完整的度过大促，整个业务的营收或者平台的口碑都是非常好的，公司老板很重视。

提升产品的口碑，也在压测的过程中会建议给用户使用其他的阿里云的产品，比如像hahs的限流降级以及dts或者引入咨询服务，因为在时间紧迫时会需要投入咨询人力，操作的方法是在刚开始时进行业务的梳理，根据涉及到的核心业务构造对应的数据，比如登录的用户数据，来源数据，电商里面涉及到的产品分类，产品的数据，实施一轮压测完成之后开始根据出的报告做一次问题的定位并且做优化的改造，再做一轮的验证，在中间的过程中引入新的产品，比如熔断保护，因为在整个压测到后期时，项目背景时间紧，到后期时来不及优化或者无法彻底解决时可以通过熔断保护，保护自己的底层业务，不至于整个系统都会挂掉，还进行dts的引入，多地域部署，实现多活架构做保障。

（1）客户场景

客户类型：中秋、国庆电商大促。

业务场景：8月首次大促,准备不足,线上电商营销失败,中秋大促压力较大、官网电商大促,含秒杀，支付等场景。

项目背景：时间紧迫、系统复杂、任务繁重。

（2）价值

客户收益：真实的模拟秒杀业务、多地域/运营商来源大流量，高真实度的完成性能测试,顺利完成大促，业务营收、平台口碑。

我们的收益：提升产品口碑,现在活动前都会使用压测产品，从PTS带入更多产品使用( AHAS. DTS咨询服务)，现是AHAS的重点标杆客户。

（3）操作方法

压测入场：梳理核心业务、 构造数据、压测实施，问题定位、 优化改造、再次验证。

新产品引入：熔断保护: 保证大部分用户的实时体验;大促目标数据确认：限流保护( AHAS )，DTS 引入，多活架构做保障。

（4）为何能成功?

业务梳理清晰，选择了主流、可靠的压测工具，性能测试服务。

7、大促成功原因

（1）清晰的业务与数据

梳理清楚压测范围，比如淘宝双11时为电商系列会涉及到，像有其他业务的不太跟电商类有关系的就不会涉及，准备好相应的数据，登录的用户数据，商品数据。

（2）最正确的工具

模拟真实的流量来源，模拟真实业务场景，比如的秒杀场景能够损时高并发的访问，操作简便，繁琐的工具会使用户使用心理上排斥，其次操作也会复杂，增加的整个流程的成本，问题定位(全方位的监控)，甚至给出合理的建议，当前系统能够平稳的运行，多大的流量，结论性，产出细致的报告，在线下分析问题点在哪里。

（3)成功的大促准备

准确的预估容量,安全可靠的系统稳定性准备.

8、压测方法对比

（1）业界常见压测方式

开源工具：灵活、再塑性强、协议支持广、自定义方法、并发能力低、代码能力要求高。

开源工具的优势是很灵活，再塑性强，有jar包就能够实现所有的协议的支持，可以自定义方法，灵活的劣势就是并发能力不高，同时代码要求能力会非常高，它有版本的概念，官网发布新版本之后，本地的版本需要跟着迭代的，同时如果想要做高并发就需要自己在上面搭一套控制层，成本就会非常高。

自研平台：高成本、协议适配、人力/资源成本、代码侵入、维护成本高、稳定性较弱。

自研平台基于开源工具做的事情，除了成本高之外还有代码侵入的风险，需要有专门的团队，至少要有专门的人力维持，稳定性差，所以自研平台不推荐。

竞品工具：价格高、售后支持力度不够、操作复杂、流量无法定制。

在国内甚至是国外时会有其他做性能测试的平台，跟竞品相比，竞品上面出现价格高的问题，售后的支持力度不够，页面操作的复杂度高，流量无法定制。

（2）PTS性能压测服务

基于与开源工具资源平台或者竞品的对比，pts的性能压测服务的优点是高并发的能力，阿里巴巴自己在做淘宝双11压测，用的压测服务是完全一模一样的，由内部做的压测的平台对外商业化的输出，所以底层完全一样，理解成淘宝双11用什么做压测，外面的客户也可以用什么做压测，工具一样。

高并发能力，目前用到最大高并发的用户已经达到一百万的并发，对应的rps有八百万。

真实流量(支持定制化流量)有从cdn的流量同时还可以定制化流量，比如整个100%的流量其中有50%自于广东的移动，20%自于杭州电信，支持定制化。

全方位定位能力，压测之后的报告日志定位。

JMeter的支持，对使用开源工具用的多的同学，支持开源，很多做性能测试的同学，对开源的工具非常熟悉，他不想再切到你的平台，他想要沿用原来的一套，但是又想要高并发真实的能力以及定位的能力，所以可以通过pds直接用，JMeter类型的压测即可。

请求采样日志/错误日志，无论是竞品还是开源工具都没有。

VPC网络压测，有主题系列文章讲阿里巴巴是如何做准备双11，可以在公众号上查看，在做全链路压测之前有部分业务想要自己做单链路的压测，在内部的压测，比如rpc、mqtt、double都是需要在vpc网络内部进行，pts的压测也支持vpc网络配置，和公网一模一样，只要切换网络来源即可。

自动得出系统能力结论，在容量评估的模式下会自动压测得出结论，当前的业务系统最佳能够跑的压力能力是多少，最佳是指基本上不会报错，rt会非常正常，正常是由业务决定的，只要告诉R T不能超过100毫秒，错误率不得低于90%，会自动压测得出最佳的压力点是多少，就是系统下跑这么多能量，压力不会出任何问题，会告诉当前能够容忍小级别的错误，也就是限流的阈值是多少，最后会告诉压力达到破坏点，系统会出现问题，所以初次做性能压测或者无法判断系统是多少时非常有帮助。

 

二、PTS 产品简介

可以模拟各种客户端，各种浏览器，各种移动端，从全世界各地发起流量，压测对象可以是公有云，专有云，自建idc以及vpc网络就是阿里云上面的内部网络。

1、非阿里云客户能用吗?

可以,无论客户是公有云/专有云/混合云/自建IDC,无论什么云厂商

只要在公网可访问就能通过PTS来压测。阿里云上的客户有另外的好处就是可以做vpc网络的压测。

2、使用上需要什么门槛吗?

不需要专业测试背景,只需要懂一点http协议即可进行压测场景的设

置。甚至业务请求可以通过云端录制器来录制抓取。

pts是纯saas工具，开箱即用就是打开页面在页面上配置甚至通过的云端录制器都不需要知道的登录接口详细的名字是什么，详细的参数是什么，提交订单的时候，订单名字是大写还是小写都没关系，可以通过云端录制的模式帮快速的录到接口，只要后期更改要压测的数据即可。

3、压测之后的问题定位

pts提供丰富的报告，针对于阿里云和非阿里云用户稍微有一点不一样，监控是分层的，会有客户端的监控，客户端的监控就是用户层面的监控，基础性能就是系统的基础负载能力，能够看到应用级别的监控，客户级别的监控就是常见的请求数，成功率，响应时间是多少，pts自带，无论是不是在阿里云上都会有能力，总结本次压测系统能力，在某个压测模式下会告诉当前系统能够承载的最佳压力值，限流的阈值是多少，以及达到多少量级时系统有问题，基础性能包括基础负载，像cpu或者网络或者内存利用率，slb的带宽连接数，使用率，在阿里云上的用户都可以看到云监控的数据，会直接拿云监控的数据看，不在阿里云上的用户会提供客户端部署采集，同时会上线功能根据阿里云的用户把整个部署的结构，比如有哪些ecs挂载在哪些slb下面，它们的性能情况是什么样子，压测出现问题是具体哪个ecs或者slb有问题，功能预计11月中旬会上线。有客户端的监控，有底层的监控，中间就是应用级别的监控，客户端有rt有异常，负载高，具体是因为什么引起，需要看业务的问题定位，已经集成arms的业务实施监控，可以做链路的分析和性能的定位所以pds上面的压测是提供了比较全面的端到端的监控以及总结性的东西。

4、典型使用压测的业务场景

（1）新系统上线

新系统上线,准确探知站点能力,防止一上线就被用户流量打垮。

（2）峰值业务稳定性

类似阿里双11的峰值业务稳定性考验，保障峰值业务不受损。

（3）站点容量规划

搬站成本优化,对站点进行精细化的容量规划。

（4）性能瓶颈探测

探测站点的性能瓶颈,提升站点的整体服务能力和吞吐量。

5、产品主要客户类型

PTS的30%压测流量中去向非阿里云,业务触及大量友商、IDC。平安，安利等。

6、PTS客户场景类型

 

7、PTS客户行业类型

 

8、客户案例介绍-太平

（1）客户场景

业务场景：开门红活动、新产品发布(太平宝宝)。

项目背景：影响品牌和业务体验、业务接口复杂、业务数据安全性第一。

（2）价值

客户收益：托管式压测服务 (专家服务) , 投入少、活动和产品发布顺利进行，帮它用pds进行压测给出相应的优化建议。

我们的收益：

大场景客户对产品的验收能力、 产品信任度高，从PTS带入更多产品使用( AHAS、每年扩容服务)，专家服务的收费形式，每年都持续使用PTS进行压测。

（3）打法策略

压测入场：梳理核心业务、构造数据、压测实时，问题定位、优化改造、再次验证

新产品引入：熔断保护:保证大部分用户的实时体验;大促目标数据确认:限流保护( AHAS )，按照终态压测结果+预留buffer形式，进行

扩容。

9、PTS客户场景销售切入点

（1）迁移上云：上云迁移，需要检测新系统性能。

（2）新业务上线：如电商系统，秒杀模块新上线新上。

（3）验收项目：作为第三方测试下交付系统是否验收达标。

（4）成本控制：通过压测检查到短板，把相应富裕的资源释放或者补给短板想节省机器成本。

（5）扩容：扩容后需要检验下资源时候达到预期，是否浪费成本。

（6）开源方案替代：JMeter或者破解版LoadRunner。

（7）友商竞品：云智慧/OneAPM/腾讯压测，PTS更有价格优势，且简单易用流量更广。

10、PTS的计费方式

（1）PTS采用预付费购买资源包的形式收费。解决方案需另外按照人天计算。

（2）计费单位是VUM。VUM=VU (压测任务中并发用户数) *M (压测场景执行时长,按分钟粒度,不满一分钟按一分钟计算) ,举例: 4并发用户运行2分钟即8VUM，8并发用户运行1分钟也是8VUM。

举例，对应成移动的加油包，假设买个vum是一百万的资源包，它类似于移动是40G的流量包，资源包会有能力的上限vu就是能模拟多少个并发用户，最大的带宽是100兆，剩下的就是时间，100兆跑二十分钟，相当于是两个g再乘以60就会有时间的概念，vum是能力上限乘以运行的时间，能力乘以运行的时间就是这次要扣掉的量，8vum可以是四个并发用户跑两分钟或者八个并发用户跑一分钟，单位一样。