万人在线考试需要同时保障集中入场、持续保存答案、集中交卷和考后结果处理。百分考采用多实例服务、共享数据与异步阅卷机制，并已积累三万人完整考试业务链路压测、平台四万多名考生同时在线的实际运行记录。组织者可以结合这些证据和本场题型、终端、监考方式，确认适合自己的考试方案。
从三万人压测到四万人运行，分别验证不同场景
百分考既有三万人压测采用单企业百万道模拟试题背景，三万名独立考生在60秒内通过免登录登记进入考试。测试包含取卷、每人50次答案保存、正式交卷和结果处理，固定卷与随机卷分别测试，覆盖一次考试的主要业务过程。
该测试使用双Nginx入口、5个8 vCPU / 16 GiB应用实例，以及独立部署的MySQL、Redis和RabbitMQ。固定卷测试中，答案保存P95为48.6毫秒，交卷受理P95为728.4毫秒。P95表示该次测试中，对应接口约95%的请求耗时不超过这个值；交卷受理耗时不等于最终出分时间。
实际运行方面，2026年9月24日上午，多家企业考试窗口重叠，百分考平台峰值同时在线考生超过四万人。这是多租户平台在当次配置与动态扩容条件下的运行规模，包含同期不同企业，并非某一家企业同一秒进入同一场考试。
两类证据回答不同问题：压测检验明确负载模型下的承载表现，实际运行记录说明不同企业、题型和考试规则共同使用时的业务交付。普通考试业务链路的结果不能直接换算为同规模多路视频监考能力。
集中入场，让取卷与身份处理有足够承载空间
大型考试的压力往往从开考时集中到达。员工需要确认账号或报名信息、进入正确考试，再取得本次试卷；随机组卷还要按规则形成各自的题目集合。
百分考由统一入口分发业务请求，多实例共同处理考试任务，数据库与缓存承接共享数据。考生的后续请求可以由不同实例继续处理，不依赖某一台应用服务器独自保存整场考试状态。
对组织者而言，这种结构提供了按整体业务负载配置应用资源的基础。安排统一开考时，应提前确认预计同时在线人数、集中入场窗口、试卷组成和身份核验要求，再据此准备容量与考务支持。
持续作答，保存答案并保留本次实际卷面
考试过程中，系统持续接收答案保存。考生重新进入尚未结束的答卷时，按考试规则读取已保存内容继续作答；断网期间未成功保存的内容，不能视为已经交付到服务器。
随机题目在本次答卷开始时确定，刷新、恢复或重新进入同一份答卷不会重新抽题。题目、显示顺序和评分所依据的卷面随答卷保留，方便考后核对员工当时实际回答了什么。
考前通知应说明保存反馈、限时规则和异常联系入口。遇到设备或网络问题，先确认当前答卷状态，能继续原作答时继续，不要直接要求员工重开一次考试。
集中交卷，把答卷提交与后续阅卷分开处理
多人接近同一时间结束时，交卷请求会集中到达。百分考把交卷受理与后续阅卷、结果处理分开推进，让作答结束与评分工作各自完成。系统按答卷状态处理提交，防止重复请求生成重复的交卷结果。
客观题按规则判分；需要人工批改的答卷进入后续阅卷。问答题评分和复核可能晚于考生交卷，因此大型考核应分别告知交卷截止时间、预计成绩确认时间和查询方式。
这也让阅卷工作能够按人员权限分工。考务人员先确认答卷是否完成提交，阅卷人员处理评分，负责人再安排正式成绩公布、导出和达标发证。
真实考核交付：三家企业27375份答卷与考后发证
在2026年9月24日的运行记录中，选取的三家企业当天分别完成7685、7634和12056份答卷，合计27375份；对应答卷在考后完成评分并满足条件后，累计签发21672张电子证书。四万多名同时在线考生还包括其他企业，不能与这三家的当天答卷数混为同一统计范围。
这些考核包含移动端人脸核验与周期抓拍、混合题型和子管理员人工阅卷，以及单题限时、禁止返回的作答规则。它们展示了大规模考试从入场和答题到阅卷、结果交付的实际应用。
正式开考前，把容量与实际考试方案一起确认
同样是万人规模，集中一分钟入场和分时进入、客观题与图片答案、普通考试与三路视频监考，对资源和组织工作的要求不同。已验证的考试规模应结合本场配置使用，不能只用一个人数概括所有场景。
- 明确参加总人数、预计同时在线人数，以及最集中的入场和交卷窗口。
- 确认固定或随机试卷、题量、图片和音视频材料，以及阅卷方式。
- 确认电脑、手机网页和小程序的实际参加路径；视频监控考试使用电脑作答，副摄另备手机。
- 提前完成账号、设备与入口试用，安排考务联系人及阅卷负责人。
- 确认监考资源、容量方案和结果公布安排；普通考试与音视频监考分别评估。
