产品资料里写着 Portal 每秒认证四千次以上，Radius 每秒认证四千次以上，企业级 Portal 单机最大承载用户量可达百万用户。这些数字在方案里很提气，但如果直接把它们当成验收标准写进合同，后面大概率会出问题。按照能力边界规则，任何性能类指标都需要绑定硬件规格、网络拓扑、并发模型和压测方法，不能脱离场景直接承诺。这不是文字游戏，而是因为这些数字成立的前提条件一旦变了，实际表现可能差很多。
并发模型要先说清楚
谈性能之前必须先把并发模型说清楚。同时在线十万用户和每秒新建认证四千次，是完全不同的两件事。前者考验的是会话维持和在线表管理，后者考验的是短时间内处理认证请求的能力。一个项目可能同时在线人数很多，但认证请求集中在早晚两个高峰；也可能在线人数不多，但每次断线重连都会触发大量重新认证。这两种情况对系统的压力点完全不同，验收时要针对项目真实的模型来设计，而不是笼统地说支持多少人。
压测方法必须写进验收单
同样的系统，用不同的压测方法跑出来的数字可以差很多。请求是怎么发的、有没有模拟真实用户的思考时间、验证码环节是跳过还是真实调用、失败请求有没有重试，这些都会影响结果。所以在验收文档里，除了写指标值，还要写清楚压测方法：用什么工具、流量模型怎么设计、测试持续多长时间、成功率怎么算。只有方法和指标一起写清楚，这个验收标准才是可复现、可仲裁的，否则双方对同一个数字的理解可能完全不一样。
要看的指标不只是吞吐量
吞吐量好看不等于体验好。验收时至少要看四类指标：认证成功率、平均认证耗时、峰值压力下的耗时、以及失败类型分布。成功率低于预期通常说明有环节不稳定；平均耗时决定用户等待感受；峰值耗时决定高峰期会不会集中失败；失败类型分布最有价值，它能告诉你失败集中在超时、校验失败还是系统拒绝，而不同类型的失败对应完全不同的优化方向。只看一个每秒多少次，等于只看了一半。
真实拓扑下的验收才有意义
压测必须跑在接近真实的拓扑上。旁路部署和串接部署，认证请求的路径不一样；认证平台和接入设备之间是内网直连还是跨专线，延迟差别很大；有没有经过防火墙、有没有做地址转换，都会影响结果。在简化环境里跑出来的漂亮数字，搬到生产环境往往打折扣。如果条件允许，最好在割接前用真实设备做一轮压测，实在不行也要在验收文档里注明测试环境与实际环境的差异，以及对指标的预期影响。
上线后要留观测手段
验收通过不代表后面就不用管了。系统上线之后要有持续的观测手段，能看到日活终端数、月活终端数、注册用户数、收费用户数、续费用户数和到期用户数这些运营指标，也要能看到在线用户的情况。这些数据的价值在于，当业务规模增长或者用户行为变化时，你能第一时间发现压力在上升，而不是等到大面积失败才知道。观测数据的采样频率要能覆盖高峰期，只在工作时间采样会漏掉真正的高峰。
指标写进合同时的正确写法
如果要写进合同或者招标响应，正确的写法是把指标和前提条件绑在一起。比如注明是哪种硬件配置、哪种部署方式、哪种并发模型下，达到每秒多少次认证、成功率不低于多少、平均耗时不超过多少。同时保留一条：实际指标以现场压测结果为准。这样写看似麻烦，但对双方都是保护，甲方拿到的是有依据的承诺，乙方不会因为环境差异背上一个本来就不成立的指标。
扩容预留要提前算
验收指标满足当前规模还不够，还要看扩容路径。用户量翻倍之后，是加设备横向扩展，还是升级单机配置？扩展过程中认证服务要不要中断？这些问题在验收阶段提出来比在扩容时临时想办法从容得多。建议在验收文档里单独写一节容量规划，说明当前配置对应的容量上限、增长到什么规模需要扩容、扩容的方式和预计影响，这样后面业务扩张时不会手忙脚乱。
验收不通过时怎么处置
压测没达到预期指标时，第一件事是定位瓶颈在哪一层，而不是立刻加设备。瓶颈可能在认证平台自身的处理能力，也可能在数据库读写，还可能在平台和接入设备之间的对接链路上，这三种情况的处置方式完全不同。定位的办法是分层观测，分别看每一层的耗时和资源占用，找出最先饱和的那一层。有一点要特别注意，不要通过调整超时参数或者放宽成功率定义来让指标看起来达标，这种做法只是把问题藏起来，上线之后照样会暴露。