1.性能测试从外部看，主要关注这三个指标：吞吐量,响应时间，错误率
吞吐量的指标受到响应时间，服务器软硬件配置，网络状态等多方面因素影响
正常来说-吞吐量越大,响应时间越长;服务器硬件配置越高，吞吐量越大；网络越差，吞吐量越小
2.与系统吞吐量有关的几个重要参数：QPS(TPS),并发数,响应时间越长
QPS（TPS）= 并发数/平均响应时间
一个系统吞吐量通常由QPS（TPS）、并发数两个因素决定，每套系统这两个值都有一个相对极限值，在应用场景访问压力下，只要某一项达到系统最高值，系统的吞吐量就上不去了，如果压力继续增大，系统的吞吐量反而会下降，原因是系统超负荷工作，上下文切换、内存等等其它消耗导致系统性能下降
3.并发数、QPS、平均响应时间三者之间关系
4.从服务器的角度看，性能测试主要关注CPU、内存、服务器负载、网络、磁盘IO等
top命令可以查看
cpu-后台服务的所有指令和数据处理都是由CPU负责，服务对CPU的利用率对服务的性能起着决定性的作用
us & sy：大部分后台服务使用的CPU时间片中us和sy的占用比例是最高的。同时这两个指标又是互相影响的，us的比例高了，sy的比例就低，反之亦然。通常sy比例过高意味着被测服务在用户态和系统态之间切换比较频繁，此时系统整体性能会有一定下降。另外，在使用多核CPU的服务器上，CPU 0负责CPU各核间的调度，CPU 0上的使用率过高会导致其他CPU核心之间的调度效率变低。因此测试过程中CPU 0需要重点关注。
id：线上服务运行过程中，需要保留一定的id冗余来应对突发的流量激增。在性能测试过程中，如果id一直很低，吞吐量上不去，需要检查被测服务线程/进程配置、服务器系统配置等。
wa：磁盘、网络等IO操作会导致CPU的wa指标提高。通常情况下，网络IO占用的wa资源不会很高，而频繁的磁盘读写会导致wa激增。如果被测服务不是IO密集型的服务，那需要检查被测服务的日志量、数据载入频率等。
内存：top命令可以查看
VIRT：进程所使用的虚拟内存的总数。它包括所有的代码，数据和共享库，加上已换出的页面，所有已申请的总内存空间
RES：进程正在使用的没有交换的物理内存（栈、堆），申请内存后该内存段已被重新赋值
SHR：进程使用共享内存的总数。该数值只是反映可能与其它进程共享的内存，不代表这段内存当前正被其他进程使用
SWAP：进程使用的虚拟内存中被换出的大小，交换的是已经申请，但没有使用的空间，包括（栈、堆、共享内存）
DATA：进程除可执行代码以外的物理内存总量，即进程栈、堆申请的总空间
从上面的解释可以看出，测试过程中主要监控RES和VIRT，对于使用了共享内存的多进程架构服务，还需要监沙发控SHR
网络--可以使用nethogs命令查看
磁盘IO--可以用iostat命令来监控磁盘状态、