关于一个简单接口的并发测试与优化记录

目的

通过测试了解高并发的各处细节,寻找制约因素;为软硬架构设计提供优化参考。

前述

  • 优化前,该接口在测试环境的qps为140左右
  • 该接口的内部逻辑
    • 处理前1:开始计时
    • 处理前2:较验IP白名单
    • 处理:
      • 查询数据库并缓存
    • 处理后1:结束计时,并提交日志(用于形成性能报告)
      • 日志通过REST API,最终写入数据库
  • 该接口特征:
    • 内部处理简单
    • 可优化点比较清楚

开始测试

  • 使用一个nio或aio的通道框架测试helloworld

    • 使用本机测试,qps约为:450万(我的电脑4c 16g)
      • 如果server端的服务线程,加个System.out.println;qps估计要降一半(亲自跑过)
  • 使用solon.boot.jlhttp,测试helloworld(单机,单实例)

    • 使用本机测试,qps 约为:5万(我的电脑4c 16g)
    • 使用域局网测试(192.168.8.118),qps给为:2万(2c 16g)
  • 测试 getAppByID 接口(服务端为单机单实例;测试端为另一台机,走的是内网)

    • 服务端测试机情况
      • 上面有8个java服务;docker服务(memcached,redis,mysql);
    • 初始测试
      • qps约为:140
    • 去掉三个触发器(相当于Spring的过滤器)
      • -不用缓存,qps约为:600
      • +memcached,qps约为:1万(memcached 在本机,应该有优势;否则可能差些)
      • +二级缓存,qps约为:1.4万
      • 从DB角度思考,如果涉及写。。。qps只能靠DB的硬件提升了(量大时,还要靠分库分表)
    • 加上触发器 + 二级缓存
      • +记性能,qps约为:750
      • +记性能 +记日志,qps约为;240(异步http提交日志;可能存储在本机会有较大负影响;sev->http->db->磁盘
      • +记性能 +记日志 +白名单较验,qps约为:160
      • +白名单较验,qps约为:900

优化一

  • 将okhttp异步,改为线程池加同步(okhttp自带的异步,因为有融断机制性能差些)
    • +记性能 +记日志,qps约为;320(异步http提交日志;明明是异步了,为什么还这么低?因为还是有IO)
    • +记性能 +记日志 +白名单较验,qps约为:200

优化二

  • 为白名单增加10s本地缓存
    • +白名单较验,qps约为:1.1万
    • +记性能 +记日志 +白名单较验,qps约为:320

优化三

  • 性能记录,改为本地收集 + 5秒间隔提交
    • +记性能 +白名单较验,qps约为:8000(应该还有优化空间)
    • +记性能 +记日志 +白名单较验,qps约为:800
  • 日志级别动态可控,可在非必要时控制日志提交量
    • 日志约等于可没有...进而减少这部分的IO(对于业务系统,这个控制是非常之必要)

优化四

  • 优化性能记录的定时器
    • +记性能 +白名单较验,qps约为:15000
  • 日志改为管道模式
    • 统一写入队列;定时抽取队列数据,分批提交给代理(一批量多为100个)
      • +记性能 +记日志 +白名单较验
        • 1秒间隔,单包最多100个日志:qps约为:5000
        • 1秒间隔,单包最多200个日志:qps约为:10000
//日志级别动态切换控制
WaterClient.Config.subscribe("sponge", (set)->{
    int level = set.get("rock_log_level").getInt();
    WaterLogger.setLevel(Level.of(level));
});

后续实验尝试

  • 实验一:
    • 对比测试:日志管道模式提交,与代理抓取模式的差异

分析总结

  • 减少IO次数(主要是网络写IO),可以大大提搞QPS。。。此为王道
  • 何为IO?一次IO输出过程:
    • 应用空间 - > 内核空间 -> 设备寄存器
    • 减少次数或避免IO可大大提高并发(像System.out.print...就是,都会影响高并发)
  • IO的总量有限...
    • 我们经常会看到,cpu、内存很底,但是并发压不上去。。。就是大量的IO在排队
    • 或者程序在一段时间失去了响应,过段时间又好了。。。也是大量的IO在排队
    • 业务的程序,基本上是IO密集型的
    • 不管是多线程,还是异步。。。但IO总量有限
      • 之前一直以为,异步写日志对并发没什么影响;对单次请求性能无影响,但会占用IO资源

附:

  • 工具安装
# centos 版
yum install -y https://github.com/scutse/wrk-rpm/releases/download/4.1.0/wrk-4.1.0-1.el7.centos.x86_64.rpm

# mac 版
brew install wrk
  • 测试代码
wrk -t10 -c200 -d10s --latency "http://10.0.0.79:1013/getAppByID?appID=10970"
posted @ 2020-06-30 17:54  刘之西东  阅读(...)  评论(...编辑  收藏