性能指标峰值
简述
- 彻底理解了性能指标(1)(2)的内容，这一篇随笔其实就不用看了，而且大家也能猜到这一篇内容是啥：二八原则
- 性能指标不要硬性的往那些性能指标上去靠，要根据业务来，熟悉业务，明白了解你们的项目性能的点在哪，是用户量，QPS，TPS，PV等，哪个是重点，哪个会给用户带来性能瓶颈。
- 根据项目、需求、用户给出的已有条件，去换算出我们可以预估的性能指标目标
- 有一个盲点，帮大家缕清一下，不是所有的指标都有量和率这么一说，要从实际需求，项目要求出发。比如吞吐量、吞吐率这个指标，从业务角度出发，考虑请求总数即可，没有吞吐率这么一说，有人就会说，那也可以看每秒传输了多少请求啊，那我问你，QPS、QTS统计的是什么？从网络角度出发，考虑传输的总字节数，每秒传输的字节数，也就是吞吐率
二八定律
二八定律又名80/20定律、帕累托法则（Pareto‘s principle）也叫巴莱特定律、朱伦法则（Juran’s Principle）、关键少数法则（Vital FeRule）、不重要多数法则（Trivial Many Rule）最省力的法则、不平衡原则等，被广泛应用于社会学及企业管理学等。
二八定律是19世纪末20世纪初意大利经济学家帕累托发现的。他认为，在任何一种事物中，最重要的只占其中一小部分，约20%，其余80%尽管是多数，却是次要的。
从经济学上看，世界上80%的财富，都集中的20%的人手里
从心理学来说，人类80%的智慧，都集中在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%的时间 * 冗余系数
