长连接系统性能指标的定语陷阱

比较不同语言实现的长连接push系统性能时，很难保证测试环境和需求完全统一，任何一个看起来漂亮的数字背后都藏着一堆容易被忽略的”定语”，至少体现在三个指标上。单机连接数：稳定连接、没有网络吞吐的情况下比较连接数意义不大，因为维持连接本身消耗的CPU很小、每条TCP连接约占4K内存，单实例理论上能冲到300万长连接；但在真实弱网络环境下，假设每秒千分之一的用户断线重连，300万长连接意味着每秒新建连接达3万，这3万用户要做注册、加载离线存储等内部RPC调用，还要维持全部连接的心跳（假设300秒一次心跳，每秒也要一万TPS），加上单播多播广播数据转发、GC压力、内部接口响应延迟，这些压力集中在一个实例里，可用性会成为真正的挑战——所以线上单实例实际支持的连接数远低于理论峰值，要结合客户端真实网络状况来定。消息系统的内存使用量：是否需要全双工（读写能否同时进行）会决定每个用户连接需要一个还是两个协程，读写buffer是全局复用、每连接独享、还是动态申请，都会让内存开销的测试结果完全不可比。每秒消息下发量：要看消息到达的QoS级别（ACK策略）、架构是纯推还是推拉结合、是否开启消息日志及其缓冲和flush策略，还要算上为高可用增加的内部通信成本、以及应对小概率闪断的补偿策略成本——去掉这些机制才是纯粹比拼基础库性能，但真实生产系统不可能都去掉。这三个指标共同说明：脱离具体场景、需求和实现细节孤立比较一个”性能数字”是没有意义的，任何架构性能对比都要先把这些”定语”讲清楚，否则数字之间根本不可比。