看来和设计1000比较相符，，，那我停了
好像还真是带宽爆了，我看 CPU Profiler 的结果都堵在网络 IO 上了
流量算法切换到bbr看看？
BBR 不是万能的
不过在有一定时延和丢包的情况下较其他算法还是有优势的
可以再试一次，根据建议我改了一下最大允许的连接数，然后撤掉了异步队列（这可能是个正向优化，也可能是个负向优化）。
我刚刚测了一下服务器的带宽，它实际上有 3Gbps 的带宽，大概是瓶颈不了（至少到测速服务器不会），但是到你的服务器带宽可能是有限的。
除此之外，开了压缩支持。
另外：本次使用 Valkey 而不是 Garnet，看看 Valkey 的并发能力
好了，你观察看看，我总感觉瓶颈是docker。。。
稍等，我有个参数没调，我调一下解除限制
发现 service.tracker.max-parallel-announce-service-requests 的参数被限制在了一个较低的水平，现在重启一下解除这个限制
- 00:48 新参数上线
- 00:48 忘记更新版本了……更新一下 更新到 4cf51e7
是的爆了，但是不知道哪里出的问题，我 dump 一下线程
Redis 线程 CPU 压力满了
现在换回 Garnet 看看
- 重启更换 Garnet
- 停止使用虚拟线程，换到 OS 线程看看
现在应该部分恢复了，还在看效果，响应速度现在恢复了（好像直接不调度了？现在 QPS 只有来自 newtracker 的 300 左右的 qps）
视乎你做了这个后，就恢复正常了
QPS: 1.71k
CPU: ~49%
Heap RAM: < 3GB (in use)
目前 Garnet 和 Sparkle 的 CPU 使用率一半一半的样子
我怀疑是 CarrierThreads 频繁的上下文切换导致产生性能损失了
其实中间我做了不止这一件事情
- 一个是禁用了虚拟线程，我怀疑承载虚拟线程的平台线程数量不足，而且频繁上下文产生了性能损耗
- 将
server.tomcat.threads.max加到了 500 个 OS 线程 server.tomcat.accept-count加了三倍到300server.tomcat.max-connections还是保持默认 8192
虚拟线程其实就是其他语言里的 “协程”，指在一个平台线程上分时运行多个虚拟的线程，因为平台线程由操作系统管理，开太多了系统吃不消
平台线程就是 OS 线程，也就是实打实的操作系统上面开一个新的线程
我现在怀疑是承载虚拟线程的 CarrierThreads 线程数少的太保守了，导致性能上不来？
改回虚拟线程？
- 改成虚拟线程
- 观察结果 爆了
你改回去试试？我调度还没停
对，改回去虚拟线程看看还会不会爆
我可以试试看增加下虚拟线程对应的平台线程数量
之前有建议过比特彗星引入boost fcontext协程，减少上下文切换，，然而官方没回我
使用fcontext应该能提高性能
并不总是绝对的，要看场景，协程比较适合 I/O 重或者中间有阻塞代码的。
我刚刚加了一下 jdk.virtualThreadScheduler.parallelism 到 128，让我检查一下生没生效
笑死，生效了，但是除了 CPU 占用变高了以外，没看到服务变好
我现在加到和原来的平台线程一样的 500 看看，没啥卵用
- 切换回平台线程
现在是平台线程，但不知道为什么还是卡住，好了，又卡住了，我启个 profiler 看看
看来这个虚拟线程很烂的样子，所以以后要避开这个，都用os线程
切换回去居然又卡住了吗，怪，我这里提示503
服务器这里出现了奇怪的网络问题，我感觉好像网络中断了，但我 web 控制台还连着
重启一下容器看看，各种意义上的十分诡异