性能测试TPS指标到底多算才算合适呢？二八定律

前言

通常我们在压测的时候，都会有一个指标去衡量，比如搜索商品接口，我们预期TPS需要达到多少。

最理想的情况就是开发/产品/项目经理提前确定好了性能指标，但是通常大多数公司对于性能不是很理解，可能你问产品经理，产品经理说TPS是什么。那么这种情况下，我们就需要根据实际情况进行分析，确认性能指标。

明确压测项目类型

一般我们压测的项目会分为两类，一种是老项目，一个是新项目。像我们公司的项目已经上线运行了很长一段时间了，那么在生产环境中，会生成一些历史数据，并且线上也业务监控系统，定期监控各个业务模块核心接口的调用量、平均耗时等数据。那么我们可以去分析TOP前10的接口（这个根据公司实际情况而定），这些接口在过去一周或者一个月内，接口调用量最高的那一天，找到他的峰值。

比如我商品搜索的接口，接口调用量最高的时间点（分钟级别）如1：30分的时候，调用量为10000，那么我们可以根据根据这个峰值去计算他的TPS。 10000/60 =166, 因此我们可以确定这个接口TPS达到166即可满足。

那有些朋友会说，我们公司没有业务监控系统，这种怎么去评估呢？方法有很多，比如我们通过中间件的日志，每个中间件都有访问日志。比如 Nginx 的 access.log，该日志中详情记录了每个HTTP请求的访问时间、url、响应时间、响应状态码。

那么我们有这些数据，就可以通过脚本编写，统计处每个接口在哪个时间端调用最高、调用的峰值是多少。根据这个数据统计出接口每秒的tps。

二八定律

那么实际工作中，比如我们新上线一个项目，需要我们上线前先压测一轮，那么在没有历史数据的情况下，我们怎么去定义这个性能指标呢？

这里有一个算法，叫做 二八定律。意思是80%的用户请求发生在20%的时间内，下面我们来看看二八定律的定义。

八定律又名80/20定律、帕累托法则（Pareto‘s principle）也叫巴莱特定律、朱伦法则（Juran's Principle）、关键少数法则（Vital FeRule）、不重要多数法则（Trivial Many Rule）最省力的法则、不平衡原则等，被广泛应用于社会学及企业管理学等。

下面我们来看看如何计算TPS的指标：

首先先预估系统的每日总请求数，这个没有固定的方法，如果没有任何历史数据参考，一般是通过用户量或者其他关联系统来评估。

假设我们有一个APP，APP上线了新功能。这个APP的注册用户有1000w，日活用户大概在100w左右。在最极端的情况下，就是这100w个用户都来使用这个新功能，但是实际工作中，并不会是所有的人都会来用，但是我们需要考虑到这种极端情况，所以指标尽可能的往高了评估。

那么我们就按照100w用户的请求的80%计算，80%的请求数就是100w*0.8=80w。

其次是确定系统20%的时间，通常在公司一般是24小时对外提供服务的，那么通常0-6点这个时间端，都没有什么人用，我们排除掉这部分时间，24小时减去6小时，那么剩余18个小时，那20%的时间=18小时 * 3600秒 * 0.2 = 12960秒。那么最终计算出来的结果为80w 请求 / 12960s = 61左右。也就是说接口的TPS满足61就可以了。

但是到这里我们考虑到，比如之后平台做推广活动，到时候会有可能超出100w的日活，因此保险起见，我们通常会加上一个冗余系数，提高预期指标，防止人为评估造成预期指标偏低的情况。

一般冗余系数定位 2-5之间，这个会根据不同的公司情况而定，之前有个朋友她们公司是压测京东项目的，她就跟我说过她们公司的冗余系数是10。那么假设我们冗余系数是3，最终tps指标就定为61* 3 = 183 TPS。同时我们上线之后，可以通过对项目接口的峰值监控，来对比之前评估的算法结果，调整冗余系数，最终随着不断的数据累计将会形成一套项目的性能模型。

那么将来项目上线后，接口的访问量真的和计算的一模一样吗？这个肯定不会，大家一定得知道一个原则，性能测试从来都不是一门非常精确的技术。二八定律也并不是100%适用于所有业务场景。在没有任何历史数据参考的背景下，二八定律相对来说是一种相对来说靠谱的算法，最起码有一定的理论依据

总结一下， 二八定律的算法为 80%的请求 / 20%的时间 * 冗余系数

通常线上的项目都是集群部署的，如果说我们是压测单台服务器的话，tps指标需要在除以部署机器数量 ，即公式为（每天的总业务量80%） / （24小时3600 *20%）/ 部署机器数量 * 冗余系数。