【转】性能测试中的二八原则

写的很好，转自 https://www.cnblogs.com/brainchan/p/10978025.html

性能测试中的二八原则

在生活中，做任何事情之前，最好先确定一个目标。

同样的，在我们日常做性能测试之前，最好把本次预期性能指标确定下来，没有预期指标的衡量，将无法评估测试结果数据是否满足预期。比如以下这样的指标：

接口	预期TPS
查询接口	1000
入库接口	2000

 在实际工作中呢，最理想的情况是，开发/产品/项目经理已经提前确定好了性能指标，然后把指标明确的告诉你。

但是理想很丰满，现实很骨感，根据我多年的性能测试经验来看，大多数提性能需求的人，大多是不太懂性能的，所以根本不会有指标的，或者虽然有指标，但是是拍脑袋决定的，没有任何依据。

所以作为一个测试人员，很有必要去通过一些数据分析，在测试之前就先明确一个相对科学的指标，这样测试才会更加有价值。

 

一般来讲，我们将压测的项目分为两类，一种是老项目，一种新项目。

先看看老项目，老项目是指项目已经上线了，并且已经运行了一段时间，这时候会产生一些历史数据，可以通过以下手段对历史数据进行分析

1、业务监控系统

在一些大厂，或者一些发展比较成熟的公司，大多都有各种各样的业务监控系统，定期监控各业务模块核心接口的调用量、平均耗时等等，一般是以分钟级别做监控，如下图

我们可以在系统里查看过去一周（或者一个月）内，接口调用量最高的那一天，然后再找到当天中接口调用量最高的时间点（分钟级别），比如说是在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%的时间 * 冗余系数

 

看了上面一大堆分析，有的朋友可能又说了，别整这些有的没的，我们公司的项目就是啥都没有，三无产品，没有业务监控、没有中间件日志，也没有日活数据，那怎么评估预期指标。 

对于这样的系统和公司，我的建议是，可以不要管什么指标了，直接开始测试，测试完成后，把本次测试数据发送给相关人员，然后大家召开会议会结果进行讨论，最终由领导来拍板决定系统性能是否满足需求。