posts - 97,  comments - 5,  trackbacks - 0

性能点:营销招商活动,提交报名

 

前言:

    以下是我在项目中完成的另一次性能测试实践,对性能测试还处于摸索阶段,如果有不准确的地方欢迎指点。

一、简介

批量交报名,libra2manager应用处理请求,调用libra2center服务进行相关商品和卖家信息的判断,调用qc服务进行卖家商品资质判断是否可报名、成功后插入到数据库。

系统依赖图


二、期望值的评估

RT

按照统一标准制定为300ms

TPS

卖家端应用libramanager平时一天的总pv量为30w;期望pv=pv*5 = 150w (考虑平时的小型促销*5,卖家开放后需要重新开发并重新考虑性能)

根据计算公式

每秒**平均值 =( (PV*80%)/(24*60*60*40%))/服务器数量(4pv/s   = 8

每秒**峰值 = (((PV*80%)/(24*60*60*40%))*1.6) /服务器数量(4pv/s   = 15 (平时最大的压力)

按照去年双12的场景,增加线上机器的情况下,预期TPS50 (开发提供的数据),则将此次TPS设置为50

三、Checklist

1、期望值评估

2、环境搭建:应用、数据库

3HTTP脚本(HSF脚本)

4、性能环境数据准备

5、功能是否已稳定

四、实施压测

压测结果

TPSRT都不满足期望

原因分析:CPUJVMload

应用:libra2managerlibra2centerqcDB

应用libra2manager、libra2center、qc的cpu、jvm等值都正常,再看DB的表现

原因定位:DB连接过多,一次批量提交3条报名的操作大约有21次select、3次update、1次的delete、1次insert

  (天机系统中查看)

五、原因分解

原因分解-爬代码,看看为什么有这么多次的数据库操作,以下是调用的会操作到数据库的接口


数据库操作:>20 ,分析结论:

1、多次查询contentDoblockDo,有优化空间

2savesubmit报名记录前的查询目前是3条记录3次查询可优化成一次查询

六、调优

调优点

1、较多的contentDo查询,改用读取tair的方式(这个问题应该是可以规避的,由于多个模块由不同开发负责,开发们缺乏沟通,缺乏整体的统筹)

2、批量报名saveApplication方法和submitApplication方法前的查询,改成一次查询

3ContentBlockQualiRootService查询得到的QualiDo,作为ApplicationAcessService接口的入参,减少查询一次QualiDo

调优结果

结论

1、调优后,批量提交三条报名记录,对数据库操作约11次,整体TPS提升约2.5倍。

2、单submitResult方法种就有3~4次的数据库操作,这块功能经评审不是非常重要,决定后续增加开关,系统压力较大时,屏蔽该功能,进一步减少对数据库操作


性能点:活动列表查询

前言:

    以下是我在项目中完成的一次性能测试实践,对性能测试还处于摸索阶段,如果有不准确的地方欢迎指点。


一、简要介绍

    卖家进入淘营销系统,查看当前可报名的所有营销活动。前台应用libra2manager首先从vsearch读取当前在报名进行中的所有活动,qc读取 这些活动所需判断的所有指标项后获取卖家对应的指标值,根据指标项要求和卖家具体指标值判断卖家可报名的所有活动,展现在可报名活动列表中

    qc首先在tair中读取卖家指标值,若tair中不存在该指标值,则从对应的datasource中读取

    系统依赖图

二、期望值的制定

¨RT

     所有活动列表按照统一标准制定为300ms;可报名列表业务调用的逻辑复杂度,再参照去年对列表的压测结果(分页有3s)和期望值(500ms),设置为500ms

¨TPS

      卖家端应用libramanager平时一天的总pv量为30w;期望pv=pv*5 = 150w (考虑平时的小型促销*5,卖家开放后需要重新开发并重新考虑性能)

根据计算公式

每秒**平均值 =( (PV*80%)/(24*60*60*40%))/服务器数量(4pv/s   = 8

每秒**峰值 = (((PV*80%)/(24*60*60*40%))*1.6) /服务器数量(4pv/s   = 15

三、系统设计阶段

qc的指标读取validate,以下四点是开发所进行的性能考虑

1. 提供批量验证接口,避免多次hsf调用。

2. 将资质数据读取方式从原有的懒加载改为预加载。合并多个资质树的资质,一次读取。

3. 并行数据读取。资质数据涉及多个系统(多个HSF调用),将多个HSF调用从串行改为并行

4. 并行验证。批量验证时采用并行的方式验证。

总结下来就是

1、abc:并行、tair

2、def:一次读取

3、多次调用变一次调用

其实大多数read方式的功能点都可以按以上三个方向去考虑性能问题,化串行为并行,化多次调用为一次调用,读取慢就考虑采用tair。

测试改进

原读取方式:合并指标项一次读取数据源a、b、c中对应所需的d、e、f

改进点:合并指标项一次读取数据源a、b、c中所有的指标值

举例,请求1需要数据源a中的指标d、e和数据源b中指标f;原读取方式是并行将a、b中的d、e、f读取出来;改进后的读取方式是并行将a、b中的d、e、f、g、h...都读取过来;它的性能提升将体现在下一次需要读取指标g、h...的请求N中

四、压测前的checklist

1、期望值评估:TPSRT

2、性能环境搭建

3HTTP脚本(HSF脚本)

4、性能环境数据准备

5、功能是否已稳定

五、压测

     第一次压测结果,我们期望结果能更好

场景名

并发用户数

事务名

性能指标

事务统计

TPS

RT(ms)

执行事务数

失败事务数

失败率

淘营销-list

14

canActions

22.961

506.519

82427

0

0%

allActions

22.963

104.37

82436

0

0%

淘营销-list

25

canActions

23.549

818.815

85010

0

0%

allActions

23.549

193.079

85010

0

0%

RT过高!

应用:Libra2manager->qc->Vsearch

分析:CPUJVMload

Libra2manager和qc的cpu、jvm都正常,Vsearch机器达到75左右,再通过profile打点判断RT消耗

原因定位Vsearch数据读取耗时占比>80%

这 里要提一个点,系统在设计过程中,考虑到性能问题,设置一次从vsearch读取的活动量为1024,获取第一批活动后即合并资质计算是否可报名,同时获 取第二批1024个活动,并行读取和验证。daily上目前是3100左右个报名进行中的活动,所以会有三次vsearch读取。

六、调优

    从结果上来看,vsearch读取耗时占比>80%的情况下,设计读取三次vsearch结果和qc验证并行可能不是最合理的。因此,调整一次vsearch读取的值验证性能表现

调优过程记录,将一次查询量上限设置为4000时性能表现最优。

¨

¨结论

1、当前活动量,一次将所有活动全部查询性能最好

2、当前线上处于报名中状态的活动为1943个,预计很长时间内将稳定在3000内,则将一次查询量数字确定设置为3000

七、最终压测结果


场景名

并发用户数

事务名

性能指标

事务统计

TPS期望值

TPS

RT期望值(ms

RT(ms)

执行事务数

失败事务数

失败率

混合场景:淘营销list

14

canActions

可报名活动

15

25.717

500

408.84

92322

0

0%

allActions

所有活动

15

25.72

300

139.184

92333

0

0%





天猫 软件自动化测试开发

posted on 2014-03-31 16:38 zouhui 阅读(381) 评论(0)  编辑  收藏 所属分类: 2.软件测试 性能自动化

只有注册用户登录后才能发表评论。


网站导航:
 
<2014年3月>
2324252627281
2345678
9101112131415
16171819202122
23242526272829
303112345

常用链接

留言簿(2)

随笔分类(94)

随笔档案(94)

搜索

  •  

最新评论

阅读排行榜

评论排行榜