性能测试的一些基础

性能测试要考虑的几个因素：吞吐量、响应时间、资源利用、错误率。。。

 

失败率

1. 性能测试的失败率的容忍应该是非常低的。对于一些关键系统，成功请求数必须在100%，一点都不能含糊

 压测时间：

一般业务15-30分钟

吞吐量：

1.吞吐量的值需要和响应时间结合来看，比如：TP99小于100ms的时候，系统可以承载的最大并发数是1000qps

2.系统的最大TPS是一定的（在一个范围内），但并发用户数不一定，可以调整。

3.最大的tps:不断的增加并发数，加到tps达到一定值开始出现下降，那么那个值就是最大的tps。

4.性能测试最终的目的，是找到系统的瓶颈，一般来说，是找到服务单机最大TPS(每秒完成的事务数)需要注意的是，服务的TPS需要结合请求平均耗时来综合考虑。例如：服务TPS压到1000，平均请求耗时500ms，但是假如我们定的服务请求耗时不能超过200ms，那么这个1000的TPS是无效的。

响应时间：

1.响应时间：百分比分布统计，不能光取平均值。（例如99.9%的请求必须小于1ms，所有的平均时间必须小于1ms。两个条件的限制。）

2.定义一个系统的响应时间latency，建议是TP99，以及成功率。比如路透的定义：99.9%的响应时间必需在1ms之内，平均响应时间在1ms以内，100%的请求成功。

3.在这个响应时间的限制下，找到最高的吞吐量。测试用的数据，需要有大中小各种尺寸的数据，并可以混合。最好使用生产线上的测试数据。

并发用户数：

1.一般情况下，大型系统（业务量大、机器多）做压力测试，5000个用户并发就够了，中小型系统做压力测试，1000个用户并发就足够了。

2.Throughput吞吐量每秒请求的数大于并发数，则可以慢慢的往上面增加；若在压测的机器性能很好的情况下，出现吞吐量小于并发数，说明并发数不能再增加了，可以慢慢的往下减，找到最佳的并发数；

3.判断一个应用是否满足性能指标，只需要判断这个应用每秒能处理多少请求，和用户并没有直接关系，并发不是指用户，而是指请求。