性能测试该怎么做？

性能优化的常见概念

吞吐量（TPS, QPS）：简单来说就是每秒钟完成的事务数或者查询数。通常吞吐量大表明系统单位时间能处理的请求数越多，所以通常希望TPS越高越好

响应时间：即从请求发出去到收到系统返回的时间。响应时间一般不取平均值，而是要去掉不稳定的值之后再取均值，比如常用的90%响应时间，指的就是去掉了10%不稳定的响应时间之后，剩下90%的稳定的响应时间的均值。从聚类的观点看，其实就是去掉离群点。

错误率：即错误请求数与总请求数之比。随着压力增加，有可能出现处理请求处理不过来的情况，这时错误数会不断增加。

三者有极大的关联，任何孤立的数据都不能说明问题。典型的关系是，吞吐量增加时，响应延迟有可能增加，错误率也有可能增加。因此，单拿出一个10w的TPS并不能说明问题。

性能调优的思路

一般情况，调优需要有个前提条件，即无论是用线上的真实流水还是线下的压力测试让问题扩大化，明显化。

根据这些比较明显的现象去初判问题，收集证据去验证初判结果成立，然后分析现象产生的原因，并尝试解决问题。

1.性能摸底测试

对于新上的系统或者是有过较大代码改动的系统来说，做一次摸底测试还是很有必要的。一般来说，期望摸底的测试是一次对单机的压力测试。压力测试可以帮你大概搞清楚系统的极限TPS是多少，在压力上来时有没有暴露一些错误或者问题，系统大致的资源占用情况是什么，系统可能的性能瓶颈在哪。

如下是一次摸底测试的配置和结果。这是用12000并发用户对10台机器压测的结果，可以看出，TPS到7w多，平均响应时间为82ms，错误率在2.5%。

从图中还可以得到哪些信息？首先，TPS在后期迅速下落，实际上已经支撑不了如此大的并发量，即进入崩溃区，这里有几个可能，一是系统根本承受不了如此大的并发量，二是系统中间有问题导致TPS下跌。其次，随着时间增长，错误率显著增加，说明系统已经处理不了如此多的请求。结合前面两点以及相对平稳的平均响应时间，大致可以推断系统没法承受如此大的并发。另外，由于是10台机器，单台的TPS大概在7000多，今后的调优可以以此为依据。

对于应用的特点，也要在这时候分析出来，即应用可能占用的资源。比如是CPU密集型应用还是IO密集型应用（还可以细分为是磁盘密集还是网络 ）