性能测试实践分享

性能测试实践分享

性能点：营销招商活动，提交报名

 

前言：

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

1、简介

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

系统依赖图

2、指望值的评估

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

3、Checklist

1、指望值评估

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

3、HTTP脚本（HSF脚本）

4、性能环境数据准备

5、功能是否已稳定

4、实施压测

压测结果

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

  (天机系统中查看)

5、缘由分解

缘由分解-爬代码，看看为何有这么屡次的数据库操做，如下是调用的会操做到数据库的接口

数据库操做：>20 ，分析结论：

1、屡次查询contentDo，blockDo，有优化空间

2、save和submit报名记录前的查询目前是3条记录3次查询可优化成一次查询

6、调优

调优势

1、较多的contentDo查询，改用读取tair的方式（这个问题应该是能够规避的，因为多个模块由不一样开发负责，开发们缺少沟通，缺少总体的统筹）

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

3、ContentBlockQualiRootService查询获得的QualiDo，做为ApplicationAcessService接口的入参，减小查询一次QualiDo

调优结果

结论

一、调优后，批量提交三条报名记录，对数据库操做约11次，总体TPS提高约2.5倍。

二、单submitResult方法种就有3~4次的数据库操做，这块功能经评审不是很是重要，决定后续增长开关，系统压力较大时，屏蔽该功能，进一步减小对数据库操做

性能点：活动列表查询

前言：

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

1、简要介绍

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

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

    系统依赖图

2、指望值的制定

¨ 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

3、系统设计阶段

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

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

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

3. 并行数据读取。资质数据涉及多个系统（多个HSF调用），将多个HSF调用从串行改成并行

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

总结下来就是

一、a、b、c：并行、tair

二、d、e、f：一次读取

三、屡次调用变一次调用

其实大多数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中

4、压测前的checklist

1、指望值评估：TPS、RT

2、性能环境搭建

3、HTTP脚本（HSF脚本）

4、性能环境数据准备

5、功能是否已稳定

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读取。

6、调优

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

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

¨

¨ 结论

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

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

7、最终压测结果

场景名	并发用户数	事务名		性能指标				事务统计
				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%