一、通过线上监控观察(准确度较高)
查看待压测接口的线上监控数据（请求量和RT），可以直接查看该接口的某一段时间的调用峰值，将统计粒度换算为每秒请求量（qps）。
例一：
某接口1天被请求36万次（粗粒度统计），平均RT在100ms，指标计算如下
指标=(日量36万/10小时高峰期/3600秒)x5倍保险系数=50qps、rt100ms
例二：
某接口近期监控显示的请求峰值为1小时36万次（粗粒度统计），平均RT在100ms，，指标计算如下
指标=(时量36万/3600秒)x5倍保险系数=500qps、rt100ms
二、通过相似接口类比(准确度较低)
针对新接口或者线上无监控的接口，但存在类似接口的监控，可以类比计算。
例：
A接口线上指标为50qps、rt100ms，新接口B的使用场景和A相似度很高，那可以将B接口的性能也指标定位50qps、rt100ms
三、估算法(准确度低)
针对新接口或者线上无监控的接口，也没有类似的接口可以参考，仅从产品或者市场调研估算出某一天的量或者某一段时间的量，接下来估算方法和方法一类似。关于RT，如没特别说明，将会采用默认性能要求值（单服务单表类rt<100ms；较复杂接口rt<300ms；大list类或调用链较长接口rt<1s）
例：
通过运营数据得知接口A在1天内要完成36万笔交易，指标计算如下
指标=(日量36万/10小时高峰期/3600秒)x8倍保险系数=80qps、rt100ms
四、其他情况：
除以上场景外，针对新接口无任何数据，无法给出指标值情况，性能压测不再关注指标压测，仅执行阶梯性的负载测试，压测出该接口的最优处理能力。（此情况存在较大风险，上线后需要时刻关注，尽量避免此情形。）
关于估算指标的系数
3倍5倍7倍等系数的作用，一方面是为了解决业务量估算的误差，一方面是为了解决峰值问题（一分钟内60秒，可能某十几秒会很高，其他较低，在一分钟这个维度会出现正态分布的效果）。
至于系数问题，这个和估算过程中统计的粒度和估算业务量有关系，比如当前线上的监控都能监控到秒级，那么拉取这几个月最高的TPS，那就是目标指标的tps，系数就可以不加了。
大部分项目，很多都不知道自己的业务量多少，那为了避免估算的不准确性，这个系数可以适当放大，我们一般测试结束后，都会去关注线上真实的量（来看下之前业务估算的量是否准确、系数是否需要适当调整等等）
总结
综上可知，估算过程中提供的请求总量和时间段越精确，估算出来的指标将会越准确。（另外，估算指标一般都会大于实际线上流量的，因为业务给数据的时候会上浮请求量，而本身又乘以了几倍的峰值系数）
