每年开学季，总有一批高校的校园WiFi网络计费系统在学生集中返校那天当场崩溃。平时测试环境跑得好好的，几百个并发认证秒过，一到真实场景就各种超时、丢包、拒绝连接。原因很简单：测试环境和生产环境的流量模型完全不是一回事。压力测试不是可选项，是校园WiFi网络计费系统上线前必须过的坎，而且不能随便跑，要有针对性地模拟真实场景。

并发认证是第一道关

校园WiFi网络计费系统最核心的压力场景就是并发认证。晚上7点，整栋宿舍楼的学生同时回到宿舍打开手机，几千个认证请求在同一秒涌入RADIUS服务器。如果你的计费系统每秒只能处理500个认证请求，而实际峰值达到了2000，那剩下的1500个请求就会排队等待，超时的直接返回拒绝，学生看到的就是"认证失败"。压力测试的第一步就是确定你的系统在当前硬件配置下的认证吞吐量上限。测试方法不复杂：用负载生成工具按梯度增加并发数，从100开始，每次加200，直到认证成功率低于99%或平均响应时间超过2秒。这个临界点就是你的系统容量天花板。记住，这个数字不是理论值，是你在当前服务器、当前网络、当前数据库配置下实测出来的。换一台服务器，这个数字就得重新测。

数据库读写压力不能忽略

很多人做校园WiFi网络计费系统的压力测试只关注认证模块，忽略了数据库的读写压力。实际上，每一次认证请求都会触发至少两次数据库操作：一次查询用户状态和余额，一次更新在线信息。如果是计费场景，还涉及实时扣费和流量记录。当并发认证请求达到峰值时，数据库的连接池可能耗尽、锁等待可能超时、写入队列可能堆积。我见过一个案例，认证模块本身能扛住3000并发，但数据库在1500并发时就开始出现锁等待超时，导致整体吞吐量断崖式下降。压力测试必须把数据库纳入测试范围，而且要关注的是持久连接场景下的表现，不是短连接。因为校园WiFi的用户行为特点是连上之后长时间在线，中间偶尔有流量更新，这意味着数据库上同时存在大量的慢查询连接。

模拟真实的流量模型

压力测试最忌讳的就是用均匀分布的请求来模拟真实场景。校园WiFi网络计费系统的真实流量模型有几个典型特征：早上8点到9点有一个小高峰，是教学区的集中接入；中午12点到1点有一个中高峰，是食堂和宿舍的交叉切换；晚上7点到11点是最大高峰，是宿舍区的集中使用。最极端的场景是晚上7点那一波，大量学生同时回宿舍开手机，认证请求在5分钟内飙升到日均值的10倍。如果你的压力测试只是用固定速率发请求，测出来的容量数据没有参考价值。建议按照真实的日流量曲线来设计压力测试脚本，重点验证高峰时段的系统表现，而不是平均负载。如果资源有限只跑一个场景，那就跑晚上7点那波，这最能暴露问题。

计费精度在高压下的表现

校园WiFi网络计费系统在高压场景下还有一个容易被忽视的问题：计费精度。正常负载下，流量统计和费用计算可能精确到小数点后两位，但在高压下，由于计费引擎的处理延迟、数据库写入的排队等待、流量采样间隔的拉长，计费精度可能下降。具体表现为：用户查询余额时看到的数字和实际扣费不一致、流量统计出现跳跃式的增长、包月用户被错误扣费。这些问题在测试环境很难发现，因为测试环境通常不会跑24小时以上的持续高压。建议在压力测试中加入长时间稳定性测试，至少跑72小时，期间保持50%以上的负载，验证计费精度是否在可接受范围内。

容灾切换和降级策略

压力测试不仅要测系统正常情况下的表现，还要测到达极限后的降级行为。校园WiFi网络计费系统在过载时应该有明确的降级策略：比如优先保证新用户的认证请求，延后非关键的流量统计写入；或者当RADIUS服务器响应超时时，启用本地缓存认证模式，允许已知用户临时上网，等负载下来再同步数据。这些降级策略需要在压力测试中逐一验证，确保在极端场景下系统不会直接挂掉，而是逐步降级保住核心功能。一个没有降级策略的计费系统，过载时就是全线崩溃，恢复时间可能长达数小时，到时候网络中心电话会被打爆。