然后我们再来看性能测试的指标是怎么来的呢？

1、产品和运营要给出业务需求：

这个服务，在多长时间段，多少人会访问

2、性能要求上，通常情况下的APP或者web应该如何？

一般情况下通用的标准是页面显示时间预判：

页面响应时间2、5、8原理(用户进入服务2s内要展示完所有内容，超过5秒用户就无法忍受了，超过8秒就没有人再等了，直接关闭服务)

页面响应时间3、5、10原理

这里包括了页面的渲染时间+资源文件的载入时间+接口的获取时间，那么在这个条件下，压测的平均响应时间也要在这个时间之内

怎么通过业务量来计算TPS多少合适呢？

案例1，秒杀型算法

案例的业务量要求

某业务，类似秒杀型，用户估算有2W左右，每个用户平均请求2次接口(比如查询用户信息接口、查询业务接口)， 这些用户大概率会在2分钟内会访问我们的系统，业务要保证用户2s能打开页面

TPS的分析

TPS是系统每秒钟处理的任务数量，给定了业务场景，我们就需要先计算出每秒需要系统处理多少任务，从而反推在压力测试的时候，需要多大的TPS了

首先，整个系统的总请求数=用户(2W)* 每个用户请求数(2次)= 40000次

其次，每秒要求处理的请求数=总请求数/时间(切换到秒) 即约40000/(2*60) = 333 (向上取个整350)既每秒要求处理的请求数是350

每秒实际处理请求数量=tps数量 * 1000【tps单位秒，需要切换为毫秒】/tps处理时间

TPS数量 > 每秒要求处理的请求数 * tps返回时间【加入按200ms计算】/1000ms

带入上面数据计算

tps>(350 * 200)/1000，具体tps>70。

因此可让压力测试人员按照tps100来压接口，返回在200ms以内就满足性能要求。

当然如果实际tps50的返回时间为100ms，则按照这个粗略的公式来推算，也是能够支撑的(350 * 100/1000=35，也就是说tps高于35，返回100ms以内也是可以的)

案例2，我们来看一个日常服务的算法

如：一个100w访问的服务，每天访问集中白天8小时，每个用户大约会请求3个接口，每天早上9点是峰值。

首先计算日均请求数(每秒)

按8小时 100w访问量、平均3个接口请求计算

每秒日均请求数=100w(访问量)* 3(每个访问量平均请求接口数)/8(小时)/3600(切换成秒)，结果就是每秒请求100次。

按接口200ms返回，tps需要> 100 * 200/1000，即>20就行了。

如考虑日常服务的峰值，则按4 * 日均，即每秒请求400次，则tps>80即可，因此可推荐按tps=100来做接口的压力测试。

如果用整日的数据来计算总请求数，需要按照日流量分布来估算一个峰值数据，可考虑使用 峰值=4 * 日均【当然还是要看你具体的访问量】

网络上面的总结

没啥人用的服务 tps 20，返回有300ms就行了

十万到百万级的服务，响应能达到tps50 /200ms就可以了

后台服务，能达到tps 20 / 200ms即可(通常后台同时使用也没多少人)

秒杀类的短时间高并发……TPS100或200 在 100ms内响应 应该也能撑一段时间(具体情况还是要看业务量)

在jmeter中，具体的平均响应时间，tps既吞吐量，请求次数都可以在图表中看到，一般来说在请求没有错误率的情况下，逐步提高请求数，查看平均响应时间，tps既吞吐量，并结合服务器的内存，cpu 使用率不高于80%来获取系统压力下的指标情况，从而进一步分析在目前服务器配置情况下，能否满足

如果这篇文章对你有所启发，点赞、转发都是一种支持