在我们日常做性能测试之前,最好把本次预期性能指标确定下来,没有预期指标的衡量,将无法评估测试结果数据是否满足预期。比如以下这样的指标:
在实际工作中呢,最理想的情况是,开发/产品/项目经理已经提前确定好了性能指标,然后把指标明确的告诉你。
但是理想很丰满,现实很骨感,根据我多年的性能测试经验来看,大多数提性能需求的人,大多是不太懂性能的,所以根本不会有指标的,或者虽然有指标,但是是拍脑袋决定的,没有任何依据。
所以作为一个测试人员,很有必要去通过一些数据分析,在测试之前就先明确一个相对科学的指标,这样测试才会更加有价值。
一般来讲,我们将压测的项目分为两类,一种是老项目,一种新项目。先看看老项目,老项目是指项目已经上线了,并且已经运行了一段时间,这时候会产生一些历史数据,可以通过以下手段对历史数据进行分析。
1、业务监控系统
在一些大厂,或者一些发展比较成熟的公司,大多都有各种各样的业务监控系统,定期监控各业务模块核心接口的调用量、平均耗时等等,一般是以分钟级别做监控,如下图
那么我们可以去分析TOP前10的接口(这个根据公司实际情况而定),我们可以在系统里查看过去一周(或者一个月)内,接口调用量最高的那一天,然后再找到当天中接口调用量最高的时间点(分钟级别),比如说是在12:10调用量为10000,那么我们再换算为每秒调用量10000/60=166,因此可以确定这个接口tps只要达到166即可满足。
2、日志
有的公司(大多数都是创业型公司)根本没有上述的业务监控系统,那有没有办法去评估预期指标呢。
方法也是有的,那就是通过中间件的日志,每个中间件都有访问日志。比如Nginx的access.log,该日志中详细记录了每个HTTP请求的访问时间、url、响应状态码、响应时间等,如下图
有了这些数据就好说了,我们可以通过一些脚本(自己编写或者找运维帮忙),统计出每个接口在哪个时间段调用最高,调用量峰值是多少。根据峰值数据,最终可以计算出每秒的调用量,然后可以将这个指标定为接口的预期TPS。
接下来我们重点说一下新项目,也是在实际工作中遇到最多的情况。
新项目是还没有上线,在上线前希望先进行一轮压测,评估项目性能是否能支撑当前的用户,这个时候性能预期指标更为重要。但是由于是新项目,线上并没有任何的历史监控数据和日志数据,所以之前介绍的方法就不再适用,这个时候需要使用另外一种方法来评估性能指标,那就是“二八定律”。
什么是二八定律?先来看一下定义:
二八定律又名80/20定律、帕累托法则(Pareto‘s principle)也叫巴莱特定律、朱伦法则(Juran’s Principle)、关键少数法则(Vital FeRule)、不重要多数法则(Trivial Many Rule)最省力的法则、不平衡原则等,被广泛应用于社会学及企业管理学等。
二八定律是19世纪末20世纪初意大利经济学家帕累托发现的。他认为,在任何一种事物中,最重要的只占其中一小部分,约20%,其余80%尽管是多数,却是次要的。
从经济学上看,世界上80%的财富,都集中的20%的人手里
从心理学来说,人类80%的智慧,都集中在20%人身上。
二八定律是一种社会准则,符合大多数社会现象的规律。同样也适用于互联网领域。
一个网站有成千上万的用户,但是80%的用户请求是发生在20%的时间内,比如大家去网上购物,基本也都集中在中午休息或晚上下班后。二八定律的核心原则是关注重要部分,忽略次要部分。系统性能如果能支撑发生在20%时间内的高并发请求,必然也能支持非高峰期的访问。
具体来说下怎么通过二八定律来计算预期指标。
首先先预估系统的每日总请求数,这个没有固定的方法,如果没有任何历史数据参考,一般是通过用户量或者其他关联系统来评估。
比如某网站新增了一个每日签到送积分功能,由于还没有上线,所以没有签到的数据。网站的注册用户1000w,日活跃用户大概是100w左右,那么最极端情况下,这100w人都会来签到(实际肯定不会这么多人来签到,但是评估指标要尽量往高评,以免出现极端情况),那么每天大概有100w次签到请求,80%的请求数就是100w*0.8=80w。
其次确定系统的20%时间,大多数系统是24小时对外提供服务的(也有一些系统,比如政府类的项目,是在一天的某个时间段提供服务的)。但是大多数系统在0点-6点之间访问量很少,从一天的总访问量来看,可以忽略不计。所以统计时间的时候,可以把这段时间去掉,一天24小时去掉这6个小时,还剩下18个小时,那20%的时间=18小时3600秒0.2=12960秒。
最终计算出来的结果为80w请求/12960秒=61左右。
也就是说接口TPS满足61即可。但是也需要考虑一个问题,因为上面的用户请求是按照100w评估,也有可能推出这个活动后,每日会有超过100w的用户来签到。签到业务每个用户只能执行一次,如果是其他业务,可能会有多次操作。所以评估出来指标后,为了更加保险一些,最好再乘以一个冗余系数,提高预期指标,防止人为评估造成预期指标偏低的情况。
这个冗余系数一般定为2-5之间(个人经验),上面计算出来的tps指标为61,如果再乘以一个冗余系数3,那么最终tps指标就定为183。同时,将来项目上线后,可以通过对项目接口的峰值监控,来对比之前评估的算法结果,调整冗余系数,最终随着不断的数据积累,将会形成一套本项目的性能模型。
那么将来项目上线后,接口的访问量真的和计算的一模一样吗?这个肯定不会,大家一定得知道一个原则,性能测试从来都不是一门非常精确的技术。二八定律也并不是100%适用于所有业务场景。在没有任何历史数据参考的背景下,二八定律相对来说是一种相对来说靠谱的算法,最起码有一定的理论依据,比拍脑袋猜的值靠谱多了。
总结一下,二八定律的算法为: 80%的请求 / 20%的时间 * 冗余系数
注:二八原则计算的结果并非在线并发用户数,是系统要达到的处理能力(吞吐量)
通常线上的项目都是集群部署的,如果说我们是压测单台服务器的话,tps指标需要在除以部署机器数量 ,即公式为(每天的总业务量80%) / (24小时3600 *20%)/ 部署机器数量 * 冗余系数。
限制TPS的原因:服务器本身性能、代码结构、客户端施加的压力以及网卡等。
利用并发用户数、期望响应时间,可以计算出TPS的期望值。TPS = 并发用户数/(RT+Think Time),实际TPS和响应时间都是单独计算出来的,两者不是互相计算出来的。虽然在宏观上是反比的关系,但是两者之间没有直接关系。
系统TPS会受到并发用户数的影响,刚开始会随着并发用户数的增加而逐渐增加,当系统进入繁忙期后,TPS会有所下降。利用TPS与并发用户数图,可以分析性能瓶颈。
举例说明: 当并发数增加到10的时候,响应时间始终都是1,TPS还在继续增加,说明并发不够,需要增加并发数以达到TPS的峰值。
如果继续增加并发用户数到20,而响应时间还是1,再增加并发用户数,响应时间大于1,说明TPS达到了峰值20。
继续增加并发用户数到100,则造成了线程等待,引起平均响应时间从1秒变成3秒,TPS也从20下降到9;
看了上面一大堆分析,有的朋友可能又说了,别整这些有的没的,我们公司的项目就是啥都没有,三无产品,没有业务监控、没有中间件日志,也没有日活数据,那怎么评估预期指标。
对于这样的系统和公司,我的建议是,可以不要管什么指标了,直接开始测试,测试完成后,把本次测试数据发送给相关人员,然后大家召开会议会结果进行讨论,最终由领导来拍板决定系统性能是否满足需求。