一、 FIO简介

FIO 是一个多线程IO生成工具，可以生成多种IO模式（随机、顺序、读、写四大类），用来测试磁盘设备的性能。GFIO是FIO的图形监测工具，它提供了图形界面的参数配置，和性能监测图像。

在github上的链接为 https://github.com/axboe/fio

二、 FIO安装

1. yum安装

yum -y install fio.x86_64

2. 源码安装

yum -y install libaio* gcc wget make
  • 安装gfio：基于gdk实现，是其图形界面版（可选）
yum -y install libgtk2.0-dev
  • 解压FIO压缩包，进入FIO目录编译安装


  1. 

    

    

    

    ./configure --enable-gfio #如果希望不支持gfio，只需去掉后面的--enable-gfio参数
    

    2. 

  2. 

    

    

    

    make
    

    3. 

  3. 

    

    

    

    make install
  • 设置环境变量


  1. 

    

    

    

    vi .bash_profile
    

    2. 

  2. 

    

    

    

     
    

    3. 

  3. 

    

    

    

    PATH=$PATH:$HOME/bin:/usr/local/bin
    

    4. 

  4. 

    

    

    

     
    

    5. 

  5. 

    

    

    

    source .bash_profile

三、 常用参数



  1. 

    

    

    

    filename=/dev/emcpowerb　支持文件系统或者裸设备，-filename=/dev/sda2或-filename=/dev/sdb
    

    2. 

  2. 

    

    

    

    direct=1                 测试过程绕过机器自带的buffer，使测试结果更真实
    

    3. 

  3. 

    

    

    

    rw=randwread             测试随机读的I/O
    

    4. 

  4. 

    

    

    

    rw=randwrite             测试随机写的I/O
    

    5. 

  5. 

    

    

    

    rw=randrw                测试随机混合写和读的I/O
    

    6. 

  6. 

    

    

    

    rw=read                  测试顺序读的I/O
    

    7. 

  7. 

    

    

    

    rw=write                 测试顺序写的I/O
    

    8. 

  8. 

    

    

    

    rw=rw                    测试顺序混合写和读的I/O
    

    9. 

  9. 

    

    

    

    bs=4k                    单次io的块文件大小为4k
    

    10. 

  10. 

    

    

    

    bsrange=512-2048         同上，提定数据块的大小范围
    

    11. 

  11. 

    

    

    

    size=5g                  本次的测试文件大小为5g，以每次4k的io进行测试
    

    12. 

  12. 

    

    

    

    numjobs=30               本次的测试线程为30
    

    13. 

  13. 

    

    

    

    runtime=1000             测试时间为1000秒，如果不写则一直将5g文件分4k每次写完为止
    

    14. 

  14. 

    

    

    

    ioengine=psync           io引擎使用pync方式，如果要使用libaio引擎，需要yum install libaio-devel包
    

    15. 

  15. 

    

    

    

    rwmixwrite=30            在混合读写的模式下，写占30%
    

    16. 

  16. 

    

    

    

    group_reporting          关于显示结果的，汇总每个进程的信息
    

    17. 

  17. 

    

    

    

    此外
    

    18. 

  18. 

    

    

    

    lockmem=1g               只使用1g内存进行测试
    

    19. 

  19. 

    

    

    

    zero_buffers             用0初始化系统buffer
    

    20. 

  20. 

    

    

    

    nrfiles=8                每个进程生成文件的数量

四、 常用测试场景

1. 命令行测试

  • 100%随机，100%读，4K
fio -filename=/dev/emcpowerb -direct=1 -iodepth 1 -thread -rw=randread -ioengine=psync -bs=4k -size=1000G -numjobs=50 -runtime=180 -group_reporting -name=rand_100read_4k
  • 100%随机，100%写，4K
fio -filename=/dev/emcpowerb -direct=1 -iodepth 1 -thread -rw=randwrite -ioengine=psync -bs=4k -size=1000G -numjobs=50 -runtime=180 -group_reporting -name=rand_100write_4k
  • 100%顺序，100%读，4K
fio -filename=/dev/emcpowerb -direct=1 -iodepth 1 -thread -rw=read -ioengine=psync -bs=4k -size=1000G -numjobs=50 -runtime=180 -group_reporting -name=sqe_100read_4k
  • 100%顺序，100%写，4K
fio -filename=/dev/emcpowerb -direct=1 -iodepth 1 -thread -rw=write -ioengine=psync -bs=4k -size=1000G -numjobs=50 -runtime=180 -group_reporting -name=sqe_100write_4k
  • 100%随机，70%读，30%写 4K
fio -filename=/dev/emcpowerb -direct=1 -iodepth 1 -thread -rw=randrw -rwmixread=70 -ioengine=psync -bs=4k -size=1000G -numjobs=50 -runtime=180 -group_reporting -name=randrw_70read_4k

2. 参数文件测试

FIO提供了不同场景的压测参数文件，修改其中配置然后直接执行即可。https://github.com/axboe/fio/tree/master/examples

fio examples/ssd-test.fio

上面这个参数文件用于测试ssd性能，参数文件内容如下：

其中每一个[]代表一个测试分组，会为每组分别进行测试（比如下面有5组）。



  1. 

    

    

    

    # Do some important numbers on SSD drives, to gauge what kind of
    

    2. 

  2. 

    

    

    

    # performance you might get out of them.
    

    3. 

  3. 

    

    

    

    #
    

    4. 

  4. 

    

    

    

    # Sequential read and write speeds are tested, these are expected to be
    

    5. 

  5. 

    

    

    

    # high. Random reads should also be fast, random writes are where crap
    

    6. 

  6. 

    

    

    

    # drives are usually separated from the good drives.
    

    7. 

  7. 

    

    

    

    #
    

    8. 

  8. 

    

    

    

    # This uses a queue depth of 4. New SATA SSD's will support up to 32
    

    9. 

  9. 

    

    

    

    # in flight commands, so it may also be interesting to increase the queue
    

    10. 

  10. 

    

    

    

    # depth and compare. Note that most real-life usage will not see that
    

    11. 

  11. 

    

    

    

    # large of a queue depth, so 4 is more representative of normal use.
    

    12. 

  12. 

    

    

    

    #
    

    13. 

  13. 

    

    

    

    [global]
    

    14. 

  14. 

    

    

    

    bs=4k
    

    15. 

  15. 

    

    

    

    ioengine=libaio
    

    16. 

  16. 

    

    

    

    iodepth=4
    

    17. 

  17. 

    

    

    

    size=10g
    

    18. 

  18. 

    

    

    

    direct=1
    

    19. 

  19. 

    

    

    

    runtime=60
    

    20. 

  20. 

    

    

    

    directory=/mount-point-of-ssd
    

    21. 

  21. 

    

    

    

    filename=ssd.test.file
    

    22. 

  22. 

    

    

    

     
    

    23. 

  23. 

    

    

    

    [seq-read]
    

    24. 

  24. 

    

    

    

    rw=read
    

    25. 

  25. 

    

    

    

    stonewall
    

    26. 

  26. 

    

    

    

     
    

    27. 

  27. 

    

    

    

    [rand-read]
    

    28. 

  28. 

    

    

    

    rw=randread
    

    29. 

  29. 

    

    

    

    stonewall
    

    30. 

  30. 

    

    

    

     
    

    31. 

  31. 

    

    

    

    [seq-write]
    

    32. 

  32. 

    

    

    

    rw=write
    

    33. 

  33. 

    

    

    

    stonewall
    

    34. 

  34. 

    

    

    

     
    

    35. 

  35. 

    

    

    

    [rand-write]
    

    36. 

  36. 

    

    

    

    rw=randwrite
    

    37. 

  37. 

    

    

    

    stonewall

下面是一个模拟MySQL数据库的压测配置文件



  1. 

    

    

    

    # QPS: 40000（10 cores)
    

    2. 

  2. 

    

    

    

    # Dataset: 200G
    

    3. 

  3. 

    

    

    

    # R/W: 8/2
    

    4. 

  4. 

    

    

    

    # ThreadPool Num: 64
    

    5. 

  5. 

    

    

    

    #  IO ThreadNum: 32
    

    6. 

  6. 

    

    

    

     
    

    7. 

  7. 

    

    

    

    [global]
    

    8. 

  8. 

    

    

    

    runtime=86400
    

    9. 

  9. 

    

    

    

    time_based
    

    10. 

  10. 

    

    

    

    group_reporting
    

    11. 

  11. 

    

    

    

    directory=/your_dir
    

    12. 

  12. 

    

    

    

    ioscheduler=deadline
    

    13. 

  13. 

    

    

    

    refill_buffers
    

    14. 

  14. 

    

    

    

     
    

    15. 

  15. 

    

    

    

    [mysql-binlog]
    

    16. 

  16. 

    

    

    

    filename=test-mysql-bin.log
    

    17. 

  17. 

    

    

    

    bsrange=512-1024
    

    18. 

  18. 

    

    

    

    ioengine=sync
    

    19. 

  19. 

    

    

    

    rw=write
    

    20. 

  20. 

    

    

    

    size=24G
    

    21. 

  21. 

    

    

    

    sync=1
    

    22. 

  22. 

    

    

    

    rw=write
    

    23. 

  23. 

    

    

    

    overwrite=1
    

    24. 

  24. 

    

    

    

    fsync=100
    

    25. 

  25. 

    

    

    

    rate_iops=64
    

    26. 

  26. 

    

    

    

    invalidate=1
    

    27. 

  27. 

    

    

    

    numjobs=64
    

    28. 

  28. 

    

    

    

     
    

    29. 

  29. 

    

    

    

    [innodb-data]
    

    30. 

  30. 

    

    

    

    filename=test-innodb.dat
    

    31. 

  31. 

    

    

    

    bs=16K
    

    32. 

  32. 

    

    

    

    ioengine=psync
    

    33. 

  33. 

    

    

    

    rw=randrw
    

    34. 

  34. 

    

    

    

    size=200G
    

    35. 

  35. 

    

    

    

    direct=1
    

    36. 

  36. 

    

    

    

    rwmixread=80
    

    37. 

  37. 

    

    

    

    numjobs=32
    

    38. 

  38. 

    

    

    

     
    

    39. 

  39. 

    

    

    

    thinktime=600
    

    40. 

  40. 

    

    

    

    thinktime_spin=200
    

    41. 

  41. 

    

    

    

    thinktime_blocks=2
    

    42. 

  42. 

    

    

    

     
    

    43. 

  43. 

    

    

    

    [innodb-trxlog]
    

    44. 

  44. 

    

    

    

    filename=test-innodb.log
    

    45. 

  45. 

    

    

    

    bsrange=512-2048
    

    46. 

  46. 

    

    

    

    ioengine=sync
    

    47. 

  47. 

    

    

    

    rw=write
    

    48. 

  48. 

    

    

    

    size=2G
    

    49. 

  49. 

    

    

    

    fsync=1
    

    50. 

  50. 

    

    

    

    overwrite=1
    

    51. 

  51. 

    

    

    

    rate_iops=64
    

    52. 

  52. 

    

    

    

    invalidate=1
    

    53. 

  53. 

    

    

    

    numjobs=64

五、 测试结果解读

测试输出结果如下



  1. 

    

    

    

    fio -ioengine=libaio -bs=4k -direct=1 -thread -rw=read -filename=/dev/sda -name="BS 4KB read test" -iodepth=16 -runtime=60
    

    2. 

  2. 

    

    

    

     
    

    3. 

  3. 

    

    

    

    #输出
    

    4. 

  4. 

    

    

    

    BS 4KB read test: (g=0): rw=write, bs=1M-1M/1M-1M/1M-1M, ioengine=libaio, iodepth=16
    

    5. 

  5. 

    

    

    

    fio-2.8
    

    6. 

  6. 

    

    

    

    Starting 1 process
    

    7. 

  7. 

    

    

    

    Jobs: 1 (f=1): [W(1)] [100.0% done] [0KB/68198KB/0KB /s] [0/66/0 iops] [eta 00m:00s]
    

    8. 

  8. 

    

    

    

    test: (groupid=0, jobs=1): err= 0: pid=4676: Thu Apr  7 17:22:37 2016
    

    9. 

  9. 

    

    

    

      write: io=20075MB, bw=68464KB/s, iops=66, runt=300255msec           #执行多少IO，平均带宽，线程运行时间
    

    10. 

  10. 

    

    

    

        slat (usec): min=51, max=5732, avg=291.11, stdev=262.47           #提交延迟
    

    11. 

  11. 

    

    

    

        clat (usec): min=1, max=2235.8K, avg=239043.28, stdev=153384.41   #完成延迟
    

    12. 

  12. 

    

    

    

         lat (usec): min=367, max=2235.9K, avg=239337.72, stdev=153389.57 #响应时间
    

    13. 

  13. 

    

    

    

        clat percentiles (usec):
    

    14. 

  14. 

    

    

    

         |  1.00th=[  221],  5.00th=[  442], 10.00th=[ 1004], 20.00th=[108032],
    

    15. 

  15. 

    

    

    

         | 30.00th=[228352], 40.00th=[248832], 50.00th=[257024], 60.00th=[268288],
    

    16. 

  16. 

    

    

    

         | 70.00th=[280576], 80.00th=[301056], 90.00th=[342016], 95.00th=[477184],
    

    17. 

  17. 

    

    

    

         | 99.00th=[806912], 99.50th=[864256], 99.90th=[1122304], 99.95th=[1171456],
    

    18. 

  18. 

    

    

    

         | 99.99th=[1646592]
    

    19. 

  19. 

    

    

    

        bw (KB/s): min=  170, max=204800, per=100.00%, avg=68755.07, stdev=27034.84
    

    20. 

  20. 

    

    

    

        lat (usec) : 2=0.01%, 4=0.13%, 50=0.06%, 100=0.26%, 250=1.04%
    

    21. 

  21. 

    

    

    

        lat (usec) : 500=4.53%, 750=2.61%, 1000=1.33%
    

    22. 

  22. 

    

    

    

        lat (msec) : 2=1.18%, 4=0.15%, 10=0.77%, 20=0.77%, 50=1.50%
    

    23. 

  23. 

    

    

    

        lat (msec) : 100=4.43%, 250=23.48%, 500=53.23%, 750=3.09%, 1000=1.30%
    

    24. 

  24. 

    

    

    

        lat (msec) : 2000=0.19%, >=2000=0.01%
    

    25. 

  25. 

    

    

    

      cpu          : usr=0.03%, sys=2.11%, ctx=19066, majf=0, minf=7
    

    26. 

  26. 

    

    

    

      IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=103.8%, 32=0.0%, >=64=0.0%   #io队列
    

    27. 

  27. 

    

    

    

         submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%  #单个IO提交要提交的IO数
    

    28. 

  28. 

    

    

    

         complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.1%, 32=0.0%, 64=0.0%, >=64=0.0%  
    

    29. 

  29. 

    

    

    

         issued    : total=r=0/w=20060/d=0, short=r=0/w=0/d=0, drop=r=0/w=0/d=0
    

    30. 

  30. 

    

    

    

         latency   : target=0, window=0, percentile=100.00%, depth=16    #IO完延迟的分布
    

    31. 

  31. 

    

    

    

     
    

    32. 

  32. 

    

    

    

    Run status group 0 (all jobs):
    

    33. 

  33. 

    

    

    

      WRITE: io=20075MB, aggrb=68464KB/s(group总带宽), minb=68464KB/s(最小平均带宽), maxb=68464KB/s(最大平均带宽), mint=300255msec(group中线程的最短运行时间), maxt=300255msec(group中线程的最长运行时间)
    

    34. 

  34. 

    

    

    

     
    

    35. 

  35. 

    

    

    

    Disk stats (read/write):
    

    36. 

  36. 

    

    

    

      sda: ios=23/41769(所有group总共执行的IO数), merge=0/149(总共发生的IO合并数), ticks=706/9102766(Number of ticks we kept the disk busy), in_queue=9105836(花费在队列上的总共时间), util=100.00%(磁盘利用率)

输出参数介绍（详情参考 Fio Output Explained）

  • io=执行了多少M的IO
  • bw=平均IO带宽（吞吐量）
  • iops=IOPS
  • runt=线程运行时间
  • slat=提交延迟，提交该IO请求到kernel所花的时间（不包括kernel处理的时间）
  • clat=完成延迟, 提交该IO请求到kernel后，处理所花的时间
  • lat=响应时间
  • bw=带宽
  • cpu=利用率
  • IO depths=io队列
  • IO submit=单个IO提交要提交的IO数
  • IO complete=Like the above submit number, but for completions instead.
  • IO issued=The number of read/write requests issued, and how many of them were short.
  • IO latencies=IO完延迟的分布
  • io=总共执行了多少size的IO
  • aggrb=group总带宽
  • minb=最小平均带宽
  • maxb=最大平均带宽
  • mint=group中线程的最短运行时间
  • maxt=group中线程的最长运行时间
  • ios=所有group总共执行的IO数
  • merge=总共发生的IO合并数
  • ticks=Number of ticks we kept the disk busy
  • io_queue=花费在队列上的总共时间
  • util=磁盘利用率

六、 测试建议

  • 使用顺序IO和较大的blocksize测试吞吐量和延迟
  • 使用随机IO和较小的blocksize测试IOPS和延迟
  • 在配置numjobs和iodeph前，建议深入了解应用采用的是同步IO还是异步IO（是多进程并发IO还是一次提交一批IO请求）

备注

  • 磁盘的 IOPS，也就是在一秒内，磁盘进行多少次 I/O 读写。
  • 磁盘的吞吐量，也就是每秒磁盘 I/O 的流量，即磁盘写入加上读出的数据的大小。
  • 每秒 I/O 吞吐量＝ IOPS* 平均 I/O SIZE。

七、 简单自动压测脚本



  1. 

    

    

    

    #!/bin/sh
    

    2. 

  2. 

    

    

    

    # fiotest.sh
    

    3. 

  3. 

    

    

    

    # bs=4k,1M  size=100M,1G  type=read,randread,write,randrw,rw  各压测三次，取平均值
    

    4. 

  4. 

    

    

    

     
    

    5. 

  5. 

    

    

    

    bs_list=(4k 1M)
    

    6. 

  6. 

    

    

    

    size_list=(100M 1G)
    

    7. 

  7. 

    

    

    

    type_list=(read randread write randrw rw)
    

    8. 

  8. 

    

    

    

     
    

    9. 

  9. 

    

    

    

    for v_bs in {0..1} #bs_list
    

    10. 

  10. 

    

    

    

    do
    

    11. 

  11. 

    

    

    

     
    

    12. 

  12. 

    

    

    

    	for v_size in {0..1} #size_list
    

    13. 

  13. 

    

    

    

    	do
    

    14. 

  14. 

    

    

    

     
    

    15. 

  15. 

    

    

    

    		for v_type in {0..4} #type_list
    

    16. 

  16. 

    

    

    

    		do
    

    17. 

  17. 

    

    

    

     
    

    18. 

  18. 

    

    

    

    			for v_runtime in {0..2} #runtime
    

    19. 

  19. 

    

    

    

    			do
    

    20. 

  20. 

    

    

    

     
    

    21. 

  21. 

    

    

    

    				logfile=fio_${bs_list[$v_bs]}_${size_list[$v_size]}_${type_list[$v_type]}_$v_runtime.txt
    

    22. 

  22. 

    

    

    

     
    

    23. 

  23. 

    

    

    

    				echo -e "test $v_runtime started\n" > $logfile
    

    24. 

  24. 

    

    

    

    				echo -e "started time `date`\n" >> $logfile
    

    25. 

  25. 

    

    

    

     
    

    26. 

  26. 

    

    

    

    				fio --filename=/data/testfile1 --direct=1 --bs=${bs_list[$v_bs]} --size=${size_list[$v_size]} --rw=${type_list[$v_type]} --ioengine=libaio --iodepth=128 --numjobs=1 --time_based --group_reporting --runtime=60 --name=$logfile >> $logfile
    

    27. 

  27. 

    

    

    

     
    

    28. 

  28. 

    

    

    

    				echo -e "\nfinished time `date`" >> $logfile
    

    29. 

  29. 

    

    

    

    				echo -e "\ntest $v_runtime finished" >> $logfile
    

    30. 

  30. 

    

    

    

     
    

    31. 

  31. 

    

    

    

    				sleep 5
    

    32. 

  32. 

    

    

    

     
    

    33. 

  33. 

    

    

    

    			done #runtime
    

    34. 

  34. 

    

    

    

     
    

    35. 

  35. 

    

    

    

    			sleep 60
    

    36. 

  36. 

    

    

    

     
    

    37. 

  37. 

    

    

    

    		done #type_list
    

    38. 

  38. 

    

    

    

     
    

    39. 

  39. 

    

    

    

    	done #size_list
    

    40. 

  40. 

    

    

    

     
    

    41. 

  41. 

    

    

    

    done #bs_list

八、 输出结果解析命令

我们一般记录框里的值

读IO提交延迟

cat fio_* |grep -A 3 read |grep clat > read.tmp

写IO提交延迟

cat fio_* |grep -A 3 write |grep clat > write.tmp

带宽与iops

读

cat fio_* |grep bw|grep iops|grep read > r_iops.tmp

写

cat fio_* |grep bw|grep iops|grep write > w_iops.tmp

直方图信息（记录最大比例）

cat -n fio_* | grep 'lat (' | grep -v min > histos.tmp

参考

FIO使用说明_半遮雨的博客-CSDN博客_fio util结果100%

https://github.com/axboe/fio

IO测试工具之fio详解 - raykuan - 博客园

Fio模拟Mysql服务器IO压力脚本 | 系统技术非业余研究

磁盘性能评价指标—IOPS和吞吐量_风云龙儿的博客-CSDN博客_海波龙磁盘吞吐量多少

</article>

[转帖]FIO 存储性能压测的更多相关文章

  1. 软件性能测试分析与调优实践之路-JMeter对RPC服务的性能压测分析与调优-手稿节选

    一.JMeter 如何通过自定义Sample来压测RPC服务 RPC(Remote Procedure Call)俗称远程过程调用,是常用的一种高效的服务调用方式,也是性能压测时经常遇到的一种服务调用 ...

  2. MySQL 性能压测工具-sysbench，从入门到自定义测试项

    sysbench是一个开源的.基于LuaJIT(LuaJIT 是 Lua 的即时编译器,可将代码直接翻译成机器码,性能比原生 lua 要高) 的.可自定义脚本的多线程基准测试工具,也是目前用得最多的 ...

  3. 性能压测诡异的Requests/second 响应刺尖问题

    最近一段时间都在忙着转java项目最后的冲刺,前期的coding翻代码.debug.fixbug都逐渐收尾,进入上线前的性能压测. 虽然不是大促前的性能压测要求,但是为了安全起见,需要摸个底心里有个数 ...

  4. jmeter系列-如何实现像loadrunner一样，多个并发用户先通过登录初始化，然后做并发的接口性能压测

    自动转开发后,就很少关注性能测试方面的东西,最近在帮朋友做一个性能压测,由于朋友那边的公司比较小,环境比较简单,而且是对http服务进行的压测,所以最终 选用了jmeter来实现这个压测. 如下就是我 ...

  5. 性能压测，SQL查询异常

    早上测试对性能压测,发现取sequence服务大量超时报错,查询线上的监控SQL: 大量这个查询,我在DeviceID和Isdelete上建有复合索引,应该很快,而且我测试了一下,取值,执行效率很高, ...

  6. jmeter性能压测瓶颈排查-网络带宽

    问题: 有一台机器做性能压测的时候,无论开多少个线程,QPS一直压不上去,而服务器和数据库的性能指标(主要是CPU和内存)一直维持在很低的水平. 希望帮忙排查一下原因. 过去看了下进行压测的接口代码, ...

  7. 性能压测中的SLA，你知道吗？

    本文是<Performance Test Together>(简称PTT)系列专题分享的第6期,该专题将从性能压测的设计.实现.执行.监控.问题定位和分析.应用场景等多个纬度对性能压测的全 ...

  8. 并发模式与 RPS 模式之争，性能压测领域的星球大战

    本文是<如何做好性能压测>系列专题分享的第四期,该专题将从性能压测的设计.实现.执行.监控.问题定位和分析.应用场景等多个纬度对性能压测的全过程进行拆解,以帮助大家构建完整的性能压测的理论 ...

  9. [SCF+wetest+jmeter]简单云性能压测工具使用方案

    前言 压测太难?局域网压力无法判断服务器网络指标?无法产生非常大的并发量?云性能太贵? 也许我们可以把各种简单的工具拼起来进行压力测试! 准备 https://cloud.tencent.com/pr ...

  10. EMQ X 系统调优和性能压测

    前言 如果使用 EMQ 来承载百万级别的用户连接可以吗?毕竟在 MQTT 官方介绍上说 EMQ X 可以处理千万并发客户端,而 EMQ X 自己官方称 4.x 版本 MQTT 连接压力测试一台 8 核 ...

随机推荐

  1. 面试官：禁用Cookie后Session还能用吗？

    Cookie 和 Session 是 Web 应用程序中用于保持用户状态的两种常见机制,它们之间既有联系也有区别. Cookie 是由服务器在 HTTP 响应中发送给客户端(通常是浏览器)的一小段数据 ...

  2. ThreadLocal真的会造成内存泄漏吗？

    ThreadLoca在并发场景中,应用非常多.那ThreadLocal是不是真的会造成内存泄漏?今天给大家做一个分享,个人见解,仅供参考. 1.ThreadLocal的基本原理 简单介绍一下Threa ...

  3. 云图说｜华为云CodeArts Build，云端化的编译构建平台

    阅识风云是华为云信息大咖,擅长将复杂信息多元化呈现,其出品的一张图(云图说).深入浅出的博文(云小课)或短视频(云视厅)总有一款能让您快速上手华为云.更多精彩内容请单击此处. 本文分享自华为云社区&l ...

  4. EDS从小白到专家丨打造数据交换的六边形卫士，让你的数据你做主

    本文分享自华为云社区<[EDS从小白到专家]第4期:打造数据交换的六边形卫士,让你的数据你做主>,作者: 开天aPaaS小助手 . 你还在担心数据共享后一旦"失控"将爆 ...

  5. GaussDB技术解读系列之应用无损透明（ALT）

    本文作者 :华为云GaussDB研发高级工程师 藏琦 1.背景 GaussDB作为一款企业级分布式数据库,提供了"同城跨AZ双活.两地三中心.双集群强一致"等极致的高可用容灾能力. ...

  6. 新晋“网红”Cat1 是什么

    摘要:此Cat非彼Cat,它是今年物联网通信圈新晋网红"靓仔". 引言 今年5月,工信部发布了<关于深入推进移动物联网全面发展的通知>,明确提出推动存量2G.3G物联网 ...

  7. 这场世界级的攻坚考验，华为云GaussDB稳过

    摘要:实践证明,华为云GaussDB完全经受住了这场世界级的攻坚考验,也完全具备支撑大型一体机系统迁移上云的能力,并积累了丰富的经验. 本文分享自华为云社区<这场世界级的攻坚考验,华为云Gaus ...

  8. Solon Aop 特色开发（3）构建一个Bean的三种方式

    Solon,更小.更快.更自由!本系列专门介绍Solon Aop方面的特色: <Solon Aop 特色开发(1)注入或手动获取配置> <Solon Aop 特色开发(2)注入或手动 ...

  9. Solon Web 开发，三、打包与运行

    Solon Web 开发 一.开始 二.开发知识准备 三.打包与运行 四.请求上下文 五.数据访问.事务与缓存应用 六.过滤器.处理.拦截器 七.视图模板与Mvc注解 八.校验.及定制与扩展 九.跨域 ...

  10. Kubernetes(K8S) helm 安装

    Helm 是一个 Kubernetes 的包管理工具, 就像 Linux 下的包管理器, 如 yum/apt 等, 可以很方便的将之前打包好的 yaml 文件部署到 kubernetes 上. Hel ...