行业资讯 · 发布时间：
在线考试放在台湾节点，容量估算最容易出错的地方，是把“同时在线人数”当成唯一指标。台湾节点承载在线考试系统的并发容量估算，还要看考生何时集中登录、题目如何加载、答案多久保存一次，以及数据库能否接住瞬时写入。若只按平时访问量采购资源，开考几分钟内就可能出现登录排队、页面超时或答案保存延迟。
先把考生人数换成系统负载
并发人数是某一时刻在线的用户数，不等于每秒请求数。容量规划应先列出考试人数、登录时间窗、题目与图片体量、自动保存间隔、交卷方式，再分别估算请求和写入。
举例说，假设一场考试有 5,000 人，考生分布在 5 分钟内进入，平均约每秒 17 次登录；若都挤在 1 分钟内，则约每秒 83 次。若每位考生每 30 秒自动保存一次答案，平均约产生每秒 167 次保存请求；集中开考、网络恢复或批量切换题目时，实际峰值还会更高。以上是用于规划的算术示例，不代表任何特定系统的实测容量。
台湾节点的四类过载风险
登录与开考请求形成尖峰
统一开考、监考人员集中发放口令，都会令认证、会话创建及考试状态查询同时升高。即使应用服务器CPU尚有余量，数据库连接池或身份验证服务也可能先排队。可以设置分批开放入口、提前完成身份校验，并为开考时段单独测峰值并发。
自动保存把轻操作变成持续写入
自动保存有助于降低断线丢答风险，但保存过于频繁、每次都写整份答卷，可能造成数据库写入和锁竞争。保存间隔应结合答案类型、可接受的数据丢失窗口和断线恢复机制确定；选择题与大段文本也不一定适合相同的保存策略。观察写入延迟、失败率和队列长度，而非只看页面是否仍可打开。
题目资源与动态请求争抢资源
静态题图、附件可以通过缓存或内容分发网络减轻源站流量，但这不会替数据库处理交卷、计时和答案保存。若试题页面依赖大量动态接口，或图片未经压缩，开考时仍可能占满节点出口带宽。应分别核算静态资源带宽与动态请求能力，并检查台湾节点到考生所在地的访问延迟；地理位置接近不等于所有网络路径都稳定。
故障余量和交卷尾峰被忽略
考试结束前后，交卷、成绩计算和后台导出可能叠加。若容量按全部资源持续满载来估算，单台实例重启、数据库维护或网络抖动就可能让服务整体降级。应为故障切换、重试流量和临时扩容留余量，并避免客户端在失败后无间隔重复提交。
按步骤做容量估算与验证
- 定义负载模型：记录预计人数、登录时间窗、考试时长、保存间隔、图片或附件比例、交卷峰值，以及需要支持的设备类型。
- 拆分关键链路：分别检查登录、题目读取、答案保存、计时校验和交卷接口，标出依赖的应用实例、缓存、数据库与对象存储。
- 建立基准并发：按预计峰值设计场景，再逐级增加负载。记录响应时间、错误率、CPU、内存、数据库连接数、磁盘与网络指标。压测环境应尽量接近实际部署，避免把测试结论直接套到不同规格或不同网络。
- 测试突发与降级：模拟集中登录、自动保存叠加、短时断网后重连和集中交卷；验证限流、排队、重试及故障切换是否按预期工作。
- 留出可解释的余量：根据压测结果确定安全容量，不以单次“撑住”作为上线标准。峰值并发、请求速率和数据库写入速率要分别记录，并在正式考试前复核近期配置变化。
台湾节点承载在线考试系统的并发容量估算，最终应以业务负载模型和同配置压测结果为依据。CDN能缓解静态内容压力，增加应用实例能提高部分计算能力，但数据库、连接池或出口带宽若已饱和，单纯扩服务器未必解决瓶颈。上线前明确告警阈值和人工处置流程，比只追求一个最大并发数字更可靠。
常见问题
并发人数和每秒请求数有什么区别？
并发人数表示同时在线用户；每秒请求数表示系统单位时间收到的请求。用户操作频率、保存间隔和页面设计不同，同样人数也会产生不同请求量。
静态资源放到缓存后，就不需要做峰值测试了吗？
仍需测试。缓存主要减轻图片、脚本等静态资源的源站负担，登录、答案保存和交卷等动态请求仍需验证应用与数据库能力。
容量估算应该预留多少余量？
没有适用于所有系统的固定比例。应结合压测曲线、故障切换方式、负载增长预期和服务目标确定；至少验证峰值场景下关键接口仍满足既定响应时间与错误率要求。
