==== SUMMARY ====
Uplink capacity: 402.621 Mbps
Downlink capacity: 863.956 Mbps
Responsiveness: Medium (118.769 milliseconds | 505 RPM)
Idle Latency: 51.000 milliseconds | 1176 RPM

新年好

建议加快捷键 j k 用于上下滚动

@ltkun 有什么 pt 可以推荐下吗

求一个馒头，300M 带宽，群辉
MTUxODk0MzY5NUBxcS5jb20=

我的经验是可以专门找时间去图书馆或者书店这种场所去专门看书，这样不容易被手机打扰，周围环境也能更容易静下心来

@iseki 主要还是 grpc 框架的限制，目前是不支持这种方式的。然后就算是在流中处理，他也是需要占用堆内存，还是解决不了 GC 的问题

@ccde8259 这个我理解 netty 已经给封装好了？各种 handler ，直接处理 ByteBuf 就行了

@iseki proto 编解码工作量还行，接口不多，而且工作是一次性的。至于 API 这个，说多了都是泪，需要适配客户端，客户端升级不了。
能再详细说一下 arena 是什么原理，怎么用吗？

@momo24672 这个解决不了，protobuf 里面的 bytes 还是会分配对堆内存的问题

@flyqie 消息队列的场景

@ccde8259 思路是这个，就是说目前 grpc 的 api 不支持分配到非堆，所以想看看我说的那个用 netty 实现的思路行不行

@wenhuibrave 都不用强制 GC ，每分钟十几次，主要是流量大 2GB/s ，垃圾多，算下来也是这么个 GC 频率。gc 调优治标不治本。所以才想不用 grpc ，自己去解析 ByteBuf

@haython 对，必须得用 java

@chendy 最大可能几十 MB ，单机流量快 2GB/s 。用的 ZGC ，主要是 Allocation Stall 内存分配暂停。

@me1onsoda 用的 ZGC ，stw 比较短，但是会有 Allocation Stall ，几百毫秒

@lmshl 目前是 ZGC ，流量太大 2GB/s ，堆都用了 40G 了，偶尔还是会有内存分配暂停。单个 grpc 请求比较大，可能会有几十 M