性能测试分析之性能指标确认

在实际工作中，我们会接受到各种各样的性能测试任务，但是在这些性能测试任务中，很大的可能接口的性能指标没有办法很明确的给到测试人员，在这个时候怎么处理呢？

最理想的情况是：开发或者是项目经理/产品已经提前确定好了性能指标，然后将这个指标很明确的告诉你，这个接口就是要达到多少的tps

 理想很丰满，现实很骨感，根据实际的工作经验看，这种根本不会有（也许有，但是我还没碰见过）

所以作为性能测试人员，我们很有必要去针对一些数据进行分析，在实际测试之前就先明确一个相对科学的指标，这样测试出来的结果才更加有价值

好，下面很重要了

一般来说：我们对压测的项目可以分为两种，一种的老项目，一种是新项目

那么何为老项目？何为新项目，这个应该对测试人员来说不难，所谓老项目也就是指已经上线运行了一段时间的项目，新项目也就是还没有上线过的项目

一、针对老项目来分析

既然已经上线运行过一段时间，那么我们可以通过以下手段对历史数据进行分析

1、业务监控系统

在比较成熟点的公司，一般都会有各种各样的业务监控系统，定期监控各业务模块核心接口的调用量，平均耗时等，这个可以直接问运维要，或者和你有权限也可以直接上监控平台中看

数据：过去一周或者一个月内没调用接口量最该的一天，然后在找到接口量调用最好的时间点（分钟），比如在12：00的调用量为10000，那么我们再换算成S级别：10000/60=167，也就是说我们可以确定这个接口满足tps为167即可

2、日志

有的比较小一点的公司，可能压根就没有建立业务监控系统，这样就没有直接的数据了，但是办法也是有的，比如：日志，那么那么多的日志，我们找什么日志呢？

比如中间件的访问日志或者tomcat的访问日志，看情况自己寻找，这里举例说明下tomcat的访问日志吧，

tomcat的访问日志我们一般可以通过localhost_access_log.*.txt这个文件进行查看，里面记录了每一个接口的详细记录，请求的访问时间，URL，请求的方式，响应码，响应时间等，但是里面那么多记录，我们怎么处理呢？ 

有了这些日志信息就很好办了，如果你自己会Python或者java，那就自己写一个脚本搞定，如果自己不会那就找运维或者开发了，我们只需要统计出你需要的接口在哪个时间段调用量最高，峰值是多少，然后根据上面的公式来计算出TPS即可，计算出的的tps直接定为这个接口的预期TPS

二、针对新项目

在新项目中我们可没有这些线上数据，这怎么搞？一般在新项目上线前，很有可能会先压测一波，评估下项目的性能如何，到底能支持多少的并发，这个时候这个性能预期更为重要。但是我们又如何确定这个数据呢？

这里我们一般会使用“二八定律”

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

有句话说：世界上百分之八十的财富都掌握在百分之二十的人手里，不无道理

同样二八定律也适合我们目前的场景

通常，一个网站80%的用户请求是发生在20%的时间内，比如一个商城而言，针对下单购物，也基本是符合二八定律的，因为基本都集中在中午或者晚上下班的时候人们才会去购物吧。

二八定律的核心是关注重要的部分，忽略次要的部分，同样，如果在重要的部分都能够经受住考验，那么次要的也就没啥问题了，比如：我们的新系统的性能能够支撑发生在20% 的时间内的高并发请求，那么也必然可以支撑非高峰期的80%的时间访问

 

具体说下怎么使用二八定律来计算预期的指标

首先预估下系统的每日总请求数，这个一般是通过用户量或者其他关联系统来预估，

比如：你们的系统要新增一个功能，但是这个接口还没有上线，所以我们没有数据，那么我们根据现在的用户量来看，假如用户量为500W，其中日活为100w，在极端的情况下，这100W人都会来使用这个功能（实际可能没有，但是我们这是评估），那么每天都会有100W的调用量，80%的请求也就是：100W*0.8=80W

其次确定系统的20%的时间，假设我们的系统是24H提供服务的，但是一般在0点到6点的访问量极低，我们直接去掉这个时间，那就剩下18H，那么20%的时间也就是：18*20%*3600s=12960s

最终计算的结果为：80w请求/12960s = 62左右，也就是说这个接口的TPS满足61即可，但是同时还要考虑一个点，因为我们上面评估的基准用户量是日活的100w，有没有可能会发生这个功能上线后，会有超过这个日活量的用户都会来使用这个功能，所以在这里我们还要乘以一个冗余系数，提高预期指标

但是冗余系数怎么定？一般来说这个冗余系数为2-5（这个是行业经验吧），通过上面的62，假设我们取冗余系数为3，那就是186，所以我们最终得出的TPS标准就为186

 

 

总结下二八定律的计算方法：80%的请求 / 20%的时间 * 冗余系数