1 测试指标
根据服务实际情况选择需要评估指标进行衡量
1.1 CPU性能
1.1.1 CPU 使用率
用户CPU使用率 |
系统CPU使用率 |
iowait CPU使用率 |
软中断和硬中断的 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 平均负载
指单位时间内，系统处于可运行状态和不可中断状态的平均进程数，也就是平均活跃进程数
1min |
5min |
15min |
衡量负载的标准
需要根据当前的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 |
total 是总内存大小
used 是已使用内存的大小，包含了共享内存
free 是未使用内存的大小
shared 是共享内存的大小
buff/cache 是缓存和缓冲区的大小
available 是新进程可用内存的大小。
统计数据的方式
free -h
1.2.2 程序内存性能
VIRT |
RES |
SHR |
%MEM |
VIRT 是进程虚拟内存的大小，只要是进程申请过的内存，即便还没有真正分配物理内存，也会计算在内。
RES 是常驻内存的大小，也就是进程实际使用的物理内存大小，但不包括 Swap 和共享内存。
SHR 是共享内存的大小，比如与其他进程共同使用的共享内存、加载的动态链接库以及程序的代码段等。共享内存 SHR 并不一定是共享的，比方说，程序的代码段、非共享的动态链接库，也都算在 SHR 里。当然，SHR 也包括了进程间真正共享的内存。所以在计算多个进程的内存使用时，不要把所有进程的 SHR 直接相加得出结果
%MEM 是进程使用物理内存占系统总内存的百分比。
统计数据的方式
top
1.3 网络性能
1.3.1 网络层和数据链路层转发性能
在这两个网络协议层中，每秒可处理的网络包数 PPS，就是最重要的性能指标。特别是 64B 小包的处理能力，需要特别测试。
测试工具推荐 pktgen
所用时间 |
网络包数量 |
PPS |
吞吐量 |
错误数 |
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
Linux 4.15.0-1035 (ubuntu) 01/06/19 _x86_64_ (2 CPU)
13:21:40 IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s %ifutil
13:21:41 eth0 18.00 20.00 5.79 4.25 0.00 0.00 0.00 0.00
13:21:41 lo 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
吞吐量 |
PPS |
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/
QPS |
吞吐率 |
请求总数 |
请求失败总数 |
请求成功率 |
请求延迟的分布
50% |
75% |
90% |
99% |
附上延时分布条形图
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/
模板如下：
性能测试 模板
1、概况
1.1 测试背景
简要描述与测试项目相关的一些背景资料，如项目上线计划、测试需求等。
1.2 测试目的
在大用户量、数据量的超负荷下，获得服务器运行时的相关数据，从而进行分析，查看xx服务是否符合需求。
1.3 测试范围
本次测试主要是对xx 服务的性能测试。
2. 测试工具及环境
2.1 测试环境
描述测试环境的物理架构，可以用物理架构图来展示。
2.2 基本配置
描述如何部署测试环境基于测试前需要配置的一些参数等。
测试环境
操作系统 |
网络 |
内存 |
被测服务的环境
操作系统 |
网络 |
内存 |
被测对象commit号/版本号 |
2.3 测试工具
a.压测工具：go-stress和wrk
b.监控工具：graph
3、测试内容
3.1 增加并发连接数(短链接)
# -c 表示并发数 -n 表示每个并发执行请求的次数
./go-stress-testing-mac -c 1000 -n 1000 -u https://www.baidu.com/
./go-stress-testing-mac -c 10000 -n 1000 -u https://www.baidu.com/
./go-stress-testing-mac -c 20000 -n 1000 -u https://www.baidu.com/
./go-stress-testing-mac -c 50000 -n 1000 -u https://www.baidu.com/
并发连接数 |
CPU |
||||
系统 |
进程 |
||||
用户CPU使用率 |
系统CPU使用率 |
iowait CPU使用率 |
软中断和硬中断的 CPU 使用率 |
进程CPU使用率 |
|
1000 |
|||||
10000 |
|||||
20000 |
|||||
50000 |
|||||
并发连接数 |
内存 |
|
系统使用内存 |
进程使用内存 |
|
1000 |
||
10000 |
||
20000 |
||
50000 |
||
并发连接数 |
网络 |
|||||
QPS |
吞吐率 |
请求失败率 |
请求分布延时 |
|||
p75 |
p90 |
p99 |
||||
1000 |
||||||
10000 |
||||||
20000 |
||||||
50000 |
||||||
将以上表格中的CPU、内存、网络(除请求延时绘制成条形图外)绘制成折线图。
3.2 增加连接数(长连接)
测试工具 wrk
# -c表示并发连接数1000，-t表示线程数为2，-d表示测试持续时间单位s
wrk -c 1000 -t 10 -d 600s --latency http://192.168.1.1/
wrk -c 10000 -t 100 -d 600s --latency http://192.168.1.1/
wrk -c 20000 -t 200 -d 600s --latency http://192.168.1.1/
wrk -c 50000 -t 500 -d 600s --latency http://192.168.1.1/
并发连接数 |
CPU |
||||
系统 |
进程 |
||||
用户CPU使用率 |
系统CPU使用率 |
iowait CPU使用率 |
软中断和硬中断的 CPU 使用率 |
进程CPU使用率 |
|
1000 |
|||||
10000 |
|||||
20000 |
|||||
50000 |
|||||
并发连接数 |
内存 |
|
系统使用内存 |
进程使用内存 |
|
1000 |
||
10000 |
||
20000 |
||
50000 |
||
并发连接数 |
网络 |
|||||
QPS |
吞吐率 |
请求失败率 |
请求分布延时 |
|||
p75 |
p90 |
p99 |
||||
1000 |
||||||
10000 |
||||||
20000 |
||||||
50000 |
||||||
3.3 增加机器数，压出直至服务所在服务器上的CPU能达到95%以上
压测机器数 |
网络 |
内存 |
1 |
153.165 |
|
2 |
||
... |
测试工具 wrk
# -c表示并发连接数1000，-t表示线程数为2，-d表示测试持续时间单位s
wrk -c 50000 -t 500 -d 600s --latency http://192.168.1.1/ //server-1
wrk -c 50000 -t 500 -d 600s --latency http://192.168.1.1/ //server-2
wrk -c 50000 -t 500 -d 600s --latency http://192.168.1.1/ //server-3
...
并发连接数 |
CPU |
||||
系统 |
进程 |
||||
用户CPU使用率 |
系统CPU使用率 |
iowait CPU使用率 |
软中断和硬中断的 CPU 使用率 |
进程CPU使用率 |
|
50000 |
|||||
并发连接数 |
内存 |
|
系统使用内存 |
进程使用内存 |
|
50000 |
||
并发连接数 |
网络 |
|||||
QPS |
吞吐率 |
请求失败率 |
请求分布延时 |
|||
p75 |
p90 |
p99 |
||||
50000 |
||||||
3.4 使用大文件传输，测试出吞吐率
测试工具 wrk
# -c表示并发连接数1000，-t表示线程数为2，-d表示测试持续时间单位s
wrk -c 1000 -t 100 -d 600s --latency http://192.168.1.1/
并发连接数 |
CPU |
||||
系统 |
进程 |
||||
用户CPU使用率 |
系统CPU使用率 |
iowait CPU使用率 |
软中断和硬中断的 CPU 使用率 |
进程CPU使用率 |
|
1000 |
|||||
并发连接数 |
内存 |
|
系统使用内存 |
进程使用内存 |
|
1000 |
||
并发连接数 |
网络 |
|||||
QPS |
吞吐率 |
请求失败率 |
请求分布延时 |
|||
p75 |
p90 |
p99 |
||||
1000 |
||||||
3.5 持续压测72小时，保持服务所在的服务器CPU达到百分之70，测试稳定性
压测时间 |
服务是否正常 |
4、测试结果与分析
结论：
1.当并发连接数达到最大值xx ，CPU的占用为xx％，内存占用xxM，平均延时为xxms, 请求失败率为xx%.
2.当长连接数达到最大值xx，CPU的占用为xx％，内存占用xxM，p90为xxms, 请求失败率为xx%,QPS为xx,吞吐率为xx.
3.xxx性能在CPU方面占用过多,过多的系统调用导致CPU飙升,内存占用过多,需要相应的优化.
4.给出运行服务所需要的配置参数列表