晚上九点到十一点，几千个学生同时回到宿舍，掏出手机、打开笔记本、连上WiFi。这个时间窗口对校园无线wifi计费系统来说就是一次"考试"——认证请求扎堆、流量峰值飙升、Portal页面同时被大量刷新。一个平时运行得好好的系统，到了晚高峰就可能暴露出各种问题。

高并发场景下最先承受压力的是认证模块。Radius认证协议本身是UDP的，单个认证请求的处理时间很快——通常几十毫秒就能完成。但当几千个请求在几分钟内集中到达时，Radius服务器的并发处理能力就成了瓶颈。如果Radius进程处理不过来，请求开始排队，排队的请求超时后又重新发起，形成恶性循环。最终表现就是学生连上WiFi、弹出认证页面、输入账号密码、点了登录之后转了很久然后提示认证失败。

这个问题的解决方案不是简单地"加服务器"。校园无线wifi计费系统的认证性能瓶颈通常不在硬件上，而在软件架构上。Radius服务的线程模型、数据库连接池的配置、认证日志的写入策略，这些都会影响并发处理能力。有些系统的Radius服务默认是单线程的，不加修改的话不管你服务器配置多高，并发处理能力都不会提升。需要确保认证模块支持多线程或多进程，并且数据库连接池的大小能匹配预期的并发量。

第二个容易出问题的地方是Portal页面本身。Portal认证页面是一个Web页面，几百上千人同时刷新这个页面，对Web服务器的压力很大。如果Portal页面还加载了比较重的资源——大图片、第三方JS库、视频背景——晚高峰时页面加载速度会非常慢，学生可能等不及就直接关掉了。Portal页面应该尽量轻量化：纯文本加少量CSS，资源做CDN或本地缓存，尽量减少HTTP请求数。

第三个问题是BRAS或认证网关的性能。当大量用户同时通过认证后开始传输数据，网关需要同时维护大量会话状态——每个用户的IP、MAC、上下行速率、已使用流量、剩余时长等。如果网关的会话表容量不够，新的会话建不起来，已经认证通过的用户也会掉线。这个问题的隐蔽之处在于：白天流量低的时候一切正常，运维人员看不出任何异常，只有到了晚高峰压力上来了才会暴露。

数据库的写入压力也是一个容易被低估的环节。校园无线wifi计费系统每完成一次认证、每记录一条上网日志、每更新一次用户余额，都要写数据库。晚高峰时几千人同时在线，数据库的写入操作量可能是白天的几十倍。如果数据库没有做读写分离，认证模块的读操作和日志模块的写操作竞争同一套数据库资源，两边都会变慢。建议的做法是：认证相关的高频读写用内存缓存或独立的认证数据库，运营报表和历史日志走离线分析库，物理上分开。

还有一个对用户感知影响很大但技术上不复杂的问题：认证成功后的跳转速度。学生认证通过后，BRAS需要下发授权策略——分配带宽、设置ACL、开通访问权限——然后才能正常上网。这个策略下发的过程如果因为设备处理慢而延迟了十几秒，学生看到的是"明明提示认证成功了但还是上不了网"。这种体验比认证失败还糟糕，因为学生不知道怎么处理，只能反复登录。

对运营团队来说，高并发场景下的监控和告警也非常重要。晚高峰是问题的高发期，如果运维人员不能实时看到当前的认证QPS、成功率和延迟，等学生大量投诉了才知道出问题，就太被动了。校园无线wifi计费系统应该提供实时监控面板，重点指标包括：认证请求QPS、成功率、平均响应时间、当前在线用户数、各出口带宽使用率。一旦某个指标超过阈值，系统主动告警。

高并发优化的方向其实很明确：认证链路做减法——减少每一环的处理时间；数据库做读写分离——高频写入和低频查询分库处理；Portal页面做瘦身——减少不必要的资源加载；网关会话表做扩容——确保设备规格能匹配实际并发需求。这些事情不需要等到上线以后才发现问题，压力测试阶段就应该把这些瓶颈找出来。