校园网认证计费系统的性能指标，厂商在方案书里写的都是很亮眼的数字——"单机支持百万用户""每秒认证四千次以上""系统可用性99.99%"。但这些数字的真假，不是看文档就能判断的。检验性能只有一种方法，就是在尽可能接近真实场景的条件下跑压力测试。但这个"尽可能接近真实场景"本身就很难做到，很多项目的压力测试做完了，上线之后照样在高峰期被打穿，就是因为测试场景跟真实环境差距太大。

最典型的错误做法是只用单一场景做压力测试。比如只模拟一万个用户在五分钟之内同时发起Portal认证——这个场景下系统撑住了，厂商就说"我们一万并发没问题"。但真实环境中的压力模式不是这样的。晚高峰时段的负载峰值是这样叠加的：有学生在不停地做Portal弹窗认证、有已经认证的用户在产生上网流量（这会产生计费数据写入）、有学生在充值（支付回调触发套餐开通）、同时AC还在向认证服务器发送无感知认证请求。这四种负载是叠加在一起的。如果你只测了其中一种场景，那得到的性能数据就严重失真。

正确的压力测试方法应该是混合负载测试。测试脚本需要同时模拟四种并发场景：Portal认证请求（模拟新生入学高峰期）、已认证用户持续在线流量（模拟日常晚高峰）、充值和套餐变更（模拟学期初缴费高峰）、无感知认证请求（模拟学生日常漫游）。四种场景的并发比例要参考学校的历史数据来设定——比如某个学校的数据显示晚高峰时段Portal认证占比约15%、在线流量占比约60%、无感知认证占比约20%、充值操作占比约5%，那就按这个比例来构建混合负载。

第二个测试盲区是长时间持续负载下的性能衰减。很多压力测试只跑10分钟或者半小时，看到系统没挂就收工了。但实际上认证计费系统是一个长期持续运行的系统，如果存在内存泄漏、数据库连接池耗尽、日志文件膨胀等问题，可能在连续运行几个小时甚至一两天之后才开始出现性能下降。所以压力测试至少要跑一轮长时间耐力测试——建议至少连续跑八小时的混合负载，每半小时记录一次关键指标（认证响应时间、CPU使用率、内存使用率、数据库连接数），观察有没有明显的性能衰减趋势。

第三个关键测试点是故障场景下的降级能力。真实环境里故障是必然会发生的——数据库主库宕机了、RADIUS服务挂掉了、网络链路断了、机房断电了。系统能不能在这些异常情况下至少保证认证服务的基本可用性？比如在数据库主库宕机的时候自动切换到备库、在RADIUS响应超时的时候用本地缓存数据做认证兜底、在日志服务器不可用的时候先把日志暂存到本地磁盘等恢复后再补传。这些降级能力如果不在压力测试阶段逐一验证，等真的出了问题就是全网中断。

代拨模式下的性能测试还有一个独特的难点：运营商BRAS的响应时间不可控。认证流程里有一个环节是代拨网关向运营商BRAS发起PPPoE拨号请求，这个拨号请求的响应时间取决于运营商BRAS的网络状况和负载水平。你实验室里用测试环境测出来拨号响应时间平均0.5秒，上线的第一天晚高峰运营商BRAS因为全网负载高，拨号响应时间翻了一倍。那整个认证流程的端到端时长就会从你测试时的两秒变成四秒——用户可能以为认证卡住了。所以性能测试里必须把BRAS响应延迟作为一个可变参数，分别测试在正常延迟（0.5秒）、较高延迟（1秒到2秒）和极端延迟（3秒以上）三种情况下的系统表现。

最后再提一个容易被忽视的验证维度：Portal页面的大小和加载速度对认证成功率的影响。有些学校很在意Portal页面的美观程度，往上面堆了很多高清轮播图、CSS动画和JavaScript框架，结果Portal页面的总体积超过了5MB。在学生宿舍WiFi信号较差或者AP负载较高的场景下，这个页面可能要十几秒才能完全加载完成。很多学生在页面还没加载完的时候就以为认证失败了、切出去干别的了。portal页面的大小对认证成功率的影响，尤其是低信号环境下的影响，应该在测试阶段做专项验证——用网络限速工具模拟不同带宽和延迟条件下的Portal页面加载情况，观察认证完成率的变化。

高并发支撑能力的验证，本质上不是测"系统在什么负载下会挂"，而是测"系统在各种真实场景组合下，能不能稳定地提供合格的用户体验"。这两者之间差的是一个完整的测试策略——混合负载、长时间耐力、故障降级、外部依赖延迟、终端弱网环境——缺了任何一项，测试结论都是有盲区的。宁愿多花一周时间把测试做扎实，也好过上线之后在晚高峰堵在机房打电话催促扩容。