无线Portal上线后，学校最怕的就是晚高峰卡顿：学生连上了WiFi，认证页一直转圈，或者进了网页半天打不开。运维老师第一反应往往是认证服务器不行了，其实卡顿很少是单一原因，通常分布在五层里的某一层。定位不到具体那层，盲目扩容只是把钱扔进水里。下面把这五层拆开讲。
第一层：认证服务器本身
认证服务器承载所有登录请求，晚高峰并发高时，如果处理器或内存跑满，新请求就会排队。我们一般看服务器的实时负载曲线，峰值时段处理器持续高于八成就要警惕。这一层的问题靠加服务器或做集群解决，但得先确认是不是它，别看见卡就加机器。曾有个学校连加三台服务器还是卡，最后发现瓶颈根本不在这一层。
第二层：后端数据库
认证服务器查账号、写日志都要过数据库。如果数据库没做读写分离、索引没建好，高峰期查询会变慢，认证请求跟着卡。我们见过账号表上千万条却没建索引，晚高峰一次登录查询要几秒。这一层的问题用端到端探测和应用层抓包能看清，别只盯着服务器。数据库调优往往比加硬件见效快。
第三层：网络回程
接入点把认证请求送回服务器，这段回程带宽不够或丢包，表现就是连上WiFi进不去。我们一般会测核心到各楼栋的回程质量，晚高峰丢包率高于百分之一就要处理。回程问题常被误判成服务器问题，因为现象都是转圈。分清这两层，靠的是看请求在哪一跳开始变慢，而不是靠猜。
第四层：无线接入点
接入点本身带机量有限，一栋楼塞太多终端，接入点处理器满了，新生连都连不上，更别提认证。我们见过学校为了省钱少布接入点，结果晚高峰接入点过载，认证请求根本发不出去。这一层靠的是接入点密度和带机量规划，不是认证系统能补的。覆盖和容量没做够，Portal背不了这个锅。
第五层：门户页面加载
认证页本身如果引用了外部资源、图片太大，学生打开时就慢，容易被当成认证慢。我们建议认证页做成本地轻量页，不依赖外网资源，加载控制在毫秒级。这一层最容易忽略，因为大家习惯把慢都算到服务器头上。门户瘦身是成本最低的优化，却常被人忘。
怎么分层定位
定位靠的是分段测量：从终端到接入点、接入点到服务器、服务器到数据库，逐段看时延和丢包。我们一般上线时就把各层的监控埋好，卡顿发生时直接看哪层曲线异常。盲扩只是砸钱，分层定位才是正路。把五层各管各的修法记熟，晚高峰来了心里不慌。
缓存和会话保持的坑
认证系统一般会缓存登录会话，避免每开一个网页都重新鉴权。但缓存设太大，服务器内存会被吃满；设太小，学生翻个页就被踢重连。我们建议会话缓存按晚高峰并发的1.2倍留，并且设置合理的过期时间。这个参数上线后要根据真实曲线调，没有一劳永逸的值。缓存调好了，晚高峰的体验能上一个台阶。
压测要模拟真实峰值
很多学校上线前不做压测，或者压测用平均模型，结果晚高峰一上来就崩。我们建议压测直接用摸底得到的峰值模型，并发数、终端类型、请求频率都按真实来。压测时故意把某层打满，看系统怎么降级、怎么恢复。真压测过的系统，晚高峰心里有底；没压过的，只能祈祷。
手机和笔记本的表现差异
实战里有个细节：同一接入点下，手机认证慢、笔记本却快，或者反过来，往往和终端的无线协议、休眠机制有关。我们建议压测和排障时两类终端都覆盖，别只用笔记本测。学生以手机为主，手机的表现才代表真实体验。忽略终端差异，定位会偏，优化也打偏。
告警要和工单打通
卡顿告警别只发消息，最好直接建工单派给值班人，处理完闭环。我们建议告警和工单系统联动，谁接了、处理了多久都有记录，避免告警发了没人管。
无线Portal高峰期卡顿，很少是单一原因，得先定位到具体那一层。服务器、数据库、回程、接入点、门户加载，五层各管各的修法。盲扩只是把钱扔进水里，分层定位才是正路。把监控埋在前面，卡顿发生时才有数据可看，而不是靠运维老师的经验硬猜。