目的
通过测试了解高并发的各处细节，寻找制约因素；为软硬架构设计提供优化参考。
前述
优化前，该接口在测试环境的qps为140左右
该接口的内部逻辑处理前1：开始计时
处理前2：较验IP白名单
处理：查询数据库并缓存
处理后1：结束计划，并提交日志（用于形成性能报告）日志通过REST API，最终写入数据库
该接口特征：内部处理简单
可优化点比较清楚
开始测试
使用一个nio或aio的通道框架测试helloworld
使用本机测试，qps约为：450万（我的电脑 macbook pro 4c 16g）如果server端的服务线程，加个System.out.println；qps估计要降一半（亲自跑过）
使用solon.boot.jlhttp，测试helloworld（单机，单实例）
使用本机测试，qps 约为：5万（我的电脑 macbook pro 4c 16g）
使用域局网测试（192.168.8.118），qps给为：2万（2c 4g 虚拟机）
测试getAppByID（服务端为单机单实例；测试端为另一台机，走的是内网）
服务端测试机情况上面有8个java服务；docker服务（memcached，redis，mysql）；
初始测试qps约为：140
去掉三个触发器-不用缓存，qps约为：600
+memcached，qps约为：1万（memcached 在本机，应该有优势；否则可能差些）
+二级缓存（一级为本地缓存），qps约为：1.4万
从DB角度思考，如果涉及写。。。qps只能靠DB的硬件提升了（量大时，还要靠分库分表）
加上触发器 + 二级缓存+记性能，qps约为：750
+记性能 +记日志，qps约为；240（异步http提交日志；可能存储在本机会有较大负影响；sev->http->db->磁盘）
+记性能 +记日志 +白名单较验，qps约为：160
+白名单较验，qps约为：900
优化一
语言方法
3568L37t85yT45
x1b82
抖音升级了能看到访客52402006-07-05 12:43:59
将okhttp异步，改为线程池加同步(okhttp自带的异步，因为有融断机制性能差些)+记性能 +记日志，qps约为；320（异步http提交日志；明明是异步了，为什么还这么低？因为还是有IO）
+记性能 +记日志 +白名单较验，qps约为：200
优化二
为白名单增加10s本地缓存+白名单较验，qps约为：1.1万
+记性能 +记日志 +白名单较验，qps约为：320
优化三
性能记录，改为本地收集 + 5秒间隔提交+记性能 +白名单较验，qps约为：6000（应该还有优化空间）
+记性能 +记日志 +白名单较验，qps约为：800
日志级别动态可控，可在非必要时控制日志提交量日志约等于可没有...进而减少这部分的IO（对于业务系统，这个控制是非常之必要）
后续方案尝试
优化四：将日志记录，调整为批量隔秒提交；进一步降低框架对应用的并发影响
实验一：对比测试：日志管道模式提交，与代理抓取模式的差异
分析总结
减少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"
本站仅提供存储服务，所有内容均由用户发布，如发现有害或侵权内容，请
点击举报。
