In life, before doing anything, it is best to define a goal.
Similarly, before our daily performance tests, the best performance of this index is expected to be finalized, there is no measure of expected indicators, we will be unable to assess whether the results of the test data meet expectations. Such indicators such as the following:
| interface |
TPS expected |
| Query Interface |
1000 |
| Storage interfaces |
2000 |
In practice it, the ideal situation is to develop / product / project manager has to determine in advance a good performance, then the index explicitly tell you.
But the ideal is full, the reality is very skinny, based on my years of performance testing experience, most mention the performance requirements of people, mostly do not understand performance, so there is no index or index, although there are, but racking our brains decision, there is no basis.
So as a tester, it is necessary to go through some of the data analysis, we first define a relatively scientific index before the test, so the test will be more valuable.
In general, we will pressure test the project is divided into two types, one is the old project, a new project.
Take a look at the old project, the project refers to the old project has been on the line, and has been running for some time, this time will have some historical data, historical data can be analyzed by means of the following
1, business monitoring system
In some companies, or some of the more mature companies, most of them have a wide variety of service monitoring system to regularly monitor the amount of calls each interface module core business, average time etc., generally do in minutes level monitoring, As shown below
We can see in the system over the past week (or month), the highest amount of the interface calls that day, and then found the same day in the amount of the interface calls the highest point in time (min level), for example, is the amount of calls at 12:10 10000, we then converted the amount per call 10000/60 = 166, so you can determine this interface to achieve as long as 166 tps to meet.
2, Log
Some companies (most of them are entrepreneurial companies) do not have the above-mentioned service monitoring system, and that there is no way to assess the expectations index it.
The method is there, and that is through middleware logs, each middleware has access logs. Nginx of the access.log example, the detailed log record for each HTTP request access time, url, response status code, response time, as FIG.
有了这些数据就好说了，我们可以通过一些脚本（自己编写或者找运维帮忙），统计出每个接口在哪个时间段调用最高，调用量峰值是多少。根据峰值数据，最终可以计算出每秒的调用量，然后可以将这个指标定为接口的预期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%的时间 * 冗余系数
看了上面一大堆分析，有的朋友可能又说了，别整这些有的没的，我们公司的项目就是啥都没有，三无产品，没有业务监控、没有中间件日志，也没有日活数据，那怎么评估预期指标。
对于这样的系统和公司，我的建议是，可以不要管什么指标了，直接开始测试，测试完成后，把本次测试数据发送给相关人员，然后大家召开会议会结果进行讨论，最终由领导来拍板决定系统性能是否满足需求。