双“11”战绩惊人的背后―性能

双十一倒计时还有三天,你做好剁手的准备了吗?淘宝战绩惊人的背后到底会隐藏怎样的手法呢?想知道就跟随我来吧。


2009年11月11日,淘宝首次推出11.11购物狂欢节。该活动最早的出发点只是在“光棍节”当天做一个属于淘宝商城的节日,以提高其知名度。随着“双十一”活动的深入,淘宝商城每年11月11号都战绩惊人。

双“11”战绩惊人的背后―性能_第1张图片
双十一

那么每次双十一,面对如此高的一个负载和并发量,天猫在此阶段都要评估哪些因素?制订哪些基准?如何根据这些事先评估好的指标对硬件和软件进行一个部署和规划的呢?

天猫性能评测负责人,性能技术专家王德山这样回答:

——从性能角度来讲,几个方面来看一下,第一个就是说,我们发起接受这个项目,他应该开始是从大众的需求、产品、营运和开发角度上,把测试作为出发点,帮我们介入双十一的挑战。我们性能角度有这么几个方面,一个是我们首先会评估当前的天猫这套应用体系的性能和容量支撑。第二个,因为产品是有需求的,我们对这个产品有准确的评估,会做一个比较有意思的预测,像10年、11年、12年,它的数量级是在整个的跨越甚至跳跃的。这对我们做性能测试或性能保障是一个比较大的挑战,正好接下来,我们聊聊这方面的行动:第一个就是对当前性能的容量评估,包括当前产品应用代码本身的健壮性、是否有瓶颈;第二,因为大促是一个比较烦杂、比较有挑战的一个事情,所以我们要做好一些保障;再有一个,专业技能方面就是预案,一个预案是我们预知当前所掌控的,另外一个是非掌控性的,我们要做一个后续的处理预案,出现类似异常的时候,我们从应用层面,或者从整个容量层面来做一个比较强的处理。最后就是说容量规划,需要非常有效,目前的跨机房的,包括网络流量的内容,是一个重头戏。

双“11”战绩惊人的背后―性能_第2张图片
这么复杂?

淘宝自创立以来,对性能测试要求也越来越高。从最初的系统框架性能测试、TOP-API接口性能测试,到现在的web应用性能测试,进军无线性能测试领域,淘宝性能测试在不断向前发展,横向、纵向都在不断深入、拓宽,不断创新。

1. 性能测试通过标准

性能测试从需求、设计、准备、执行到分析,最后需要判断性能测试是否通过。性能测试工程师最终需要考虑很多因素,判断的标准相应的也会有多个维度。  此处,引入超时阀值和超时概率两个概念。超时阀值,是指在框架模板中定义的超时时间,当服务器响应超过该定义值时,被测程序仍然响应请求,同时Profiler会打印超时日志。超时概率,是指超时次数除以总请求次数所得的值。

双“11”战绩惊人的背后―性能_第3张图片
天猫性能测试通过标准

性能测试通过标准,是判断性能测试通过与否的最全面的参考依据。随着淘宝性能测试的发展,这些标准估计也会随之做出相应改动,要求也会越来越严格。

2. 性能测试流程

性能测试是一个系统工程,涉及到PDM、PM、性能测试工程师、DBA、SCM、OPS等多个角色。从性能测试申请,到性能测试设计、性能测试环境、性能测试数据、性能测试执行、性能测试调优,都离不开这些角色的相互配合,共同协助。因此,淘宝网确立了一整套性能测试流程,采取团队合作的方式,降低沟通成本,提高工作效率。

双“11”战绩惊人的背后―性能_第4张图片
天猫性能测试流程图

3. 监控工具

性能测试通常采用下列工具进行监控:

a. Profiler  一个记录log的类,阿里巴巴集团自主开发,嵌入到应用代码中使用。

b. Jstat   监控java 进程GC情况,判断GC是否正常。

c. JConsole   监控java内存、java CPU使用率、线程执行情况等,需要在JVM参数中进行配置。

d. JMap   监控java程序是否有内存泄漏,需要配合eclipse插件或者MemoryAnalyzer来使用。

e. JProfiler   全面监控每个节点的CPU使用率、内存使用率、响应时间累计值、线程执行情况等,需要在JVM参数中进行配置。  

f. Nmon   全面监控linux系统资源使用情况,包括CPU、内存、I/O等,可独立于应用监控。

g. Valgrind   监控C/C++程序是否存在内存泄漏,基于linux环境。

h. Vmmap和ApplicationVerifier   监控C/C++程序是否存在内存泄漏,基于windows环境。


那么当双十天当天上线后,项目出现性能故障,卡死,这种情况阿里又是怎么解决的呢?

王德山:这是一个“惊喜”,带双引号的惊喜。当我收到这种信息的时候,一个是通过邮件,一个是通过手机短信、旺旺通知,要么线上报警,要么线上故障,当我们遇到这种报警的时候,作为性能测试人员,我们有责任去协助研发团队把这个事情搞清楚,大概有这样几个步骤:首先看,假如是一般的报警,我们去确认,排查问题解决掉。第二个,本身这个故障对业务产生了影响,造成了用户损害,我们需要立马修复这个BUG。还有就是从性能测试角度,有几个方面:一个是我们去协助开发一起来定位,通过各种的一些分析技术,像分析日志抓取缺陷,包括这种报警时的一些异常、用户的反馈,把这些信息收集起来,迅速的把它整理出有用的信息出来。第二个就是我们把这个问题在生产线上重现,,根据重现场景,捕获代码性能瓶颈,进而目标性优化。第三个就是,当我们把这些问题优化了以后,在线下做功能、性能的测试回归,确定没有问题了,通过语法预发测试、打补丁的方式去把性能瓶颈解决;杰茜莱就是故障的Review会议,我们要避免这种问题重演。

双“11”战绩惊人的背后―性能_第5张图片
膜拜大神!

你可能感兴趣的:(双“11”战绩惊人的背后―性能)