1 测试指标
根据服务实际情况选择需要评估指标进行衡量

1.1 CPU性能
1.1.1 CPU 使用率

用户 CPU 使用率，包括用户态 CPU 使用率（user）和低优先级用户态 CPU 使用率（nice），表示 CPU 在用户态运行的时间百分比。用户 CPU 使用率高，通常说明有应用程序比较繁忙。

系统 CPU 使用率，表示 CPU 在内核态运行的时间百分比（不包括中断）。系统 CPU 使用率高，说明内核比较繁忙。

等待 I/O 的 CPU 使用率，通常也称为 iowait，表示等待 I/O 的时间百分比。iowait 高，通常说明系统与硬件设备的 I/O 交互时间比较长。

软中断和硬中断的 CPU 使用率，分别表示内核调用软中断处理程序、硬中断处理程序的时间百分比。它们的使用率高，通常说明系统发生了大量的中断。

统计数据的方式

top

用户CPU使用率 = us + ni

系统CPU使用率 = sy

iowait CPU使用率 = wa

软中断和硬中断的 CPU 使用率 = si + hi

1.1.2 平均负载
指单位时间内，系统处于可运行状态和不可中断状态的平均进程数，也就是平均活跃进程数

衡量负载的标准

需要根据当前的cpu数来进行比较，需要先计算出当前服务所在服务器上的cpu数来衡量

grep 'model name' /proc/cpuinfo | wc -l

例：假设我们在一个单 CPU 系统上看到平均负载为 1.73，0.60，7.98，那么说明在过去 1 分钟内，系统有 73% 的超载，而在 15 分钟内，有 698% 的超载，从整体趋势来看，系统的负载在降低(超载量=平均负载- CPU数量)

如果 1 分钟、5 分钟、15 分钟的三个值基本相同，或者相差不大，那就说明系统负载很平稳。

如果 1 分钟的值远小于 15 分钟的值，就说明系统最近 1 分钟的负载在减少，而过去 15 分钟内却有很大的负载。

如果 1 分钟的值远大于 15 分钟的值，就说明最近 1 分钟的负载在增加，这种增加有可能只是临时性的，也有可能还会持续增加下去，所以就需要持续观察。一旦 1 分钟的平均负载接近或超过了 CPU 的个数，就意味着系统正在发生过载的问题，这时就得分析调查是哪里导致的问题，并要想办法优化了

统计数据的方式

uptime //或者top

后面三个数字，依次则是过去 1 分钟、5 分钟、15 分钟的平均负载

1.2 内存性能
1.2.1 系统内存性能

total 是总内存大小

used 是已使用内存的大小，包含了共享内存

free 是未使用内存的大小

shared 是共享内存的大小

buff/cache 是缓存和缓冲区的大小

available 是新进程可用内存的大小。

统计数据的方式

free -h

1.2.2 程序内存性能

VIRT 是进程虚拟内存的大小，只要是进程申请过的内存，即便还没有真正分配物理内存，也会计算在内。

RES 是常驻内存的大小，也就是进程实际使用的物理内存大小，但不包括 Swap 和共享内存。

SHR 是共享内存的大小，比如与其他进程共同使用的共享内存、加载的动态链接库以及程序的代码段等。共享内存 SHR 并不一定是共享的，比方说，程序的代码段、非共享的动态链接库，也都算在 SHR 里。当然，SHR 也包括了进程间真正共享的内存。所以在计算多个进程的内存使用时，不要把所有进程的 SHR 直接相加得出结果

%MEM 是进程使用物理内存占系统总内存的百分比。

统计数据的方式

top

1.3 网络性能
1.3.1 网络层和数据链路层转发性能
在这两个网络协议层中，每秒可处理的网络包数 PPS，就是最重要的性能指标。特别是 64B 小包的处理能力，需要特别测试。

测试工具推荐 pktgen

1.3.2 传输层TCP/UDP 性能
测试工具推荐 iperf 或者 netperf

iPerf - iPerf3 and iPerf2 user documentation
Care and Feeding of Netperf 2.7.X

压测一段时间记录pps和吞吐率

数字1表示每隔1秒输出一组数据

sar -n DEV 1

rxpck/s 和 txpck/s 分别是接收和发送的 PPS，单位为包 / 秒。

rxkB/s 和 txkB/s 分别是接收和发送的吞吐量，单位是 KB/ 秒。

rxcmp/s 和 txcmp/s 分别是接收和发送的压缩数据包数，单位是包 / 秒。

%ifutil 是网络接口的使用率，即半双工模式下为 (rxkB/s+txkB/s)/Bandwidth，而全双工模式下为 max(rxkB/s, txkB/s)/Bandwidth

1.3.3 应用层HTTP/HTTPS 性能
测试工具推荐 wrk

相对ab和iperf这类工具来说，wrk可以嵌入lua脚本，给请求增加payload，更接近实际应用场景，测出服务的真实性能。

-c表示并发连接数1000，-t表示线程数为2，-d表示测试持续时间单位s

wrk -c 1000 -t 2 -d 300s --latency http://192.168.1.1/

#wrk 安装方式
https://github.com/wg/wrk
cd wrk
apt-get install build-essential -y
make
sudo cp wrk /usr/local/bin/

请求延迟的分布

附上延时分布条形图

8 threads and 200 connections （共8个测试线程，200个连接）

Thread Stats  Avg      Stdev    Max  +/- Stdev
 
              （平均值） （标准差）（最大值）（正负一个标准差所占比例）
 
    Latency    46.67ms  215.38ms  1.67s    95.59%
 
    （延迟）
 
    Req/Sec    7.91k    1.15k  10.26k    70.77%
 
    （处理中的请求数）
  Latency Distribution （延迟分布）
 
    50%    2.93ms
 
    75%    3.78ms
 
    90%    4.73ms
 
    99%    1.35s （99分位的延迟：%99的请求在1.35s以内）
 
  1790465 requests in 30.01s, 684.08MB read （30.01秒内共处理完成了1790465个请求，读取了684.08MB数据）

Requests/sec:  59658.29 （平均每秒处理完成59658.29个请求）
 
Transfer/sec:    22.79MB （平均每秒读取数据22.79MB）

先使用单线程不断增加连接数，直到QPS保持稳定或响应时间超过业务要求限制。在当期数值取得单线程最优连接数。
单个连接线程数保持不变，不断增加线程数(建议到CPU核心数为止即可)，直到整体出现QPS水平。
如果QPS没有出现随着线程数增长则是目标服务器性能已经达到瓶颈，wrk单线程即可压测出目标机器最优QPS。
如果QPS一直没有出现水平趋势，则说明wrk压测机性能出现了瓶颈，需要扩大wrk压测机性能或者增加压测机器集群。
运行 wrk 的机器必须有足够数量的可用临时端口，并且应该快速回收关闭的套接字。 为了处理初始连接突增，服务器的 listen(2) backlog 应该大于正在测试的并发连接数。
测试短链接并发连接数

Releases · link1st/go-stress-testing · GitHub

-c 表示并发数

-n 每个并发执行请求的次数，总请求的次数 = 并发数 * 每个并发执行请求的次数

-u 需要压测的地址

运行 以mac为示例

./go-stress-testing-mac -c 1 -n 100 -u https://www.baidu.com/