校园网计费系统上线前做压力测试，很多学校会做一个"模拟用户拨测"就觉得够了。但实际上，计费系统在高并发场景下会暴露的问题，远不止"能同时认证多少用户"这么简单。

最基础的压测是：同时有多少个用户能成功通过认证？这个指标厂商一般都会给，但实际上线时，并发峰值往往出现在特定时间段：晚上十点下晚自习，宿舍区集中上线；开学第一天，几千新生同时激活账号。这些场景的并发模式不是"平稳并发"，而是"突发并发"，对计费系统的连接池和会话管理要求更高。

压测时不只要看平均响应时间，还要看 P99 响应时间。如果 1% 的用户认证要等超过 10 秒，上线后的投诉量会很明显，即使平均响应时间看起来不错。

计费系统要维护一张"当前在线用户表"，这张表的大小直接影响系统负载。很多系统在测试环境里跑得很好，因为在线用户只有几百个。但实际上线后，几千人同时在线，这张表的查询和更新频率非常高，如果数据库没有针对这个场景做优化，上线一两周后会出现认证变慢、掉线率上升的问题。

压测时要模拟的不仅是认证并发，还要模拟持续在线用户数。建议压到 1.5 倍规划容量，看系统指标是不是还平稳。

很多校园网的认证流程是：用户连 WiFi → 拿到 IP（DHCP）→ 打开浏览器 → 被重定向到认证页面 → 输入账号认证。这个流程里，DHCP 的 IP 池大小和续租行为，会直接影响认证系统的会话管理。

如果 DHCP 租期设得太短，用户 IP 频繁变更，计费系统里的在线会话就会变得混乱，出现"认证了但流量不通"或者"下线了但会话还在"的问题。压测时建议把 DHCP 续租场景也模拟进去，看计费系统能不能正确处理 IP 变更。

高并发不只是用户上网的时候。开学季批量导入几千个账号，毕业季批量销户或者强制下线，这些都是计费系统的高负载场景。很多系统在"逐个用户操作"时表现正常，但批量操作时数据库锁表、任务队列堆积，会导致整个系统响应变慢。

压测时要专门测批量场景：一次导入 3000 个账号要多长时间？批量强制下线 1000 个用户时，新用户认证会不会被阻塞？这些问题的答案，决定了开学季要不要熬夜手工操作。

单一指标压测的意义有限。建议把上面几个场景组合起来跑一遍：在已经有 80% 规划容量的用户在线的情况下，再发起一波突发认证；在批量开户任务执行的同时，模拟用户正常上网和认证；在系统已经运行 7×24 小时之后，看内存有没有泄漏、日志文件有没有把磁盘写满。

校园网计费系统这个产品，功能跑通和能扛住高并发稳定运行，是两回事。压测做得细一点，上线后的运维压力会小很多。