批量提交报名，libra2manager应用处理请求，调用libra2center服务进行相关商品和卖家信息的判断，调用qc服务进行卖家商品资质判断是否可报名、成功后插入到数据库。
系统依赖图
二、期望值的评估
RT：
按照统一标准制定为300ms
TPS：
卖家端应用libramanager平时一天的总pv量为30w；期望pv=总pv量*5 = 150w （考虑平时的小型促销*5，卖家开放后需要重新开发并重新考虑性能）
根据计算公式
每秒**平均值 =( (总PV量*80%)/(24*60*60*40%))/服务器数量（4） = pv/s = 8
每秒**峰值 = (((总PV量*80%)/(24*60*60*40%))*1.6) /服务器数量（4）= pv/s = 15 （平时最大的压力）
按照去年双12的场景，增加线上机器的情况下，预期TPS是50 （开发提供的数据），则将此次TPS设置为50
三、Checklist
1、期望值评估
2、环境搭建：应用、数据库
3、HTTP脚本（HSF脚本）
4、性能环境数据准备
5、功能是否已稳定
四、实施压测
压测结果
TPS和RT都不满足期望
原因分析：CPU、JVM、load
应用：libra2manager、libra2center、qc、DB
应用libra2manager、libra2center、qc的cpu、jvm等值都正常，再看DB的表现
原因定位：DB连接过多，一次批量提交3条报名的操作大约有21次select、3次update、1次的delete、1次insert
(天机系统中查看)
五、原因分解
原因分解-爬代码，看看为什么有这么多次的数据库操作，以下是调用的会操作到数据库的接口
数据库操作：>20 ，分析结论：
1、多次查询contentDo，blockDo，有优化空间
2、save和submit报名记录前的查询目前是3条记录3次查询可优化成一次查询
六、调优
调优点
1、较多的contentDo查询，改用读取tair的方式（这个问题应该是可以规避的，由于多个模块由不同开发负责，开发们缺乏沟通，缺乏整体的统筹）
2、批量报名saveApplication方法和submitApplication方法前的查询，改成一次查询
3、ContentBlockQualiRootService查询得到的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%))/服务器数量（4） = pv/s = 8
每秒**峰值 = (((总PV量*80%)/(24*60*60*40%))*1.6) /服务器数量（4）= pv/s = 15
三、系统设计阶段
qc的指标读取validate，以下四点是开发所进行的性能考虑
1. 提供批量验证接口，避免多次hsf调用。
2. 将资质数据读取方式从原有的懒加载改为预加载。合并多个资质树的资质，一次读取。
3. 并行数据读取。资质数据涉及多个系统（多个HSF调用），将多个HSF调用从串行改为并行
4. 并行验证。批量验证时采用并行的方式验证。
总结下来就是
1、a、b、c：并行、tair
2、d、e、f：一次读取
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、期望值评估：TPS、RT
2、性能环境搭建
3、HTTP脚本（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
分析：CPU、JVM、load
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 阅读(391)
评论(0) 编辑 收藏 所属分类:
2.软件测试 性能自动化