## 先弄清两类负载
客服系统的压力由两部分组成。工单是异步协作，坐席之间转发、补充、关单，读写都不密集，但对数据可靠性要求高；在线会话是实时通道，访客一进来就挂一条长连接，消息一来一回，延迟直接被用户感知。把两者混在一台机器上按同一口径评估负载，是容量规划最常见的起点错误。
## 长连接与消息量的估算逻辑
在线会话的服务端成本主要不在计算，而在并发连接数与内存。每条长连接都要占住一份内存与文件描述符，会话高峰集中在工作时间，上午与晚间各有一个波峰，峰值并发可能是闲时的数倍。工单部分则接近典型的 Web 数据库负载，增长平稳，可按历史工单量线性外推。估算时先定峰值并发会话数，再按每连接内存推算应用进程的内存下限；CPU 按消息吞吐与坐席操作频率估，一般不是第一瓶颈。
## 最小实操
起步阶段用一台中等内存配置的顺云云服务器跑应用，数据库单独一台或使用独立实例，会话服务与应用主体可以同机分进程部署。上线前在控制台配好监控告警，重点盯三个指标：当前连接数、消息队列积压、工单接口响应时间。压测时模拟工作时间的峰值并发，观察内存曲线与连接回收是否平稳，回收不掉说明超时参数没配对。
## 常见错误
按日均访问量配机器，忽略了长连接在峰值时段的堆积，导致下午三点后新会话接不进。把会话超时设得过长，访客关掉页面后连接仍占内存，累积到进程上限。工单附件与数据库同盘，附件把磁盘打满后连工单都打不开。这些问题的共同解法是把峰值并发与连接生命周期纳入容量表，而不是只看平均值。