Skip to content

应用或组件基准测试

基于 xxl-job 分片广播特性实施分布式测试

注意:方案太不专业,使用 wrk+OpenResty 反向代理多个 SpringBoot 应用的方式。

详细用法请参考本站 示例

基准测试单个 SpringBoot 应用

基准测试单个 SpringBoot 应用在 4C4G 内存的 JVM 中的性能如何。

测试条件

宿主机:

  • VMware ESXi, 7.0.3, 20328353
  • CPU 类型 Intel(R) Xeon(R) Platinum 8269CY CPU @ 2.50GHz
  • 网卡类型 Intel(R) Ethernet Controller X540-AT2 with 1 Gbit/s

运行 SpringBoot 应用的实例:

  • CentOS Stream release 8
  • 4C4G

压力主机:

  • CentOS Stream release 8
  • CPU 和内存资源充足

测试过程

在被压力测试实例中部署基于容器的单个 SpringBoot 基准测试目标:参考 链接

在压力测试实例(CentOS8 操作系统)中:

  • 配置 wrk:参考 链接

  • 运行 wrk:

    bash
    wrk -t8 -c4096 -d60s --latency --timeout 30 http://192.168.1.188:8080/

测试过程中通过 htop 命令查看被测试的基准测试主机和压力主机 CPU、内存、网络等资源是否充足。

bash
yum install htop -y
yum install aha -y

# 或者输出 htop 结果到文件中
echo q | htop | aha --black --line-fix > htop.html

测试结果

结论:

  • wrk 使用较少的 cpu 资源即可产生很高的压力。

压力主机 htop 结果

bash
                                                                                
    0[                    0.0%]  3[||||||||||||       50.0%]   5[                    0.0%]  8[0.0%]
    1[||||||||           33.3%]  4[||||||||           33.3%]   6[||||||||||||       50.0%]  9[||||||||||||||||||100.0%]
    2[                    0.0%]                                7[                    0.0%]
  Mem[||||||||||||                               763M/9.74G] Tasks: 90, 152 thr, 255 kthr; 10 running
  Swp[                                             0K/4.93G] Load average: 0.80 0.47 0.40 
                                                             Uptime: 05:12:54    
  [Main] [I/O]                                                                   
    PID USER       PRI  NI  VIRT   RES   SHR S  CPU%▽MEM%   TIME+  Command    
   5923 root        20   0  937M 55824  3280 S  45.5  0.5  0:18.93 wrk -t8 -c4096 -d60s --latency --timeout 30 http://192

被基准测试的主机 htop 结果

bash
                                                                                
    0[||||||||||||||||||||||||||||||||||||||||||100.0%] Tasks: 91, 694 thr, 207 kthr; 4 running
    1[||||||||||||||||||||||||||||||||||||||||||100.0%] Load average: 5.55 3.71 3.27 
    2[||||||||||||||||||||||||||||||||||||||||||100.0%] Uptime: 00:37:27         
    3[||||||||||||||||||||||||||||||||||||||||||100.0%]                          
  Mem[||||||||||||||||||||||||             2.40G/7.77G]                          
  Swp[                                        0K/4.93G]                          
  [Main] [I/O]                                                                   
    PID USER       PRI  NI  VIRT   RES   SHR S  CPU%▽MEM%   TIME+  Command    
   2039 root        20   0 8273M 1751M 27728 S 150.0 22.0 48:25.39 java -Xmx4g -jar /usr/share/demo.jar --sprin

wrk 测试结果

bash
$ wrk -t8 -c4096 -d60s --latency --timeout 30 http://192.168.1.188:8080/
Running 1m test @ http://192.168.1.188:8080/
  8 threads and 4096 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   128.15ms  302.69ms   3.54s    94.33%
    Req/Sec     7.91k   650.69     9.53k    76.64%
  Latency Distribution
     50%   58.91ms
     75%   64.90ms
     90%   75.95ms
     99%    1.78s 
  3776123 requests in 1.00m, 741.85MB read
Requests/sec:  62869.91
Transfer/sec:     12.35MB

基准测试同一台主机内两个 SpringBoot 应用

基准测试两个 SpringBoot 应用在同一台 32核 16G 内存的主机中是否更加充分利用 CPU 资源。

测试过程

编译 SpringBoot 基准测试协助项目 https://gitee.com/dexterleslie/demonstration/tree/master/demo-benchmark/demo-spring-boot-benchmark

注意:编写此项目需要使用 JDK17

bash
./mvnw package -Dmaven.test.skip=true

在被测试的基准测试主机(CentOS8 操作系统)中运行 SpringBoot 基准测试项目

  • 安装 JDK17

  • 运行 jar

    bash
    # 运行第一个 SpringBoot 应用
    java -Xmx2g -jar demo.jar
    
    # 运行第二个 SpringBoot 应用
    java -Xmx2g -Dserver.port=8081 -jar demo.jar

在压力主机(CentOS8 操作系统)中运行 wrk

bash
# 压力测试第一个 SpringBoot 应用
wrk -t8 -c512 -d60s --latency http://192.168.1.185:8080/

# 压力测试第二个 SpringBoot 应用
wrk -t8 -c512 -d60s --latency http://192.168.1.185:8081/

测试过程中通过 htop 命令查看被测试的基准测试主机和压力主机 CPU、内存、网络等资源是否充足。

bash
yum install htop -y

# 或者输出 htop 结果到文件中
echo q | htop | aha --black --line-fix > htop.html

测试结果

结论:

  • 两个应用能够更加充分利用 32核 CPU

压力主机 htop 结果

bash
                                                                                
    0[||||||||||||||||||||||||||||||||||||||||||||||||                                          50.0%]   4[||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||100.0%]
    1[||||||||||||||||||||||||||||||||||||||||||||||||                                          50.0%]   5[||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||100.0%]
    2[||||||||||||||||||||||||||||||||||||||||||||||||                                          50.0%]   6[||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||66.7%]
    3[||||||||||||||||||||||||||||||||||||||||||||||||                                          50.0%]   7[||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||100.0%]
  Mem[||||||||||||||||||||||||||||                                                         764M/5.80G] Tasks: 103, 157 thr, 239 kthr; 8 running
  Swp[                                                                                       0K/4.93G] Load average: 2.87 1.41 0.60 
                                                                                                       Uptime: 1 day, 11:11:57
  [Main] [I/O]                                                                   
    PID USER       PRI  NI  VIRT   RES   SHR S  CPU%▽MEM%   TIME+  Command    
  23136 root        20   0  690M  8416  3236 S  42.1  0.1  0:46.77 wrk -t8 -c512 -d60s --latency http://192.168.1.185:8080/
  23145 root        20   0  690M  8416  3236 S  42.1  0.1  0:37.95 wrk -t8 -c512 -d60s --latency http://192.168.1.185:8081/

被基准测试的主机 htop 结果

bash
                                                                                
    0[|||||||||||||| 66.7%]  4[|||||||||||||| 66.7%]  8[|||||||        33.3%] 12[|||||||||||||||75.0%]  16[|||||          25.0%]  20[||||||||||     50.0%] 24[||||||||||     50.0%] 28[||||||||||     50.0%]
    1[|||||||        33.3%]  5[|||||||||||||||75.0%]  9[|||||||        33.3%] 13[|||||||        33.3%]  17[|||||||        33.3%]  21[|||||||||||||||75.0%] 25[|||||||||||||| 66.7%] 29[||||||||||||   60.0%]
    2[                0.0%]  6[||||||||||     50.0%] 10[|||||          25.0%] 14[|||||          25.0%]  18[|||||||||||||||80.0%]  22[||||||||||     50.0%] 26[|||||||||||||| 66.7%] 30[|||||||        33.3%]
    3[|||||||        33.3%]  7[|||||||||||||| 66.7%] 11[|||||||        33.3%] 15[|||||||||||||| 66.7%]  19[|||||||||||||| 66.7%]  23[|||||||        33.3%] 27[||||||||||     50.0%] 31[|||||||        33.3%]
  Mem[|||||||||||||||||||||||||                                                           2.57G/15.6G] Tasks: 105, 699 thr, 438 kthr; 17 running
  Swp[                                                                                       0K/4.93G] Load average: 10.16 4.89 2.14 
                                                                                                       Uptime: 10:39:37
  [Main] [I/O]                                                                   
    PID USER       PRI  NI  VIRT   RES   SHR S  CPU%▽MEM%   TIME+  Command    
  10790 root        20   0 20.5G  770M 23116 S 342.9  4.8 11:28.73 java -Xmx2g -Dserver.port=8081 -jar demo.jar
   4210 root        20   0 20.5G  914M 22972 S 285.7  5.7 45:22.65 java -Xmx2g -jar demo.jar
  10980 root        20   0 20.5G  914M 22972 S  57.1  5.7  0:03.70 java -Xmx2g -jar demo.jar          
   4278 root        20   0 20.5G  914M 22972 R  28.6  5.7  3:09.40 java -Xmx2g -jar demo.jar
   9963 root        20   0 20.5G  914M 22972 S  28.6  5.7  0:08.71 java -Xmx2g -jar demo.jar
  10858 root        20   0 20.5G  770M 23116 S  28.6  4.8  0:52.63 java -Xmx2g -Dserver.port=8081 -jar demo.jar
  10916 root        20   0 20.5G  914M 22972 S  28.6  5.7  0:03.46 java -Xmx2g -jar demo.jar
  10932 root        20   0 20.5G  914M 22972 S  28.6  5.7  0:03.65 java -Xmx2g -jar demo.jar
  10934 root        20   0 20.5G  914M 22972 S  28.6  5.7  0:03.43 java -Xmx2g -jar demo.jar
  10958 root        20   0 20.5G  914M 22972 S  28.6  5.7  0:03.59 java -Xmx2g -jar demo.jar
  10964 root        20   0 20.5G  914M 22972 S  28.6  5.7  0:03.41 java -Xmx2g -jar demo.jar
  10988 root        20   0 20.5G  914M 22972 S  28.6  5.7  0:03.55 java -Xmx2g -jar demo.jar
  10991 root        20   0 20.5G  914M 22972 S  28.6  5.7  0:03.63 java -Xmx2g -jar demo.jar
  11029 root        20   0 20.5G  914M 22972 S  28.6  5.7  0:03.72 java -Xmx2g -jar demo.jar
  11034 root        20   0 20.5G  914M 22972 S  28.6  5.7  0:03.47 java -Xmx2g -jar demo.jar
  11071 root        20   0 20.5G  770M 23116 S  28.6  4.8  0:02.87 java -Xmx2g -Dserver.port=8081 -jar demo.jar
  11095 root        20   0 20.5G  770M 23116 S  28.6  4.8  0:03.09 java -Xmx2g -Dserver.port=8081 -jar demo.jar
  11112 root        20   0 20.5G  770M 23116 S  28.6  4.8  0:03.00 java -Xmx2g -Dserver.port=8081 -jar demo.jar
  11115 root        20   0 20.5G  770M 23116 S  28.6  4.8  0:02.91 java -Xmx2g -Dserver.port=8081 -jar demo.jar
  11132 root        20   0 20.5G  770M 23116 S  28.6  4.8  0:03.04 java -Xmx2g -Dserver.port=8081 -jar demo.jar
  11141 root        20   0 20.5G  770M 23116 S  28.6  4.8  0:03.06 java -Xmx2g -Dserver.port=8081 -jar demo.jar
  11167 root        20   0 20.5G  770M 23116 S  28.6  4.8  0:02.93 java -Xmx2g -Dserver.port=8081 -jar demo.jar
  11177 root        20   0 20.5G  770M 23116 S  28.6  4.8  0:03.01 java -Xmx2g -Dserver.port=8081 -jar demo.jar
  11209 root        20   0 20.5G  770M 23116 S  28.6  4.8  0:02.97 java -Xmx2g -Dserver.port=8081 -jar demo.jar
  11210 root        20   0 20.5G  770M 23116 S  28.6  4.8  0:02.89 java -Xmx2g -Dserver.port=8081 -jar demo.jar

wrk 测试结果

bash
[root@localhost sysbench-tpcc]# wrk -t8 -c512 -d60s --latency http://192.168.1.185:8081/
Running 1m test @ http://192.168.1.185:8081/
  8 threads and 512 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     5.26ms    1.89ms  42.64ms   75.78%
    Req/Sec    12.27k     2.23k   60.76k    86.13%
  Latency Distribution
     50%    4.94ms
     75%    6.12ms
     90%    7.57ms
     99%   11.41ms
  5864801 requests in 1.00m, 1.15GB read
Requests/sec:  97588.02
Transfer/sec:     19.65MB

[root@localhost ~]# wrk -t8 -c512 -d60s --latency http://192.168.1.185:8080/
Running 1m test @ http://192.168.1.185:8080/
  8 threads and 512 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     4.77ms    1.72ms  35.36ms   76.79%
    Req/Sec    13.53k     2.06k   31.17k    81.21%
  Latency Distribution
     50%    4.45ms
     75%    5.52ms
     90%    6.83ms
     99%   10.65ms
  6463536 requests in 1.00m, 1.27GB read
Requests/sec: 107548.44
Transfer/sec:     21.66MB

基准测试单个 OpenResty

测试条件

宿主机:

  • VMware ESXi, 7.0.3, 20328353
  • CPU 类型 Intel(R) Xeon(R) Platinum 8269CY CPU @ 2.50GHz
  • 网卡类型 Intel(R) Ethernet Controller X540-AT2 with 1 Gbit/s

被基准测试 OpenResty 主机:

  • CentOS Stream release 8
  • 4C4G

压力主机:

  • CentOS Stream release 8
  • CPU 和内存资源充足

测试过程

参考 链接 部署基准测试目标

在压力主机(CentOS8 操作系统)中运行 wrk

bash
 wrk -t8 -c8192 -d60s --latency --timeout 30 http://192.168.1.185/

wrk 测试结果

bash
$ wrk -t8 -c8192 -d60s --latency --timeout 30 http://192.168.1.185/
Running 1m test @ http://192.168.1.185/
  8 threads and 8192 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     4.12ms    5.07ms 238.66ms   87.65%
    Req/Sec    10.62k     1.65k   16.90k    75.47%
  Latency Distribution
     50%    2.15ms
     75%    5.04ms
     90%   10.58ms
     99%   19.31ms
  10156724 requests in 1.00m, 2.78GB read
Requests/sec: 168997.62
Transfer/sec:     47.38MB

测试结果

结论:

  • 未经过优化单机的 OpenResty 并发能力达到 168997 QPS。
  • OpenResty 会自动充分利用多核 CPU 资源。

基准测试 OpenResty 反向代理多个 OpenResty

测试条件

宿主机:

  • VMware ESXi, 7.0.3, 20328353
  • CPU 类型 Intel(R) Xeon(R) Platinum 8269CY CPU @ 2.50GHz
  • 网卡类型 Intel(R) Ethernet Controller X540-AT2 with 1 Gbit/s

一台反向代理 OpenResty Master 主机:

  • CentOS Stream release 8
  • 12C4G

三台被反向代理 OpenResty Slave 主机:

  • CentOS Stream release 8
  • 4C4G

压力主机:

  • CentOS Stream release 8
  • CPU 和内存资源充足

测试过程

内核参数文件描述符限制调优(在所有主机中):参考 链接

在反向代理 OpenResty Master 主机中使用 docker compose 运行 示例

  • 修改 nginx.conf

    upstream backend {
        # server 192.168.1.x:80;
        server 192.168.1.188;
        server 192.168.1.189;
        server 192.168.1.191;
    }
    • server 192.168.1.x 分别为三台被反向代理 OpenResty Slave 主机
  • 启动 OpenResty Master

    bash
    docker compose up -d

在三台被反向代理 OpenResty Slave 主机中使用 docker compose 运行 示例

bash
docker compose up -d

测试单台 Slave QPS

在压力主机中运行 wrk

bash
$ wrk -t8 -c8192 -d15s --latency --timeout 30 http://192.168.1.187
Running 15s test @ http://192.168.1.187
  8 threads and 8192 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   116.76ms  606.26ms   8.07s    97.05%
    Req/Sec    23.11k     5.69k   44.32k    74.08%
  Latency Distribution
     50%   25.75ms
     75%   29.38ms
     90%   33.01ms
     99%    3.45s 
  2759171 requests in 15.09s, 773.62MB read
Requests/sec: 182870.02
Transfer/sec:     51.27MB

测试 Master 整体 QPS

在压力主机中运行 wrk

bash
wrk -t8 -c8192 -d15s --latency --timeout 30 http://192.168.1.185
Running 15s test @ http://192.168.1.185
  8 threads and 8192 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    34.02ms   90.68ms   3.10s    98.36%
    Req/Sec    40.47k     2.88k   48.32k    80.23%
  Latency Distribution
     50%   23.84ms
     75%   29.43ms
     90%   33.95ms
     99%  414.70ms
  4828907 requests in 15.09s, 1.43GB read
Requests/sec: 319997.55
Transfer/sec:     96.74MB

测试结果

结论:

  • 单台反向代理主机 OpenResty Master CPU 等配置需要很高才能够拖动并发挥出其它三台被反响代理的 OpenResty Slave 主机。
  • 单台反向代理主机 OpenResty Master 代理三台被反向代理的 OpenResty Slave 主机总体 QPS 还不如单独一台 OpenResty Master Standalone QPS 性能。

基准测试 OpenResty 反向代理多个 SpringBoot 应用(纵向扩展 scale-up)

测试条件

宿主机:

  • VMware ESXi, 7.0.3, 20328353
  • CPU 类型 Intel(R) Xeon(R) Platinum 8269CY CPU @ 2.50GHz
  • 网卡类型 Intel(R) Ethernet Controller X540-AT2 with 1 Gbit/s

用于 scale-up 的主机:

  • CentOS Stream release 8
  • 32C16G

压力主机:

  • CentOS Stream release 8
  • CPU 和内存资源充足

测试过程

内核参数文件描述符限制调优(在所有主机中):参考 链接

制作 SpringBoot 应用容器镜像作为基准测试目标:参考 链接

在 scale-up 主机中运行 https://gitee.com/dexterleslie/demonstration/tree/master/demo-benchmark/demo-openresty-reverseproxy-springboot-scale-up

bash
docker compose up -d

未扩展 SpringBoot 服务的实例数量前,在压力主机中执行测试

bash
$ wrk -t8 -c8192 -d15s --latency --timeout 30 http://192.168.1.185/
Running 15s test @ http://192.168.1.185/
  8 threads and 8192 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   110.28ms   58.23ms   1.83s    98.74%
    Req/Sec     9.36k     0.96k   13.11k    74.15%
  Latency Distribution
     50%  107.10ms
     75%  113.00ms
     90%  119.47ms
     99%  138.88ms
  1116802 requests in 15.08s, 295.02MB read
Requests/sec:  74065.48
Transfer/sec:     19.57MB

扩展 SpringBoot 服务的实例数量

bash
docker compose up -d --scale springboot=3

# 重启 OpenResty 服务,否则无法使用扩展后新的 SpringBoot 服务实例
docker compose restart openresty

在压力主机中执行测试

bash
$ wrk -t8 -c8192 -d15s --latency --timeout 30 http://192.168.1.185/
Running 15s test @ http://192.168.1.185/
  8 threads and 8192 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    58.13ms   23.35ms 296.79ms   80.96%
    Req/Sec    17.70k     1.84k   23.17k    67.50%
  Latency Distribution
     50%   51.32ms
     75%   61.77ms
     90%  104.36ms
     99%  125.24ms
  2113510 requests in 15.09s, 558.32MB read
Requests/sec: 140036.24
Transfer/sec:     36.99MB

测试结果

结论:

  • 增加 SpringBoot 服务实例模拟 scale-up 会增加 QPS,但是不是和增加实例的倍数对应。

基准测试 OpenResty 反向代理多个 SpringBoot 应用(横向扩展 scale-out)

测试条件

宿主机:

  • VMware ESXi, 7.0.3, 20328353
  • CPU 类型 Intel(R) Xeon(R) Platinum 8269CY CPU @ 2.50GHz
  • 网卡类型 Intel(R) Ethernet Controller X540-AT2 with 1 Gbit/s

运行 OpenResty 反向代理 Master 的主机:

  • CentOS Stream release 8
  • 8C8G

三台运行 SpringBoot 应用的主机:

  • CentOS Stream release 8
  • 4C4G JVM

压力主机:

  • CentOS Stream release 8
  • CPU 和内存资源充足

测试过程

分别对 OpenResty 主机和 SpringBoot 应用的主机内核参数文件描述符限制调优:参考 链接

制作 SpringBoot 应用容器镜像作为基准测试目标:参考 链接

在 OpenResty 主机中运行 https://gitee.com/dexterleslie/demonstration/tree/master/demo-benchmark/demo-openresty-reverseproxy-benchmark-master

  • 修改 nginx.conf

    upstream backend {
        # server 192.168.1.x:80;
        server 192.168.1.187:8080;
        server 192.168.1.188:8080;
        server 192.168.1.191:8080;
    }
    • server 192.168.1.x 分别为三台被反向代理 SpringBoot 应用主机
  • 启动 OpenResty Master

    bash
    docker compose up -d

三台 SpringBoot 应用主机分别运行 https://gitee.com/dexterleslie/demonstration/tree/master/demo-benchmark/demo-openresty-reverseproxy-springboot-scale-out

bash
docker compose up -d

在压力主机配置 wrk:参考 链接

测试单台 SpringBoot 应用 QPS

在压力主机中执行测试

bash
$ wrk -t8 -c8192 -d15s --latency --timeout 30 http://192.168.1.187:8080/
Running 15s test @ http://192.168.1.187:8080/
  8 threads and 8192 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   167.99ms  594.83ms   7.74s    97.24%
    Req/Sec     8.75k     1.64k   12.94k    64.58%
  Latency Distribution
     50%   85.04ms
     75%   92.67ms
     90%  100.70ms
     99%    3.44s 
  1045267 requests in 15.07s, 210.34MB read
Requests/sec:  69378.82
Transfer/sec:     13.96MB

测试整体 QPS

bash
$ wrk -t8 -c8192 -d15s --latency --timeout 30 http://192.168.1.185/
Running 15s test @ http://192.168.1.185/
  8 threads and 8192 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    59.62ms  153.30ms   3.51s    98.37%
    Req/Sec    20.49k     3.50k   37.48k    83.08%
  Latency Distribution
     50%   43.82ms
     75%   52.90ms
     90%   62.22ms
     99%  543.80ms
  2445704 requests in 15.10s, 646.08MB read
Requests/sec: 162011.11
Transfer/sec:     42.80MB

测试结果

结论:

  • 添加更多的 SpringBoot 应用节点总体 QPS 不是线性增长的。
  • SpringBoot 应用节点增加到 5 个时,QPS 不能继续增长,OpenResty 反向代理机添加更多 CPU 也不能提升总体 QPS,应该是单机 OpenResty 反向代理性能达到极限。