网络准入认证系统，准入系统的性能评估和容量规划怎么做

准入系统上线后如果认证慢、高峰期超时，用户体验会很差，运维也会被投诉淹没。性能问题往往不是上线后才发现的，而是在规划阶段就没算清楚。网络准入认证系统的性能评估和容量规划，要在部署前做扎实，根据用户规模和接入场景估算系统需要的处理能力，避免上线后才发现性能不够。

先算清楚用户规模和并发量。总用户数是基础，但更关键的是同时在线用户数和认证并发数。一个1000人的企业，同时在线可能只有600人，但早上上班高峰半小时内可能有500人集中认证。准入系统要扛的是峰值并发，而不是平均值。认证并发的估算要考虑用户的上网习惯：上班时间集中开机的企业，早高峰的认证请求会很密集；倒班制的企业，认证高峰会分散到多个时段。把峰值算准，容量规划才有依据。

RADIUS认证的TPS（每秒事务数）是核心指标。准入系统每秒能处理多少次认证请求，决定了高峰期能不能扛住。TPS和服务器的CPU、内存、数据库性能都有关系，也和认证方式有关：纯密码认证快一些，双因子认证因为要等短信或推送，响应时间更长。厂商给出的TPS指标通常是理想环境下的最大值，实际部署时要打折扣，建议按标称值的50%-70%来规划，留有余量。

数据库是性能瓶颈的高发区。准入系统的用户信息、认证日志、在线会话都存在数据库里，认证高峰期大量的读写操作会给数据库带来压力。用户量小的时候用单机数据库没问题，用户量大了以后要考虑数据库的性能优化：加索引、分表、读写分离。日志数据增长快，要考虑归档策略，不能让日志表无限膨胀影响查询性能。数据库的容量规划要包括存储增长预估，按每天产生多少日志来算一年需要多少存储空间。

高可用架构不能少。准入系统是网络的关口，如果准入服务器宕机，所有用户都认证不了，整个网络就瘫了。生产环境至少要双机部署，主备模式或集群模式。主备切换的时间要测试，确保切换期间认证请求不丢失或能自动重试。对于关键业务区域，可以考虑本地认证缓存，准入服务器不可用时，交换机用缓存的认证信息放行已认证用户，减少对准入系统的依赖。

压测是验证性能的有效手段。上线前用压测工具模拟大量认证请求，测系统在不同并发下的响应时间和成功率。压测要覆盖正常认证、拒绝认证、重复认证、异常请求等场景，不能只测正常情况。压测结果要和规划的指标对比，如果达不到要求，就要优化配置或扩容。压测最好在和生产环境配置一致的环境里做，测试环境的结果不能直接代表生产性能。

上线后的持续监控同样重要。性能指标（CPU、内存、TPS、响应时间、认证成功率）要实时监控，设置告警阈值。高峰期的性能数据要定期分析，看趋势是平稳还是在恶化。用户量增长、新业务上线、终端类型变化，都可能导致准入系统的负载增加。容量规划不是一次性的工作，要根据实际运行数据定期回顾和调整，在性能成为问题之前提前扩容。

认证超时和重试机制对用户体验影响很大。准入系统响应慢的时候，交换机会超时重试，如果重试参数设置不当，会产生大量重复的认证请求，进一步加重准入系统的负载，形成恶性循环。交换机的RADIUS超时时间建议设为3-5秒，重试次数2-3次，准入系统的处理超时要和交换机匹配。高峰期如果认证响应时间变长，要先排查是准入系统本身性能不够，还是后端的用户目录（AD/LDAP）响应慢，很多时候瓶颈在目录服务器而不是准入系统。

扩容的决策要基于趋势而不是峰值。偶尔一次高峰不代表需要扩容，要看性能指标的长期趋势：TPS峰值是否在持续增长、响应时间的P95是否在恶化、认证失败率是否在上升。如果趋势在恶化，即使当前还没到瓶颈，也要提前规划扩容。扩容的方式可以是纵向（加CPU内存）、横向（加节点做集群）、或优化（调参数、加缓存、改架构），根据瓶颈的位置选择最合适的方式。不要等系统扛不住了才紧急扩容，那时候业务已经受影响了。

准入系统的性能还要考虑峰值场景的特殊性。除了日常早高峰，还有一些突发场景：网络故障恢复后大量用户同时重连、系统升级后批量重新认证、大型活动期间临时大量用户接入。这些场景的并发量可能远超日常峰值，容量规划要把这些突发场景考虑进去。可以通过限流、排队、缓存等机制在极端情况下保护准入系统不被打垮，保证核心用户的认证优先。

性能监控的可视化很重要。把TPS、响应时间、在线用户数、认证成功率等指标做成实时仪表盘，运维人员一眼就能看到系统当前状态。设置合理的告警阈值，指标异常时自动通知。性能数据还要保留历史趋势，用于容量规划和故障复盘。好的监控不是等出了问题才报警，而是能在性能恶化前提前发现征兆。