2026 年网校服务器租用：卡在开考那一刻的机器要按峰值配

周三晚上八点，一家职业培训机构的网校平台迎来本周唯一的高强度时刻：一场限时在线考试。此前整整一周，监控面板几乎是一条平线，CPU 长期在两成以下，内存占用稳定，带宽只用到零头。运维据此判断这台机器还很富裕，短期内不需要动。但八点整考卷开放的那九十秒里，页面开始转圈，提交按钮点了没有反应，最后一批学生的答卷没有写进去。事后复盘，Web 层的 PHP 进程确实是被占满了，但根因不在 PHP——几千名学生几乎在同一分钟里往同一批表里写答案，行锁和事务队列先排起了长队，排在前面的请求开始超时，超时触发客户端重试，重试又把队列拉长一截，最终表现成 PHP 工作进程全部堵住、页面全部卡住。这台机器不是配置不够，而是它的容量口径错了：它是按日均活跃用户算出来的，而这场考试从来不按日均发生。

开考九十秒的卡顿，通常不是 Web 层慢，而是写入排不上队

网校平台故障复盘里最常见的一类误判，是把表象当成根因。值班的人看到的第一个现象是 PHP-FPM 活跃进程数打满、Nginx 开始返回 502 或 504，于是第一反应是加 PHP 进程数、加内存、换更强的 CPU。改完之后下一次考试可能确实好一点，但过一段时间又会复发，因为真正排队的地方没有被处理。

判断根因有一个简单的分辨办法：如果 CPU 使用率并不高，甚至 idle 还有余量，但系统负载值却明显升高、响应变慢，那么进程并没有在计算，它们在等待。等待有两种来源，一种是等磁盘 IO，一种是等数据库锁。区分这两者也不难：如果数据库所在磁盘的 IO 等待同步升高，且慢查询日志里出现了大量平时不出现的语句，那多半是数据库侧；如果 IO 等待升高但慢查询没有明显变化，则要看是不是备份、cron 任务或者缓存落盘在抢 IO。

把这个分辨动作放在平时做，比放在考试当晚做有用得多。因为考试当晚你没有时间做诊断，只能做重启和扩容这类盲操作。建议在测试环境里提前把「大量学生同时作答」这个场景造出来，记录下数据库侧的锁等待数量、慢查询条数、连接数与 PHP 活跃进程数四条曲线，看清楚在你的环境里究竟是哪一个先到拐点。这四条曲线的先后顺序每台机器都不一样，必须实测。

LMS 的负载是一条长期贴地的平线，加几根位置可预知的尖刺

要理解为什么按日均配机器会翻车，先要理解网校负载的形状。它和绝大多数业务都不一样。

内容站和门户的负载是读多写少、全天相对平滑，峰值出现在热点事件之后，且以读为主，可以被缓存和 CDN 层层挡掉。电商的负载有明显的尖峰，但大促的流量主体是浏览和搜索，真正转化为订单的写操作只是其中的一小部分，而且大促期间用户的到达本身就是分散的，不会精确地在同一个时间点点下去。企业内部的 ERP 是稳态的在线事务处理，负载随上班时间起伏，写操作持续但平稳，数据规模则是在几个月、几年的尺度上慢慢增长。

网校都不是。网校在大部分时间里是空的——学员分散在一周的不同时段看课件，请求稀疏，机器闲得发慌。然后在几个特定的时间点，全部人同时到达，并且到达之后做的不是浏览，而是提交。提交是写操作，写操作不能被页面缓存挡掉，必须落库。这些时间点包括：考卷开放的那一刻、交卷截止前的最后几分钟、作业截止时间前、成绩发布后的集中查询、新学期开始时的批量选课与批量导入。

这里有一个对选型非常关键的性质：这些尖峰的位置是可预知的。考试时间是教务排好的，不是突发事件。这带来两个直接推论。第一，你不需要为日均付费，但你必须为那几个时间点付费，机器规格要按峰值定，而不是按平均值定。第二，正因为峰值位置已知，你才有条件提前演练、提前扩容、提前把重任务挪开——这是网校比电商好办的地方，电商要为不确定的峰值做冗余，网校只需要为确定的峰值做计划。

请求链路拆开看，PHP 只是其中的一段

把一次「学生提交答案」的请求按链路拆开，才能看清楚资源账该怎么算。请求从浏览器发出，经过 HTTPS 到达 Web 服务器，被转发给 PHP-FPM 的某个工作进程，进程执行 PHP 代码（OPcache 决定要不要重新编译），期间读取缓存层获取课程配置与用户会话，然后向数据库写入作答记录，同时写入日志表，最后返回结果。学生端还会周期性自动保存，这意味着一次作答产生的请求数远多于学生手动点击的次数。

链路上每一段的失效模式都不同。Web 层失效的表现是连接数打满；PHP-FPM 失效的表现是活跃进程数到达上限、后续请求排队等待空闲进程；缓存层失效的表现是命中率下降、请求穿透到数据库；数据库失效的表现是锁等待、连接数打满与慢查询堆积；存储失效的表现是 IO 等待升高；定时任务失效的表现是任务积压与在特定时刻抢占资源。

网校的特殊性在于，同一个人从「浏览课件」切到「作答测验」时，请求的性质发生了根本变化。浏览课件以读为主，课程结构、语言字符串、主题资源都可以被缓存挡在数据库之前，读压力是可以被大幅削减的。而一旦进入测验，每一次自动保存都是一条新的写入记录，必须落库，缓存在这里基本帮不上忙。所以一台在平时看起来很宽裕的机器，会在开考瞬间从「读为主」切换为「写为主」，而它所有的配置参数——PHP 进程数、数据库缓存大小、磁盘 IO 能力——都是按读为主的场景调出来的。

在软件版本这一层，先过兼容性门槛。以 Moodle 官方发布的 5.3 版本服务端要求为例，官方列出的最低要求是 PHP 8.3.0（同时支持 8.4.x），仅支持 64 位 PHP，必须启用 sodium 扩展，max_input_vars 必须大于等于 5000；数据库最低版本为 PostgreSQL 17、MySQL 8.4、MariaDB 11.4.0、Aurora MySQL 8.0 与 Microsoft SQL Server 2019，且 Oracle 数据库自 5.0 起不再被支持。这些数字是能不能装上并正常运行的门槛，不是容量建议。Moodle 官方安装文档给出的硬件基线——代码 200 MB、磁盘 5 GB 被视为现实最小值、1 GHz 处理器最低与 2 GHz 双核推荐、内存 512 MB 最低与 1 GB 推荐、大型生产服务器 8 GB 以上——同样是安装基线的口径，不能直接当作「能扛住多少人同时考试」的依据。真正决定容量的是你的课程结构、插件、题目类型与保存策略，需要在自己的环境里实测。

数据库先崩的四个放大器：行锁、长事务、临时表与缺失索引

在峰值型负载下，数据库几乎总是先于 PHP 到达拐点，原因是四个放大器会同时起作用。

第一个是行锁。大量学生在短时间内更新各自的作答记录，如果这些更新落在相同的索引范围或者相同的数据页上，就会形成排队。排队本身不可怕，可怕的是排队会拉长每个事务的持有时间，持有时长一增加，后面的等待就更长，形成一个正反馈。

第二个是长事务。批量批改、成绩重算、报表生成这类操作会把事务开得很长。长事务本身在平时不是问题，但在考试窗口里，它持有的锁会盖在整个写入队列上，把本来可以快速通过的短事务全部卡住。这也是为什么报表类操作必须避开考试时段。

第三个是临时表。成绩统计、分组排序这类查询经常需要在内存里建立临时表来完成排序与聚合。当内存不够用时，临时表会落到磁盘上，于是原本是内存操作的事情变成了磁盘 IO，与正在进行的大量写入争抢同一块盘的 IOPS。

第四个是缺失索引。网校平台里增长最快的表是日志表，它记录几乎每一个用户动作，会持续膨胀。如果没有为它设置保留期限与归档策略，也不做索引审视，那么一段时间之后，原本十几毫秒的查询会变成几百毫秒，在峰值下这点劣化会被放大成系统性的堵塞。

值得强调的是，这里描述的失效模式与稳态业务系统完全不同。稳态系统的数据库问题是长出来的——数据量在半年里慢慢变大，查询在半年里慢慢变慢，运维有充足的时间发现和处理。网校的数据库问题是在几十秒内发生的：前一个瞬间一切正常，后一个瞬间队列已经排满了。这意味着网校的监控告警阈值不能按「平均值超标」来设，而要按「瞬时值突变」来设，并且告警动作要给值班的人留出在几分钟内介入的时间窗口。

峰值容量只能靠估算方法推，不能靠日均活跃用户推

既然峰值决定规格，下一个问题就是怎么估。这里只给方法，不给结论数字，因为任何结论数字都依赖于你的题目类型、插件组合与保存策略，跨环境搬用会出事。

估的第一步是确定同时开考人数，而不是注册人数，也不是日均活跃用户。注册人数里包含大量已经结业的学员，日均活跃用户则把峰值平均掉了，两个都不能用。真正有用的是「单个时间窗口内同时处于作答状态的人数上限」，这个数字由教务排课决定，可以直接拿到。

第二步是确定提交行为的时间分布。这里有两种典型形态：一种是平台开启了自动保存，学生端每隔一段时间把答案异步提交一次，写请求在时间上被摊薄，但总量不变；另一种是学生手动提交，写请求会集中在考试结束前的最后几分钟。前者对瞬时压力的考验小一些，后者会在末尾形成远高于平时的瞬时写密度。你属于哪一种，以及自动保存的间隔是多少，直接决定了后面的算式。

第三步是估算写入窗口。如果是自动保存，窗口近似等于考试时长；如果是集中提交，窗口是最后几分钟。用总写次数除以窗口秒数，就得到需要承接的每秒写请求数量级。这个数量级还要再乘上重试放大系数——网络抖动、页面转圈、学生重复点击都会产生额外的请求，这个系数只有实测才知道。

第四步是校核数据库能不能吃下这个写速率。做法是在测试环境里逐步加大并发，观察响应时间曲线的拐点出现在哪里。拐点一旦出现，再往上加并发就会出现响应时间急剧上升而吞吐不再增长的情况，这个拐点就是你的实际容量上限。所有步骤里的具体数值都必须在你自己的课程规模下实测确定，没有可以直接套用的通用答案。

OPcache 与 Redis 解决的是重复读，解决不了集中写

缓存层在网校平台里是最大的性能杠杆，但它的边界必须讲清楚，否则会给出错误的安全感。

OPcache 的作用是把 PHP 编译后的字节码放进共享内存，避免每个请求都把成百上千个文件重新编译一遍。它占据的是一块共享内存，这块内存不属于任何单个 PHP 进程的私有内存，所以在计算进程池大小时必须先把它扣掉。配置上，max_accelerated_files 要大于你实际安装的代码文件总数（含插件），memory_consumption 要根据运行一段时间之后的命中率与使用率来调整，而不是直接照抄某个常见数值。判断依据很直接：如果 OPcache 状态里显示内存已满或者发生过重启，就说明给小了。

再往上的是 Moodle 的通用缓存 MUC。它默认是写在数据目录下的文件里的，官方文档的建议是把它迁移到 Redis 或 Memcached 这样的内存存储中。会话存放也建议一并迁到 Redis。这里有一条容易被忽略的实践细节：应用缓存和会话最好分开存放在不同的 Redis 实例上，否则在内存压力下，缓存的驱逐有可能把在线考试的会话一起清掉，那后果比慢一点严重得多。另外，多节点部署时要让每个节点的本地缓存目录指向本机的本地磁盘，官方文档对把数据目录放在网络共享存储上的性能问题有过明确提醒。

但缓存解决的是重复读。学生保存答案的每一次写入都是新数据，必须落库，缓存一条都挡不掉。缓存真正的作用是把原本也在消耗数据库、消耗 CPU 的读请求挡在前面，从而为写入让出资源。这个让出很关键——它决定了峰值时数据库能把多少能力分配给写操作——但它不改变写入的总条数。

还有一条运维铁律：不要在高峰期清空缓存。清缓存会让所有页面在同一时刻重新构建，等于人为制造一个尖峰。缓存清理应该安排在低峰时段，且只在代码或主题变更之后执行。

cron 和备份必须让开考试窗口，否则它们就是最后那批压上来的进程

Moodle 的后台任务机制对 cron 频率有明确要求。开发者文档在任务 API 的说明里写得很直接：任务运行的频率取决于 cron 运行的频率，建议 cron 至少每分钟运行一次，才能从任务调度中获得最大收益。同时官方建议通过命令行脚本调用，而不是通过 HTTP 请求触发——后者会额外消耗内存，并且受 Web 服务器超时设置的影响。

这里有一个常见的误解，以为「每分钟跑一次」意味着每分钟都在做重活，担心会拖慢站点。实际上并不如此：计划任务各自有自己的调度周期，cron 只是每分钟起来检查一次有没有到点的任务，没有活就很快退出。真正危险的是相反的情况——如果 cron 被限制成每 15 分钟或 30 分钟才能跑一次，那么它每次起来都要集中处理积攒了一刻钟的队列，这一次的负载反而可能很重。

更危险的是这份负载恰好落在考试窗口里。课程自动备份是处理器密集型任务，官方文档明确提醒它不应安排在大量学生在线的时段。报表生成、日志清理、批量发送通知同样如此。这些任务在平时跑毫无感觉，在开考的九十秒里跑，就是压上来的最后一根稻草。

正确的做法是把重任务显式排到业务低峰，并且与教务的考试日程对齐。如果平台是集群部署，cron 应当集中在专用的任务节点上运行，而不是每个 Web 节点各跑一份。此外还要盯住数据目录里的待清理目录——清理它的是一个定时任务，如果 cron 不跑，这个任务也不跑，空间就会在系统没人注意的角落里悄悄长起来。

课程资源是顺序读的大文件，元数据是随机小文件，两种 IO 要分开算

存储很容易被当成「容量问题」来处理，实际上它同时是容量问题和 IO 特征问题，而这两者的账要分开算。

视频课件与 PDF 讲义属于大文件顺序读，主要消耗的是吞吐与出口带宽，容量增长快但 IO 特征温和。而数据目录里的文件池、缓存目录、临时目录、待清理目录则充满了小文件的随机读写，消耗的恰恰是 IOPS。一个堆满了小课件附件的网校和一个放了几百个视频的网校，即便总容量相同，对磁盘的要求也完全不同。

数据目录的空间增长有几个明确的来源，每个都有对应的治理手段。文件池存放真实内容，增长由课程资源决定；待清理目录存放已解除引用但尚未删除的内容文件，由一个定时任务按周期清空；自动备份区受备份存储位置、每课程保留份数上限、按天数删除策略以及保留下限这几个设置共同控制；回收站则保留被删除的课程与活动，直到过期设置把它们清理掉。这几个环节的保留策略如果都不设上限，磁盘就会在几个学期之内被慢慢填满，而且填满的那天往往正好是业务最忙的时候。官方文档也提醒过，课程备份不应该被当作站点的主备份来用——它通常落在与站点相同的存储卷上，需要另外配置真正脱离本机的备份。

基于这个特征，视频这类大文件建议外置到对象存储或外部视频平台，只以嵌入的方式出现在课程里，不要让它们占满本机的数据盘。这样既把容量增长转移出去，也把顺序读的吞吐压力从本机挪走，本机只留下随机小文件这类真正需要 IOPS 的负载。

选机器时先定单核性能，再定核数，最后才谈内存

CPU 这一项最容易被选错方向。PHP 请求的执行在单个进程中是串行的，一个请求跑得快不快，取决于单核性能，而不是核数。核数决定的是能同时并行处理多少个请求，它解决的是并发量，不是单请求延迟。所以排序应该是先定单核性能，再定核数，最后才是内存。

内存这一项则直接决定 PHP 进程池的上限。PHP-FPM 的进程数上限有一个明确的算式：可分配给 PHP 的内存总量，除以单个工作进程在真实负载下的平均常驻内存。这里有三个要点。第一，单个进程的常驻内存必须实测，不同插件、主题与题目类型之间的差距可能非常大，用别人环境的数值代入会得到完全错误的结果。第二，OPcache 的共享内存要从可分配总量里先扣掉，因为它是共享的、不计入单个进程的私有内存。第三，如果数据库与 Web 部署在同一台机器上，InnoDB 缓冲池还要再切走一大块，峰值时进程池、数据库缓存与操作系统会同时要内存，必然有一方被牺牲。

这就引出一个取舍：同机部署省钱，但峰值时三个消费者争抢同一份内存，任何一个都可能先撑不住；把数据库拆到独立机器上，内存可以几乎全部给缓冲池，Web 端也能把更多内存留给进程池，代价是多一台机器的成本与一层网络往返。什么规模该拆，取决于实测出来的拐点位置，不是一个固定的用户数门槛。

磁盘的 IOPS 保障比容量更值得问，数据盘和系统盘要分开

选存储时，容量是最容易谈的一项，也是最不重要的一项。真正决定峰值表现的，是这块盘在压力下还能提供多少随机读写能力，以及这个能力是有保障的还是共享突发型的。

共享突发型的存储产品在日常轻载时表现良好，因为突发额度没有被消耗；但一旦进入持续高负载，额度耗尽之后性能会掉到很低的水平，而网校的考试峰值恰恰是一个持续几十分钟的高负载场景，正好落在最不利的区间。所以在下单之前，要向服务商确认的是 IOPS 的保障方式，而不是标称容量。

物理结构上，系统盘和数据盘应该分开。系统盘放操作系统与程序代码，容量需求小且稳定；数据盘放数据目录与数据库文件，容量增长快、IO 压力大。分开的好处有三个：容量增长不会威胁系统盘的可用空间；随机 IO 不会与系统盘的读写争抢；做快照与重装系统时，两块盘互不牵连。介质上优先选择固态存储，机械盘在小文件随机读写上的表现与固态介质差距明显，而网校数据目录的主要 IO 特征正是小文件随机读写。

机房要看峰值是否限流、快照窗口能否自定、访问路径怎么走

机房层面的三个问题，直接决定峰值当晚会怎么过。

第一个是峰值是否受限。带宽产品有的按固定带宽计费，有的按实际流量计费，有的采用共享带宽。对网校来说，峰值是必然发生的，所以必须问清楚：峰值时段是否存在限制，限制的口径是按瞬时值还是按一段时间均值，超出之后的处理方式是什么。这一条如果没问清楚，考试当晚被限速是最难处理的一类事故，因为它不在你的机器上，你改不了任何配置。

第二个是快照与备份窗口能不能自己定。自动快照如果固定在某个时间点执行，而那个时间点恰好是你业务的高峰，就会在最不该发生 IO 抖动的时候发生 IO 抖动。要确认快照时间能否自定义、快照执行期间对 IO 的影响有多大、保留几份、恢复一次需要多长时间。更重要的是确认恢复是真正被演练过的，而不是只在文档里存在。

第三个是访问路径。学员集中在内地的话，节点位置决定了访问路径的长短与稳定性，需要结合实际学员分布去选；学员分布在海外、或者做的是面向海外的中文教育，那么把节点放在中国香港或者目标区域附近的海外节点，通常能明显改善访问路径，减少跨区域跳转带来的不确定性。访问路径这类问题不能在考试周才第一次验证，应该在选型阶段就用真实学员分布做一次访问测试。价格方面，机房、带宽与机型的具体报价需询价，以官网实时报价为准。

成本构成里，机器费只是其中一块

估算网校平台的投入时，机器租金往往只占一部分。完整的成本清单大致有这几项：服务器本身的租金，由机型、内存、磁盘规格决定；带宽费用，由计费方式决定；IP 地址；快照与备份存储，随课程资源增长而增长；如果数据库与缓存各自独立部署，则还要各算一台；证书、监控与告警；版本升级与插件兼容性验证投入的人力；演练与考试期间的值守。

容易被漏掉的是后面几项。版本升级不是点一下按钮的事，自定义插件需要在测试环境里逐项验证，否则一次升级可能正好在考试周把平台搞挂。演练需要造数据、需要有人盯、需要在考试周之外占用时间。考试当晚的值守需要有人在线，且这个人要有权限、有能力做应急操作。这些都是真实成本，且在总账里的占比并不低。

还有一类隐性成本来自规格不足导致的返工：机器选小了，考试期间出问题，事后再迁移、再升配，所花的成本通常远超一开始把规格定够的差价。所以对网校这类峰值型业务，成本优化的方向不是把平时闲置的资源砍掉，而是把峰值时真正需要的资源准备足，同时通过缓存与任务调度把峰值削平。价格性质上，本文涉及的所有价格项均需询价，以官网实时报价为准。

演练与验收：把开考那九十秒提前在测试环境里跑一遍

配置定完之后，还差最后一步——验证。没有经过演练的配置只是假设。

演练的做法是：准备一台与生产规格一致的测试机，导入与生产规模相当的课程与账号数据，按真实考试时长组织并发作答，然后逐步加大并发，直到响应时间出现明显拐点。记录在这个过程中数据库侧的锁等待数量、慢查询条数、连接数、PHP 活跃进程数、IO 等待与磁盘余量。这些曲线里最先到达拐点的那一项，就是你下一次该扩容的地方。

验收的指标不能只写「页面能打开」。对网校来说，有意义的指标是：提交成功率、响应时间的分位值而不是平均值、慢查询条数、cron 任务积压量。平均值会把最慢的那批请求掩盖掉，而最慢的那批请求恰恰是交卷失败的那批学生。

演练还要注意两点。一是要在考试周之外做，且要在每次大版本升级、每次新增重要插件之后重做，因为代码变化会直接改变资源消耗曲线。二是演练规模要按最坏情况设定，即按教务能排出的最大同时开考人数，而不是按上一次的实到人数。

网校平台上机器前最该避开的几个坑

• 按注册人数或日均活跃用户定规格，而不是按同时开考人数定规格
• 用共享虚拟主机来跑，结果 cron 被限制到十几分钟甚至半小时才能跑一次，且无法用命令行调用
• 把数据目录放在 Web 根目录下，导致作业、备份与会话文件可以通过 URL 直接访问
• 应用缓存与会话共用同一个 Redis 实例，内存压力下缓存驱逐把在线会话一起清掉
• 把课程自动备份安排在晚上八点，而那正是学员集中上线的时段
• 把视频课件直接上传到课程里，让大文件吃满数据盘容量与吞吐
• 备份从没恢复过，直到真的出事那天才发现备份不可用
• 在考试周做版本升级或安装新插件
• 从没打开过慢查询日志，故障复盘时只能靠猜测
• 平时不看磁盘余量，直到自动备份写入失败才被发现

关于网校服务器选型的几个常见问题

学员只有两千人，需要上集群吗

规模不是判断依据，并发形状才是。两千人如果分散在一周里学习，单台机器通常够用；如果这两千人在同一时刻开考，那就必须按同时开考人数重新算。判断的依据是实测出来的拐点，不是一个用户数门槛。

考试分批进行和同时进行，差别有多大

差别很大，而且是决定性的。分批把峰值摊到了不同时间窗口，瞬时压力成倍下降；同时进行则把全部压力压在一个窗口里。教务排课时把大考场拆成几个批次，往往比升配机器更省钱，且效果立竿见影。这件事应该在配置选型之前就与教务对齐。

把自动保存的间隔调长一点，能缓解峰值吗

能摊薄瞬时密度，但不会减少写入总量。如果学生本来会在考试末尾手动提交，那么调长自动保存间隔反而可能让末尾的集中提交更集中。调整之前要先看清自己的提交行为属于哪一种形态，并在测试环境里验证调整后的实际效果。

数据库一定要单独一台机器吗

不一定。同机部署在规模不大时完全可以工作，代价是峰值时进程池、数据库缓存与操作系统争抢同一份内存。拆分的临界点应由实测决定：当你在演练中观察到内存侧的争抢先于其他资源到达拐点时，就该拆了。

考试当天临时升配来得及吗

技术上可行，但风险不小。临时升配通常涉及迁移或重启，而迁移本身是有风险的，且新规格没有经过演练验证。更稳妥的做法是在考试季之前完成扩容与演练，把规格准备好。如果确实需要临时调整，也要确认服务商的生效时间与操作方式。

升级 Moodle 版本会影响考试吗

会影响，所以要避开考试周。版本升级涉及插件兼容性验证，而插件问题往往要在真实负载下才暴露。稳妥的做法是在测试环境用生产数据演练一遍完整考试流程，确认无误后再切，且把切换放在业务低峰。

关于网校峰值负载与配置取舍的几条判断线

第一条：规格按峰值定，成本按峰值算，但钱要花在刀刃上。网校的机器在大部分时间是闲置的，这是这类业务的固有代价，接受它才能换来考试那几十分钟的可靠。想在平时省钱而把规格压到平均值水平，代价会在最不能出事的那一天集中兑现。

第二条：CPU 优先单核性能，内存优先给进程池与数据库缓存，核数排在最后。单核性能决定单个请求的下限，内存决定并发上限，核数只在这两者都满足之后才值得加。用核数去掩盖单核性能不足，通常会得到一个纸面规格好看、实际响应更慢的结果。

第三条：数据库先于 PHP 到达拐点，所以优化顺序是数据库优先。索引、慢查询、保留策略这些事情的收益，通常大于把 PHP 进程数再翻一倍。进程数翻倍只是让更多请求排队等锁，等于把堵车现场修得更宽。

第四条：缓存与任务调度是削峰工具，不是扩容替代品。它们能把峰值削平一截，为写入让出资源，但不能减少写入条数。当削峰之后的峰值仍然超过实测容量，就必须真的加资源，这时候不要再用调优来拖延。

第五条：重任务与考试窗口必须物理隔离。自动备份、报表、日志清理、批量通知都要排在业务低峰，且与教务日程对齐。这条几乎不需要成本，但能避免掉相当比例的考试事故。

第六条：演练的优先级高于配置本身。一套没有被演练验证过的配置，无论参数看起来多合理，都只是假设。而演练的结论会随版本与插件变化，所以要定期重做，不能一次做完就永久有效。

一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体机型、带宽与报价以官网实时信息或咨询确认为准。

网校平台部署的口径与来源说明

本文讨论的是网校类学习平台在自建部署场景下的负载形状、资源账与选型思路，具体包括：峰值型负载的成因、请求链路各段的失效模式、数据库在集中写入下的表现、峰值容量的估算方法、缓存层的边界、定时任务与备份的排程、存储增长与 IO 特征、机器规格的决策顺序、机房选择要点、成本构成与演练验收。

本文不比较任何具体服务商或云产品的优劣，不给出任何并发用户数承诺或未经核实的性能参数，不指向任何具体客户，也不构成性能或可用性承诺。文中出现的容量相关数字均为估算方法的说明，实际数值需在自有课程规模下实测确定。文中场景为通用示例，用于说明负载形状的推理过程，不对应任何具体机构。

本文引用的版本兼容性要求来自 Moodle 官方开发者文档与官方发布说明中关于服务端要求的条目，涉及 PHP 版本、PHP 扩展、PHP 参数设置与数据库最低版本；关于 cron 运行频率的建议来自官方开发者文档中任务 API 的说明；关于数据目录存放位置、缓存配置与自动备份执行时机的提醒，来自官方文档中的相关条目。官方文档同时说明，其列出的硬件数字属于最低支持版本与安装基线口径，官方亦建议将各类软件保持更新。本文据此将其作为兼容性门槛使用，未作为容量结论使用。

本文不涉及任何具体机型、带宽与价格的报价，相关项目均需询价或以官方实时信息为准。

一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体的机型、机柜、带宽与报价，仍要以官方实时信息或咨询确认为准。