我们经常需要对程序进行压测，怎么压才合适？压到什么样才说明应用达到了性能瓶颈？用什么指标来衡量才合适？一些指标异常又说明了什么？我们又该怎么样去查问题？这些都是压测时我们需要关注的。
按照大项划分，个人将性能指标分为下面几个大项：
一、基本性能指标 QPS 和 RT
这是测试过程中最基本的指标，也是我们主要需要关注的两项。QPS 是指系统每秒处理的请求个数（query per second）。RT 指一个请求发出后系统的响应时间（reaction time）。区别下 QPS 和 TPS（Transactions per Second），他俩很像但是不是一个东西。TPS 是指每秒处理的事务数，一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。举个例子比如某个接口里面有很多项操作，这时往往用 QPS 是不准确的，因为准确来说 QPS 针对的是 Query，是询问，如单独的数据库读甚至是写都可以叫一个询问，但当接口里有多个操作，本质上调用一次产生一次事务，同时里面有许多 Query。所以 QPS 往往会比 TPS 大些。如果针对应用来说我们调用一次内部逻辑又不可见不知道里面有多少操作，这时 TPS 和 QPS 常常区分不开的，建议用 TPS 来衡量好些。
这里还要提到一个重要概念：最佳线程数量，是指刚好消耗完服务器瓶颈资源的临界线程数。 最佳线程数和 QPS、RT 是有一定关系的，这个线程数需要在压测过程中不断地去调整（一般从小到大来调，刚开始可能10个），努力去接近我们设定预期的性能测试极限。这个线程数和请求量正比关系，但是一定不要认为线程数少请求量就小。一般线程数设置8-10个左右，QPS 就可以达到 500 多了。举个例子，一个线程一秒内可以发送 N 个请求其实也是固定的，那增加我们的线程个数，比如现在我们有 M 个线程，那每秒理论上可以发 M*N 个请求，不考虑应用瓶颈，那应用每秒 QPS 就可以达到 M*N，当然有瓶颈情况下 QPS 到一定程度就不会再提升了，因为一个应用每秒能处理的请求就那么多，每处理一个请求响应时间 RT 是有限的，当不断请求过来产生堆积，响应时间上升了，还会导致 QPS 的下降。
先看看这三者的关系，QPS = 1000*线程数量/RT。QPS 单位是秒，RT 单位是毫秒，所以有一个单位换算分子乘以了1000。QPS 和 RT 成反比，当超过最佳线程数，会导致资源竞争加剧，同时响应时间也会增加，QPS 下降。
那么问题来了，如何找到最佳线程数？最土但是最实用的方法是，逐步压测，不断地调整线程数来观察系统的负载。
二、数据库指标
很多应用的瓶颈是在数据库指标。比如连接数、数据库的操作监控等等。
三、性能指标
性能指标是针对性能机器的，最佳线程数调整的监控项就是根据这个指标来的。这底下有很多东西，罗列一下：CPU使用率、JVM堆栈使用情况、GC/FGC 次数、Load指标、网络延时。
3.1 CPU 使用率
一般性能测试指标，CPU 使用率小于 75% 比较合适。通过指令：cat /proc/stat 可以查看。第一行CPU是所有CPU数据总和，CPU0~3表示各个CPU数据。其中第一列为从系统启动开始累计到当前时间，用户态的CPU时间（单位：jiffies，1 jiffies = 0.01秒）。
3.2 JVM 堆栈使用情况
对于我们的应用来说，一般会配置 JVM 的，所以对于应用来说，看机器的整体内存是没有意义的，我们更要关注的是堆栈的使用情况，关注点在已用堆信息。
3.3 GC / FGC 次数
在性能测试过程中不能出现因为FGC 的产生导致响应时间急剧升高的现象，否则压测是不正确的。尽量保证 FGC 的出现次数是0，如果出现看看它的运行时间，要确保是 FGC 产生运行时间足够短，否则就可以提Bug了。GC 产生是比较正常的，也要确保它的产生时间保持在比较低的水平。
3.4 Load 指标
Load 是 CPU 的负载，它所包含的信息不是 CPU 的使用率状况，二是在一段时间内 CPU 正在处理以及等待CPU处理的进程数之和的统计信息，也就是CPU使用队列的长度的统计信息。一般测试时它的指标是Load<CPU的核数*2。通过指令：cat /proc/loadavg 可以查看。五个数字分别是一分钟平均负载，5分钟内平均负载，15分钟内平均负载，采样时刻运行队列的任务数目，系统中活跃任务数目，最大 pid 值（包括线程）。
3.5 网络延时
常用应用服务器ping数据库，看看数据库延时是多少。
四、整体测试指标
RT（Response Time）<= 200ms，根据业务有所不同，只读的可能小于 10ms。
Load 服务器负载 <= CPU Core
CPU <= 75%
压测失败率 <= 0.2%
此外还要关注下方法耗时。
五、工具
Visual VM
