使用NetACC加速TCP应用

NetACC(Network Accelerator)是一个用户态网络加速库,利用eRDMA的低时延、高吞吐等优势,通过兼容socket接口,实现对现有TCP应用的加速。对于对网络通信性能要求高、需要低延迟和高吞吐量的TCP应用,可以通过NetACC,无需修改应用代码即可适配eRDMA,实现网络加速。

重要

NetACC当前处于公测阶段。

NetACC适用场景

NetACC适用于网络开销较大的场景:

  • 高PPS(Packets per Second)场景:尤其是大量收发小包的场景。使用NetACC可以降低CPU开销,提升系统吞吐能力,例如在Redis处理请求的场景中。

  • 对网络时延敏感的场景:eRDMA的网络时延比TCP更低,可以提升网络响应速度。

  • 反复创建短连接的场景:NetACC可以优化二次连接的速度,加快连接速度,提升系统性能。

安装NetACC

  • 安装方式

    • 通过eRDMA驱动安装

      安装eRDMA驱动的时候,NetACC也会一并安装。关于eRDMA驱动的安装,请参见为ECS实例安装eRDMA驱动

    • 单独安装

      如果您需要使用特定版本的NetACC或者您需要临时使用NetACC等,您可以在ECS实例上执行以下命令,单独安装NetACC:

      sudo curl -fsSL https://netacc-release.oss-cn-hangzhou.aliyuncs.com/release/netacc_download_install.sh | sudo sh
  • 配置文件及参数优化

    安装NetACC后默认配置文件是/etc/netacc.conf,允许用户根据需要调整参数,如消息大小NACC_SOR_MSG_SIZE、RDMA内存注册大小NACC_RDMA_MR_MIN_INC_SIZENACC_RDMA_MR_MAX_INC_SIZE、QP承载链接数NACC_SOR_CONN_PER_QP、IO线程数NACC_SOR_IO_THREADS等,以优化性能。

    配置文件示例如下:

    /etc/netacc.conf文件示例

    [netacc]
    # 一个buffer的size,一般发送数据块较大时适当调大这个参数可以提高性能;调小可以节省内存。
    # int
    NACC_SOR_MSG_SIZE=16384
    
    # rdma首次注册的mr大小,调小可以节省内存
    #   NACC_SOR_MSG_SIZE的2的N次幂倍,最小为1倍
    NACC_RDMA_MR_MIN_INC_SIZE=16384
    
    # rdma最大单次注册的mr大小(1MB ~ 512MB),调小可以节省内存
    #   NACC_RDMA_MR_MIN_INC_SIZE的2的N次幂倍,最小为1倍,最大为512M
    NACC_RDMA_MR_MAX_INC_SIZE=8388608
    
    # 单个QP承载的链接数,适当调大可以优化性能;特殊场景只能调成1
    # int
    NACC_SOR_CONN_PER_QP=1
    
    # netacc的线程数,如果吞吐较大可以适当增加
    # int
    NACC_SOR_IO_THREADS=1
    
    # 空QP淘汰时间,单位ms,0代表立即淘汰,-1代表不会淘汰
    NACC_EMPTY_QP_EXPIRE_MS=60000
    
    # 允许存在的空QP总数
    NACC_EMPTY_QP_MAX_ALL=100
    
    # 每个目的地址允许存在的空QP总数
    NACC_EMPTY_QP_MAX_PER=10
    
    # connect使用rdma建连的概率,0 ~ 100
    NACC_CONNECT_RDMA_PERCENT=100
    
    # 是否默认开启RDMA
    NACC_ENABLE_RDMA_DEFAULT=1
    
    # 日志级别
    # 0: TRACE
    # 1: DEBUG
    # 2: INFO
    # 3: WARN
    # 4: ERROR
    # 5: FATAL
    NACC_LOG_LEVEL=3
    
    # 日志路径
    NACC_LOG_PATH="/tmp/netacc.log"
    
    # 下面是不常用或者不需要设置的参数
    
    # 线程亲和性设置
    # string
    NACC_SOR_AFFINITY=""
    
    # 是否优先使用TCP创建链接
    # bool
    NACC_CONN_TCP_FIRST=0

使用NetACC

您可以通过netacc_run命令或者设置环境变量LD_PRELOAD的方式在应用中集成NetACC。使用之前,请您仔细阅读NetACC使用注意事项

netacc_run命令

netacc_run是一个工具,用于启动应用程序时加载NetACC库,通过在应用程序命令之前增加netacc_run,用户可以比较方便地启动应用程序并应用NetACC加速。

netacc_run提供了很多配置选项,比如IO线程数(-t)、QP复用数(-p)等,这些参数可以帮助优化NetACC的性能。通过netacc_run命令设置的参数会覆盖配置文件中的参数。

netacc_run命令参数说明

netacc_run -h
Usage: netacc_run [ OPTIONS ] COMMAND

Run COMMAND using NetACC for TCP sockets

OPTIONS:
   -f <path>   set config file, default /etc/netacc.conf
   -p <num>    set max connections per QP, default 1
   -t <num>    set netacc io threads, default 4
   -s <num>    set netacc message size, default 16384
   -F <num>    fast connect mode, default 0
   -d          enable debug mode
   -T          use TCP first in connect
   -P <num>    polling cq time ms
   -A <str>    affinity CPU list, 0 | 1-3 | 1,3,4
   -i <num>    set cq comp_vector, default 0
   -h          display this message
   -v          display version info
  • 使用示例:

    以本文中Redis应用为例,在Redis命令之前增加netacc_run即可实现应用NetACC。

    • 启动Redis服务

      netacc_run redis-server
    • 启动Redis基准测试

      netacc_run redis-benchmark

设置LD_PRELOAD环境变量

LD_PRELOAD是一个环境变量,用于指定在程序启动时预先加载的共享库。如果您需要在脚本中自动化NetACC的加载,您可以通过LD_PRELOAD指定NetACC加速库。

  1. 执行以下命令,查看NetACC动态库的位置:

    ldconfig -p | grep netacc

    返回信息如下所示:

    image

  2. 执行以下命令,设置LD_PRELOAD环境变量来指定预加载库:

    LD_PRELOAD=/lib64/libnetacc-preload.so your_application

    此处your_application是您想要加速的应用程序。

    使用示例:以本文中Redis应用常用命令为例:

    • 启动Redis服务

      LD_PRELOAD=/lib64/libnetacc-preload.so redis-server
    • 启动Redis基准测试

      LD_PRELOAD=/lib64/libnetacc-preload.so redis-benchmark

    在脚本中设置LD_PRELOAD环境变量

    如果您经常需要使用NetACC加速某个应用程序,或者您希望通过脚本统一管理多个应用程序在启动时候利用NetACC进行网络加速,您可以在脚本中设置LD_PRELOAD环境变量。例如,您可以创建一个名为run_with_netacc的脚本:

    #!/bin/bash
    LD_PRELOAD=/lib64/libnetacc-preload.so $@

    然后,您可以通过执行以下命令,运行应用程序:

    ./run_with_netacc.sh your_application

    使用示例:以本文中Redis应用常用命令为例:

    • 启动Redis服务

      ./run_with_netacc.sh redis-server
    • 启动Redis基准测试

      ./run_with_netacc.sh redis-benchmark

NetACC监控

netacc_ss是NetACC中自带的监控工具,您可以执行netacc_ss命令监控使用了NetACC加速的TCP应用进程收发数据的状态。在Server端和Client端均可以执行该命令进行监测。netacc_ss命令详细说明如下:

netacc_ss命令说明

netacc_ss -h
Usage:
 netacc_ss: [-p] <pid> [options]...
 Show monitoring information of specified netacc process

Options:
 -c   clear unused sock file
 -h   display this help
 -s   display specified monitoring metric[s]. [all|cfg|cnt|mem|qp|sock]
      all: all monitoring information
      cfg: configuration information
      cnt: counter information[default]
      mem: memory information
      qp : queue pair information
      sock: socket information
 -v   display netacc version

Examples:
 netacc_ss -p 12345 -s mem,cnt

执行如下命令,查看使用了NetACC加速的TCP应用进程收发数据的状态

netacc_ss -s all -p <进程ID>
说明

您可以通过执行ps -ef | grep <进程名称>命令查询进程ID。

NetACC使用注意事项

  • 使用NetACC时,只有使用支持eRDMA的网卡(IP地址)创建的连接才会被转换为RDMA连接,其他连接还是会使用TCP。

    说明

    如果网络通信的任一端的网卡不支持弹性RDMA接口,那么NetACC将无法创建RDMA连接,而是会回退到使用TCP连接。

  • 使用NetACC时,如果您需要在多个进程之间进行网络通信,您不能将RDMA的socket文件描述符(fd)通过内核的进程间通信(IPC)机制发送给其他进程。

    说明

    RDMA连接是基于特定的队列对(Queue Pair,QP)建立的,而这些QP不支持在不同进程之间直接共享,因此RDMA连接不能在进程间共享。

  • NetACC框架目前不支持IPv6协议,为了确保在使用NetACC时不出现IPv6相关的冲突或错误,建议通过执行sysctl net.ipv6.conf.all.disable_ipv6=1命令来禁用系统中的IPv6功能。

  • NetACC动态库不支持热更新,热更新可能造成不可预期的错误,更新前请先停止应用进程。

  • NetACC目前不支持TCP协议中的部分套接字选项,包括SO_REUSEPORT,SO_ZEROCOPY和TCP_INQ。

  • NetACC依赖于glibc,无法在非glibc环境下工作,比如Golang。

  • 使用NetACC前,建议您通过执行ulimit -l unlimited命令来设置进程可以锁定的物理内存的最大量为无限制。

    说明

    如果ulimit -l参数设置得过小,那么在RDMA注册内存时可能会因为超出了系统允许的内存锁定限制而失败。

  • 在NetACC中,当应用程序监听一个TCP端口以进行通信时,NetACC会为这个TCP端口额外监听一个RDMA端口(TCP端口加20000),以便在RDMA网络环境中进行高效的数据传输。

    说明

    如果RDMA端口被占用或者超过了有效端口范围,会导致无法正常建立连接。请您合理分配,以避免端口冲突。

  • 在NetACC中,当一个父进程使用fork()系统调用创建子进程后,子进程默认情况下不会继承父进程已经建立的socket连接。

    说明

    fork()后无法继承父进程创建的socket连接,可能会导致无法正常通信,需要重新建立socket连接。

  • 在NetACC中,QP复用功能默认是关闭的。

    • 您可以在NetACC的配置文件中通过NACC_SOR_CONN_PER_QP或者在运行netacc_run时候指定QP复用数(-p),配置单个QP承载的连接数大于1,即允许多个连接复用1个QP,从而开启QP复用功能。

    • 如果开启QP复用功能,因为减少了QP的数量,从而减少了管理开销和资源消耗,特别是在高并发连接的场景下,可以提升整体的通信效率。

    • 当QP复用功能开启时,多个RDMA连接可能会共享同一个本地端口号。这是因为在RDMA中,端口号是用来标识QP的,而不是用来区分连接的。如果多个连接共享同一个QP,它们也会共享同一个本地端口号。

      说明

      如果应用程序需要区分不同的本地端口号(例如,为了实现不同的服务或监听不同的端口),那么不应该开启QP复用功能。因为一旦开启,多个连接将无法通过本地端口号来区分,这可能会导致端口冲突。

Redis应用中使用NetACC

NetACC在Redis应用中的作用

  • 提升系统吞吐能力

    NetACC适用于处理每秒需要处理大量数据包的场景,在Redis处理大量请求时,可以降低CPU开销并提升系统吞吐量。

  • 提升网络响应速度

    对于需要快速网络响应的Redis应用,NetACC利用eRDMA提供的低时延特性,可以显著提升网络响应速度。

Redis性能基准测试中使用NetACC

redis-benchmark是Redis自带的一个性能测试工具,它可以模拟多个客户端同时对Redis发送请求,以此来评估Redis服务器在不同负载下的性能表现。

测试场景

redis-benchmark中使用NetACC,模拟100个clients,4个threads,循环5000000次set操作。

redis-server常用命令参数说明

redis-server是启动Redis服务器的命令。您可以在实例上执行redis-server -h查看具体参数说明,本文中用到的参数说明如下:

redis-server --port 6379 --protected-mode no
  • --port 6379:指定Redis服务的启动端口,默认不指定,为6379。

  • --protected-mode no:这个参数用来设置Redis服务器是否运行在保护模式下。保护模式是一种安全特性,当启用时,Redis只允许在本地主机(127.0.0.1 或 localhost)上进行连接,从而防止远程连接。使用no作为参数值表示禁用保护模式,允许Redis接受来自任何 IP 地址的连接。

    重要

    关闭Redis服务的保护模式,这在生产环境中可能带来安全风险,因此在开放的网络环境中使用时需要谨慎。

redis-benchmark常用命令参数说明

redis-benchmark是Redis自带的压力测试工具,用于模拟多个客户端向Redis发送大量请求,以测试Redis的性能。您可以在实例上执行redis-benchmark --help查看具体参数说明,本文中用到的参数说明如下:

redis-benchmark -h 172.17.0.90 -p 6379 -c 100 -n 5000000 -r 10000 --threads 4 -d 512 -t set
  • -h 172.17.0.90:指定Redis服务所在服务器的主机名或 IP 地址,这里是172.17.0.90

  • -p 6379:指定Redis服务的启动端口,如果使用了默认端口6379,则可以省略此配置,如果您的Redis服务启动的时候指定了其他端口,需要指定。

    说明

    您可以在Redis服务端通过sudo grep "^port" /<redis.conf文件路径>/redis.conf命令查询,Redis默认配置文件路径为/etc/redis.conf

  • -c 100:指定并发连接数,这里是100个并发连接。

  • -n 5000000:指定请求总数,这里是5000000个请求。

  • -r 10000:使用随机键的范围,这里指定了10000个不同的键的范围。这意味着测试中的SET命令将使用从0到9999的随机整数作为键的一部分。

  • --threads 4:指定线程数,这里是4个线程。redis-benchmark默认是单线程的,但某些系统可能允许使用多线程来模拟并发。

  • -d 512:指定SET命令值的数据大小,这里是512字节。

  • -t set:指定只运行set测试。-t参数后面跟的是测试命令的名称,这里只测试set命令的性能。

这个命令的意思是,使用4个线程,每个线程100个并发连接,总共发送5000000个set请求到IP地址为172.17.0.90的Redis服务器,每个请求的值是一个512字节的随机数据,并且使用的键是0到9999之间的随机整数。

redis-benchmark常用测试结果指标说明

  • 吞吐量(Throughput Summary):

    每秒请求数rps(requests per second):表示在测试期间服务器每秒能够处理的请求数量。例如332933.81 requests per second表示服务器每秒可以处理约332934个请求。

  • 延迟(Latency Summary),单位为毫秒:

    • avg:平均延迟,即所有请求的平均响应时间。

    • min:最小延迟,即所有请求中的最小响应时间。

    • p50(50th percentile,中位数):一半的请求响应时间低于这个值。

    • p95(95th percentile):95%的请求响应时间低于这个值。

    • p99(99th percentile):99%的请求响应时间低于这个值。

    • max:最大延迟,即所有请求中的最大响应时间。

准备工作

购买两台支持eRDMA的实例,勾选自动安装eRDMA驱动,并且在主网卡开启eRDMA网络接口。两台ECS实例分别作为Redis的服务端和客户端。

本示例参数如下所示:

  • 镜像:均为Alibaba Cloud Linux 3

  • 实例规格:均为ecs.g8ae.4xlarge

  • 实例主网卡的私网IP地址:Server端(172.17.0.90)、Client端(172.17.0.91)。在以下测试中,您需要根据实际情况替换IP地址。

    说明
    • 本文以在实例的主网卡上开启eRDMA网络接口为例进行测试,那么这里的172.17.0.90即Redis服务端所在ECS实例的主网卡的私网IP地址。

    • 如果您是通过辅助弹性网卡上开启eRDMA网络接口进行测试,那么这里的IP地址,需要改为您实际的辅助弹性网卡的私网IP地址。更多信息,请参见为ECS实例绑定ERI

购买过程重要参数示例

购买实例过程中需注意以下配置项(其他参数,请参见自定义购买实例):

  • 实例规格和镜像:请参见使用限制

  • 扩展程序:选中eRDMA驱动。实例启动过程中会自动安装eRDMA驱动,无需您再手动安装。您在购买Alibaba Cloud Linux操作系统的倚天实例时,还可以选择安装性能加速类扩展程序。更多信息,请参见应用性能加速

    image

  • 弹性网卡:在主网卡右侧选中弹性RDMA接口

    重要

    创建实例时,仅支持为主网卡启用弹性RDMA接口,且单台ECS实例最多只能绑定一个启用弹性RDMA接口的网卡。如果您需要使用辅助网卡配置eRDMA,只能在创建实例后,单独创建辅助弹性网卡并为其启用弹性RDMA接口,然后绑定至ECS实例上使用。具体操作,请参见创建辅助弹性网卡绑定辅助弹性网卡

    image

具体操作

  1. 分别远程连接Server端和Client端的ECS实例。

    具体操作,请参见使用Workbench工具以SSH协议登录Linux实例

  2. 确认两台ECS实例的eRDMA驱动安装完成。

    在实例启动后,您可以通过ibv_devinfo命令确认已安装完毕:

    • 如果正确安装完成后,命令返回如下所示:

      image

    • 如果尚未完成安装,命令返回如下所示(eRDMA相关驱动程序的安装可能需要几分钟,您可以稍后再尝试):

      image

  3. 在两台ECS实例上分别执行以下命令安装Redis。

    sudo yum install -y redis

    安装完成后,返回信息如下所示:

    image

  4. 通过redis-benchmark进行Redis性能的基准测试。

    使用NetACC加速测试
    1. 在Server端的ECS实例上,执行以下命令,以NetACC加速的方式启动Redis服务:

      netacc_run redis-server --port 6379 --protected-mode no
      说明

      正确启动后,返回如下所示:

      image

    2. 在Client端的ECS实例上,执行以下命令,开启Redis基准测试:

       netacc_run redis-benchmark -h 172.17.0.90 -p 6379 -c 100 -n 5000000 -r 10000 --threads 4 -d 512 -t set
      说明
      • 您需要替换对应的172.17.0.906379为您实际启动Redis服务的服务器的IP地址和端口号,详见redis-benchmark常用命令参数说明

      • 不同的网络环境下测试结果不同,本文测试数据仅供参考,具体执行结果以您的实际环境为准。

      测试结束后,返回示例内容如下

      ====== SET ======                                                      
        5000000 requests completed in 6.52 seconds
        100 parallel clients
        512 bytes payload
        keep alive: 1
        host configuration "save": 3600 1 300 100 60 10000
        host configuration "appendonly": no
        multi-thread: yes
        threads: 4
      
      Latency by percentile distribution:
      0.000% <= 0.039 milliseconds (cumulative count 3)
      50.000% <= 0.127 milliseconds (cumulative count 2677326)
      75.000% <= 0.143 milliseconds (cumulative count 3873096)
      87.500% <= 0.151 milliseconds (cumulative count 4437348)
      93.750% <= 0.159 milliseconds (cumulative count 4715347)
      96.875% <= 0.175 milliseconds (cumulative count 4890339)
      98.438% <= 0.183 milliseconds (cumulative count 4967042)
      99.609% <= 0.191 milliseconds (cumulative count 4991789)
      99.902% <= 0.207 milliseconds (cumulative count 4995847)
      99.951% <= 0.263 milliseconds (cumulative count 4997733)
      99.976% <= 0.303 milliseconds (cumulative count 4998853)
      99.988% <= 0.343 milliseconds (cumulative count 4999403)
      99.994% <= 0.367 milliseconds (cumulative count 4999704)
      99.997% <= 0.391 milliseconds (cumulative count 4999849)
      99.998% <= 2.407 milliseconds (cumulative count 4999924)
      99.999% <= 5.407 milliseconds (cumulative count 4999962)
      100.000% <= 6.847 milliseconds (cumulative count 4999981)
      100.000% <= 8.423 milliseconds (cumulative count 4999991)
      100.000% <= 8.919 milliseconds (cumulative count 4999996)
      100.000% <= 9.271 milliseconds (cumulative count 4999998)
      100.000% <= 9.471 milliseconds (cumulative count 4999999)
      100.000% <= 9.583 milliseconds (cumulative count 5000000)
      100.000% <= 9.583 milliseconds (cumulative count 5000000)
      
      Cumulative distribution of latencies:
      18.820% <= 0.103 milliseconds (cumulative count 941003)
      99.917% <= 0.207 milliseconds (cumulative count 4995847)
      99.977% <= 0.303 milliseconds (cumulative count 4998853)
      99.998% <= 0.407 milliseconds (cumulative count 4999879)
      99.998% <= 0.503 milliseconds (cumulative count 4999903)
      99.998% <= 0.703 milliseconds (cumulative count 4999904)
      99.998% <= 0.807 milliseconds (cumulative count 4999905)
      99.998% <= 0.903 milliseconds (cumulative count 4999906)
      99.998% <= 1.007 milliseconds (cumulative count 4999908)
      99.998% <= 1.103 milliseconds (cumulative count 4999909)
      99.998% <= 1.207 milliseconds (cumulative count 4999912)
      99.998% <= 1.407 milliseconds (cumulative count 4999913)
      99.998% <= 1.503 milliseconds (cumulative count 4999915)
      99.998% <= 1.607 milliseconds (cumulative count 4999916)
      99.998% <= 1.703 milliseconds (cumulative count 4999917)
      99.998% <= 1.807 milliseconds (cumulative count 4999918)
      99.998% <= 1.903 milliseconds (cumulative count 4999919)
      99.998% <= 2.103 milliseconds (cumulative count 4999920)
      99.999% <= 3.103 milliseconds (cumulative count 4999931)
      99.999% <= 4.103 milliseconds (cumulative count 4999944)
      99.999% <= 5.103 milliseconds (cumulative count 4999958)
      99.999% <= 6.103 milliseconds (cumulative count 4999971)
      100.000% <= 7.103 milliseconds (cumulative count 4999984)
      100.000% <= 8.103 milliseconds (cumulative count 4999989)
      100.000% <= 9.103 milliseconds (cumulative count 4999996)
      100.000% <= 10.103 milliseconds (cumulative count 5000000)
      
      Summary:
        throughput summary: 767341.94 requests per second
        latency summary (msec):
                avg       min       p50       p95       p99       max
              0.126     0.032     0.127     0.167     0.183     9.583

      可以看到最下面的Summary信息,最后打印的是77万左右的rps。关于指标详细说明,详见redis-benchmark常用测试结果指标说明

    测试过程中通过netacc_ss查看服务端监控

    在测试过程中,您可以在Server端的ECS实例上通过netacc_ss查看目前服务端监控信息:

    • 执行以下命令,查看目前Redis服务的进程ID:

      ps -ef | grep redis-server

      返回信息如下,可以看到redis-server的进程ID为114379:

      image

    • 执行以下命令,查看Redis服务目前的连接信息及收发数据的状态:

      netacc_ss -p 114379 -s all
      说明

      您需要将命令中的114379替换为您实际环境中Redis服务的进程的PID。详见netacc_ss命令说明

      命令返回信息如下,可以看到,由于连接两端实例的网卡均开启了弹性RDMA接口,因此建立的socket连接都是RDMA连接,最右侧4列是收发的数据量:

      image

    未使用NetACC加速测试
    1. 在Server端的ECS实例上,执行以下命令,启动Redis服务:

      redis-server --port 6379 --protected-mode no --save
      说明

      您需要替换对应的6379为您实际启动Redis服务的端口号,详见redis-server常用命令参数说明

      正确启动后,返回如下所示:

      image

    2. 在Client端的ECS实例上,执行以下命令,开启Redis基准测试:

       redis-benchmark -h 172.17.0.90 -c 100 -n 5000000 -r 10000 --threads 4 -d 512 -t set
      说明
      • 您需要替换对应的172.17.0.906379为您实际启动Redis服务的服务器的IP地址和端口号, 详见redis-benchmark常用命令参数说明

      • 不同的网络环境下测试结果不同,本文测试数据仅供参考,具体执行结果以您的实际环境为准。

      测试结束后,返回示例内容如下

      ====== SET ======                                                         
        5000000 requests completed in 15.02 seconds
        100 parallel clients
        512 bytes payload
        keep alive: 1
        host configuration "save": 
        host configuration "appendonly": no
        multi-thread: yes
        threads: 4
      
      Latency by percentile distribution:
      0.000% <= 0.055 milliseconds (cumulative count 27)
      50.000% <= 0.287 milliseconds (cumulative count 2635010)
      75.000% <= 0.335 milliseconds (cumulative count 3782931)
      87.500% <= 0.367 milliseconds (cumulative count 4459136)
      93.750% <= 0.391 milliseconds (cumulative count 4720397)
      96.875% <= 0.415 milliseconds (cumulative count 4855130)
      98.438% <= 0.439 milliseconds (cumulative count 4936478)
      99.219% <= 0.455 milliseconds (cumulative count 4965765)
      99.609% <= 0.471 milliseconds (cumulative count 4984031)
      99.805% <= 0.487 milliseconds (cumulative count 4993326)
      99.902% <= 0.495 milliseconds (cumulative count 4995579)
      99.951% <= 0.511 milliseconds (cumulative count 4997659)
      99.976% <= 0.551 milliseconds (cumulative count 4998848)
      99.988% <= 0.599 milliseconds (cumulative count 4999468)
      99.994% <= 0.631 milliseconds (cumulative count 4999722)
      99.997% <= 0.663 milliseconds (cumulative count 4999862)
      99.998% <= 0.695 milliseconds (cumulative count 4999924)
      99.999% <= 0.759 milliseconds (cumulative count 4999964)
      100.000% <= 0.807 milliseconds (cumulative count 4999982)
      100.000% <= 1.935 milliseconds (cumulative count 4999993)
      100.000% <= 2.071 milliseconds (cumulative count 4999996)
      100.000% <= 2.111 milliseconds (cumulative count 4999998)
      100.000% <= 2.119 milliseconds (cumulative count 4999999)
      100.000% <= 2.143 milliseconds (cumulative count 5000000)
      100.000% <= 2.143 milliseconds (cumulative count 5000000)
      
      Cumulative distribution of latencies:
      0.028% <= 0.103 milliseconds (cumulative count 1377)
      0.985% <= 0.207 milliseconds (cumulative count 49228)
      60.094% <= 0.303 milliseconds (cumulative count 3004705)
      96.325% <= 0.407 milliseconds (cumulative count 4816230)
      99.938% <= 0.503 milliseconds (cumulative count 4996887)
      99.991% <= 0.607 milliseconds (cumulative count 4999546)
      99.999% <= 0.703 milliseconds (cumulative count 4999927)
      100.000% <= 0.807 milliseconds (cumulative count 4999982)
      100.000% <= 0.903 milliseconds (cumulative count 4999987)
      100.000% <= 1.903 milliseconds (cumulative count 4999990)
      100.000% <= 2.007 milliseconds (cumulative count 4999995)
      100.000% <= 2.103 milliseconds (cumulative count 4999997)
      100.000% <= 3.103 milliseconds (cumulative count 5000000)
      
      Summary:
        throughput summary: 332955.97 requests per second
        latency summary (msec):
                avg       min       p50       p95       p99       max
              0.292     0.048     0.287     0.399     0.447     2.143

      可以看到最下面的Summary信息,最后打印的是33万左右的rps。关于指标详细说明,详见redis-benchmark常用测试结果指标说明