网络计费系统在低负载时运行平稳，一到高峰期就开始卡顿甚至拒绝服务，这是运维团队最常遇到的性能问题。认证网关作为用户上网的第一道关口，一旦成为瓶颈，影响的是几千甚至几万人的网络体验。排查性能瓶颈不是盲目加硬件，而是要准确定位瓶颈在哪一层。

一、性能瓶颈的典型表现

高峰期最常见的现象是认证延迟升高。平时认证只需要几十毫秒，高峰期可能要几秒甚至超时。用户连接WiFi后转圈半天，最后提示认证失败。这种情况通常是认证网关处理能力达到上限，请求排队等待。

第二种现象是计费报文丢失。用户明明在线使用，但计费系统显示该用户已下线，或者流量数据长时间不更新。这是因为网络设备发送的Accounting报文在网关处积压，部分被丢弃。丢报文直接影响计费准确性。

第三种现象是数据库锁等待。大量认证请求同时查询用户数据库，数据库的连接池耗尽，新请求等待连接超时。这种情况在开学季或大型活动时特别明显，几千人短时间内集中认证，数据库瞬间承压。

二、逐层排查的方法论

第一层看网络链路。认证网关到网络设备、到RADIUS服务器、到数据库之间的网络带宽是否够用。高峰期用ifconfig或sar看网卡的包量和带宽利用率，如果网卡跑满了，问题在网络链路，不在计费系统。解决方法是增加链路带宽或做链路聚合。

第二层看网关进程。用top或htop看CPU和内存使用率。如果CPU打满，看是哪个进程占用的。认证网关的工作进程如果都在忙，说明请求处理速度跟不上到达速度。这时候要看是认证逻辑慢还是外部依赖慢。在代码里加耗时埋点，测量每个认证请求在各个阶段（接收报文、查数据库、生成响应、发送报文）的耗时。

第三层看RADIUS服务器。RADIUS服务器收到请求后，处理时间主要花在数据库查询上。如果一条认证请求的数据库查询耗时超过50毫秒，几千并发请求会让数据库连接池瞬间耗尽。检查数据库的慢查询日志，看认证查询是否走了索引。很多性能问题追到最底层，都是数据库索引缺失或不合理。

第四层看数据库。数据库的连接数、CPU、内存、磁盘IO，哪个先到上限就是瓶颈。连接数不够用就增加连接池大小，CPU不够用就看是否有慢查询，磁盘IO高就看是否可以加缓存。数据库层面的优化往往收益最大。

三、常见的性能陷阱

第一个陷阱是认证查询没有走索引。用户认证时，系统根据用户名查询用户表。如果用户名字段没有建索引，每次认证都是全表扫描。用户表只有几千条记录时感觉不到，一旦超过十万条，每次查询的耗时就会显著上升。解决方法很简单，给用户名字段加索引。但有些计费系统的认证查询逻辑复杂，涉及多表关联，索引优化不是加一个索引就能解决的。

第二个陷阱是日志同步写入。计费系统每收到一条计费报文就写一条日志记录。如果日志写入是同步操作，每条记录都要等磁盘写完才能处理下一条请求。高峰期报文量大，磁盘IO成为瓶颈。解决方法是把日志写入改为异步批量写入，先写内存缓冲区，再批量刷盘。但异步写入的风险是系统崩溃时缓冲区的数据会丢失，需要权衡。

第三个陷阱是会话表膨胀。每个在线用户在计费系统中都有一条会话记录。如果用户下线后会话记录没有及时清理，会话表会越来越大，查询变慢。有些计费系统只在收到Accounting-Stop时清理会话，遇到异常断开就会留下僵尸会话。解决方法是设置会话超时机制，超过一定时间没有更新的会话自动标记为离线并清理。

四、容量规划和压测

性能问题最好在上线前通过容量规划和压测来预防。首先估算峰值并发量。校园网的峰值通常出现在开学季的晚上，所有学生同时认证。企业网的峰值出现在早上上班时段。根据峰值并发量倒推系统需要多少CPU、内存和数据库连接数。

然后用压测工具模拟峰值负载。RADIUS压测工具可以模拟大量并发认证请求，观察系统在不同负载下的响应时间和成功率。压测不是跑一次就完事，要逐步加压，找到系统的拐点。拐点之前系统响应稳定，拐点之后响应时间急剧上升。系统的日常运行负载应该远低于拐点。

压测时要监控所有层面的指标。只看认证成功率不够，还要看响应时间分布、数据库连接使用率、磁盘IO等待时间。有些系统在百分之九十九的请求都能成功认证的情况下，百分之一的请求响应时间超过十秒，这些用户就是投诉的来源。

性能瓶颈排查是经验活，做得多了就会形成直觉。但直觉不能替代数据。养成看监控数据的习惯，用数据说话，比靠猜靠谱得多。系统上线后持续监控核心指标，在瓶颈出现之前就做扩容，才是正确的运维姿势。