性能指标的估算--TPS

性能测试指标怎么来的？
1、产品和运营要给出业务来估算：
这个服务，在多长时间段，有多少人会访问
2、性能要求上，通常情况下的APP应该如何？
页面访问的2、5、8原理（响应时间在2s以内用户体验流畅，响应时间5s以内用户认为可接受，8s以内还能忍受。超过8秒就没有人再等了，直接关闭服务）
因此页面的渲染时间+资源文件的载入时间+接口的获取时间需要保证1s~2s内完成
3、这个条件下接口获取时间多长合适？
无脑建议200ms以内（考虑到你页面也要2s打开，还要给其他工作留时间）
tps的计算通过业务案例来分析
案例的业务量要求
某业务，类似秒杀活动，用户估算有2W左右，每个用户平均请求2次接口（查询用户信息接口、查询业务接口），这些用户大概率会在2分钟内会访问我们的系统，业务要保证用户2s能打开页面
TPS的分析：
TPS：表示每秒处理事务数，一个事务是指一个客户端向服务器发送请求。服务器做出反应的过程。客户端发送请求。（后台接收到任务之后，还需要一定的处理时间）

给定业务场景，我们就需要先计算出来每秒需要系统处理多少任务，从而反推在压力测试的时候，需要给多大的TPS了。
首先，整个系统的总请求数=用户(2W)＊每个用户请求数（2次）=40000次
其次，每秒要求处理的请求数=总请求数/时间（切换到秒）即40000/2*60约350（333向上取个整）。
最后，TPS并发数量与每个请求所消耗的时间，可实际计算出每秒实际能够处理的请求数。
即每秒实际处理请求数量=tps数量＊1000【1秒，需要切换为毫秒】/单组tps处理时间【这里是按200ms返回】
因此，我们只要保证每秒实际处理请求数>每秒要求处理的请求数就可以了。
最终结果就是
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来做接口的压力测试。