AB压测工具可以用来对Web服务镜像压力测试，模拟并发请求对被压测系统执行压力测试，并且输出多想性能测试指标结果值，本文使用该工具对k8s集群中的nginx Pod进行压力测试。

服务压测拓扑：

创建nginx工作负载，工作负载的yaml文件示例为：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: liusu-nginx
  labels:
    app: liusu-nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: liusu-nginx
  template:
    metadata:
      labels:
        app: liusu-nginx
    spec:
      nodeSelector:
        kubernetes.io/app: test
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: kubernetes.io/hostname
          whenUnsatisfiable: ScheduleAnyway
          labelSelector:
            matchLabels:
              app: liusu-nginx
      containers:
      - name: liusu-nginx
        image: docker.io/library/nginx:1.20.2

创建一个服务service关联到这个nginx工作负载上，服务的yaml文件示例为：

kind: Service
apiVersion: v1
metadata:
  name: liusu-service
  namespace: default
  labels:
    app: liusu-service
spec:
  ports:
    - name: http-0
      protocol: TCP
      port: 80
      targetPort: 80
  selector:
    app: liusu-nginx
  type: ClusterIP

在测试节点上安装 ab 测试工具：

使用方法：

ab [选项] http://hostname:port/path

选项解释：

-n requests 在测试会话中所执行的请求总个数，默认一个
-c concurrency 一次产生的请求个数，默认一个

执行压测命令示例：

ab -c 1 -n 1 http://10.96.123.181:80/

如下所示为执行了一次压测的输出结果，下面对该输出结果进行解释说明：

[root@gz15-ct4-az1-compute-s7-10e63e0e245 ~]# ab -c 100 -n 100000 http://10.96.123.181:80/
This is ApacheBench, Version 2.3 <$Revision: 1874286 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 10.96.123.181 (be patient)
Completed 10000 requests
Completed 20000 requests
Completed 30000 requests
Completed 40000 requests
Completed 50000 requests
Completed 60000 requests
Completed 70000 requests
Completed 80000 requests
Completed 90000 requests
Completed 100000 requests
Finished 100000 requests


Server Software:        nginx/1.20.2
Server Hostname:        10.96.123.181
Server Port:            80

Document Path:          /
Document Length:        612 bytes

Concurrency Level:      100
Time taken for tests:   2.683 seconds
Complete requests:      100000
Failed requests:        0
Total transferred:      84500000 bytes
HTML transferred:       61200000 bytes
Requests per second:    37277.66 [#/sec] (mean)
Time per request:       2.683 [ms] (mean)
Time per request:       0.027 [ms] (mean, across all concurrent requests)
Transfer rate:          30761.35 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    1   0.2      1       3
Processing:     0    2   0.3      2       4
Waiting:        0    1   0.3      1       3
Total:          1    3   0.3      3       5

Percentage of the requests served within a certain time (ms)
  50%      3
  66%      3
  75%      3
  80%      3
  90%      3
  95%      3
  98%      3
  99%      4
 100%      5 (longest request)

• 命令：ab -c 100 -n 100000 http://10.96.123.181:80/代表模拟100个并发对地址http://10.96.123.181:80/发起总计100000次请求

• Document Path：请求的具体文件

• Document Length：请求的具体文件的大小

• Concurrency Level：并发级别即并发数，请求中的-c参数指定的值

• Time taken for tests：本次测试总共花费的时间

• Complete requests：本次测试总共发起的请求数量

• Failed requests：失败的请求数量。因网络原因或者服务器性能原因，发起的请求不一定全部成功，通过该数值和Complete requests相除可以计算请求的失败率，作为测试结果的重要参考

• Total transferred：总共传输的数据量，指的是ab从被测试服务器接收的总数据量，包括index.html的文本内容和请求头信息

• HTML transferred：从服务器接收到的index.html文件的总大小，等于Document Length * Complete requests

• Requests per second：平均每秒完成的请求数：QPS，这是一个平均值，等于Complete requests / Time taken for tests

• Time per request: 2.683 [ms] (mean)：从用户角度看，完成一个请求所需要的时间，因用户数量不止一个，服务器完成10个请求，平均每个用户才接收到一个完整的返回，所以该值是下一项数值的10倍

• Time per request: 0.027 [ms] (mean, across all concurrent requests)：服务器完成一个请求的时间

• Transfer rate：网络传输速度。对于大文件的请求测试，这个值很容易成为系统瓶颈所在。要确定该值是不是瓶颈，需要了解客户端和被测服务器之间的网络情况，包括网络带宽和网卡速度等信息

• Connection Times (ms)：这几行组成的表格主要是针对响应时间也就是第一个Time per request进行细分和统计。一个请求的响应时间可以分成网络链接Connect，系统处理Processing和等待Waiting三个部分。表中min表示最小值； mean表示平均值；[+/-sd]表示标准差Standard Deviation），也称均方差mean square error，这个概念在中学的数学课上学过，表示数据的离散程度，数值越大表示数据越分散，系统响应时间越不稳定。 median表示中位数； max当然就是表示最大值了。需要注意的是表中的Total并不等于前三行数据相加，因为前三行的数据并不是在同一个请求中采集到的，可能某个请求的网络延迟最短，但是系统处理时间又是最长的呢。所以Total是从整个请求所需要的时间的角度来统计的。这里可以看到最慢的一个请求花费了5ms，这个数据可以在下面的表中得到验证

• Percentage of the requests served within a certain time (ms)：这个表第一行表示有50%的请求都是在3ms内完成的，可以看到这个值是比较接近平均系统响应时间：第一个Time per request。以此类推，90%的请求是小于等于3ms的。刚才我们看到响应时间最长的那个请求是5ms，那么显然所有请求100%的时间都是小于等于5毫秒的，也就是表中最后一行的数据肯定是时间最长的那个请求longest request

测试结果：

• Pod副本数1

• Pod副本数10