上半年接手了一个万人园区的WiFi认证系统性能调优项目，客户投诉集中在每天早高峰和午休时段，认证页面打不开、短信验证码延迟十几分钟才收到、个别区域直接提示"认证服务器不可达"。一开始所有人都把锅甩给出口带宽不够，结果扩容之后问题依旧。后来我们把整条认证链路拆开排查，才找到真正的瓶颈点。

认证页面的加载速度决定了用户的第一印象

Portal认证场景下，用户连上WiFi后跳出的第一个页面就是认证门户。这个页面的加载速度直接决定了用户会不会放弃连接。我们在排查时发现一个很意外的问题：认证门户的前端资源——CSS、JS、背景图片——全部被放在和认证后台同一台服务器上，而且没有做CDN加速。当早上八点半几千人同时连WiFi的时候，这台服务器要同时处理HTTPS证书协商、Portal页渲染、和Radius的认证交互，瞬间CPU就满了。

我们把认证门户的静态资源剥离到一个独立的Nginx反代节点上，只保留认证接口在后台服务器，效果立竿见影。认证页面的首屏加载时间从平均四秒降到了一秒以内，用户基本感知不到等待。这只是第一步。

Radius交互的排队效应远比想象中严重

真正让我们头疼的是Radius协议的交互瓶颈。标准的Radius认证流程是：终端关联AP → AC发起Access-Request → Radius服务器处理 → 返回Access-Accept或Access-Reject → AC下发策略。这个过程在单用户场景下几十毫秒就完成了，看不出任何问题。但在万人园区的高峰时段，同时发起认证请求的用户数可能在几十秒内达到几百甚至上千。

问题的核心在于，大多数WiFi认证系统内置的Radius服务是基于FreeRADIUS二次开发的，默认配置下它是一个单线程事件驱动的模型，并发处理能力受限于CPU单核性能。当几百个Access-Request同时涌进来的时候，后面的请求就得在队列里等着。如果前面的请求因为后端数据库查询慢了——比如去查用户套餐信息、去校验账户余额——整个队列就会堵住。

我们的改进方案分了几个层次。第一层是在Radius前面加了一层UDP负载均衡，把请求分发到多个Radius实例上并行处理。第二层是把用户套餐和账户余额这类不频繁变化的数据缓存到Redis里，Radius处理请求时直接从缓存读，不再每次都去查数据库。第三层最关键：对认证请求做了分级处理。正常续认证（比如用户从一个AP漫游到另一个AP）走快速通道，新建认证走常规通道，批量开户走低优先级通道。这样保证正常的用户体验不受后台批量操作的影响。

数据库连接池才是那条看不见的暗线

压垮骆驼的最后一根稻草往往是数据库。我们在排查过程中发现，WiFi认证系统内部的数据库连接池配置默认只有二十个连接。在高峰时段当Radius并发量大、Portal页面同时有几百人在操作、后台管理界面还有人开着在做查询的时候，数据库连接池很快就耗尽了。一旦连接池满了，所有依赖数据库的操作——认证、计费、日志写入——全部排队等连接，整个系统的响应时间呈指数级上升。

调整连接池大小只是治标，治本的办法是把读和写分离。我们把认证过程中所有只读操作——查询用户是否存在、查询套餐策略、查询密码哈希——全部指向只读从库；所有写操作——记录认证日志、更新最后登录时间、写入计费话单——指向主库。这样读写互不阻塞，连接池的压力直接降了一半。

做完这些改造之后，我们再回头看最初的投诉。不是因为出口带宽不够，不是因为WiFi信号不好，是一整套认证链路里藏着的这些性能暗礁，一个一个地被排查出来、然后一个接一个地炸掉。所以现在如果有人问我WiFi认证系统在高并发下卡不卡，我的回答是：取决于你愿不愿意把认证链路从头到尾拆开来看一遍。