A：很多时候是因为系统平时只处理两三个人的请求，数据库应对自如，觉得完全没压力。但几百个人同时点开同一个测评链接，系统要在同一秒去数据库里查几百次题目内容。这就好比平时去食堂打饭不用排队，下课铃一响几百人瞬间涌向同一个打饭窗口，窗口师傅直接就蒙了，打饭速度断崖式下跌。
比较快且有效的解决办法，是把题目这类的固定内容缓存下来。打个比方，就是把题目提前印成小抄发给大家，让大家直接从缓存里拿卷子，别再去疯狂敲数据库的门。这样系统的抗压能力立刻就能上好几个台阶。
Q：页面一直在转圈，到底是服务器带宽不够还是内存爆了？
A：都有可能，遇到这事千万别瞎猜。你可以直接看云服务器的控制台监控面板。
如果 CPU 占用率一直飙在 90% 甚至 100%，多半是代码里有耗时的计算，或者是数据库查询太慢，硬生生拖垮了整个系统。
如果看到是带宽跑满了，那可能是页面里包含了一些大尺寸图片、音频或者视频文件，几百人同时下载，直接把服务器那根细细的网线撑爆了。这种情况下，可以考虑把静态资源单独摘出来，放到专门的云存储对象上，别让它们跟主服务器抢通道。
Q：大家都在同一秒疯狂点提交，会不会出现交不上、丢数据或者重复交卷的情况？
A：如果系统后台没做好排队和限制，确实极易发生这种灾难。学生看到页面卡住，习惯性地就会一直狂点提交按钮。
这就要求我们在前端页面上做好防抖处理：只要点了一次提交按钮，按钮立马变成灰色“提交中”状态，不让点第二次。另外后台也要有个稳妥的机制来按顺序处理这些涌入的数据。橙星云技术团队在应对这类几千人甚至上万人的集中测试时，通常会引入专门的队列机制，就像在检票口拉起了排队警戒线，所有提交的卷子先老老实实按顺序领个号码牌，系统再根据自身能力去逐个把数据稳妥地写入库中，既不会出现卷子丢失，也坚决杜绝了重复计分的问题。
Q：我们买的是最基础普通的云服务器，能扛得住全校一起做测评吗？
A：坦率地说，这就完全取决于系统底子的好坏了。
基础款普通服务器资源非常有限，如果这套测评系统写得很笨重，查个分数都要卡两三秒，那几百人一进来肯定直接崩溃。但如果代码逻辑优化得到位，很多页面做了静态化处理，不怎么消耗数据库资源，那么普通配置的服务器也能同时应付不少人。
不过，如果遇到全校期末大型测评这种关键时刻，最稳妥的解决办法还是花钱买心安：提前一两天去控制台把服务器的带宽、内存临时升级一下。等考完试再把配置降回来，总共也花不了几个钱，却能避开系统崩溃带来的无数后续麻烦事。
Q：学生反馈题目里的图片加载太慢，卡在第一页过不去怎么办？
A：这往往是因为题目里的图片本身实在太大了。很多老师在后台录入题目时，直接拿着手机拍的高清原图就传上去了，一张图片动辄三五兆。一两百个人同时刷这张图，服务器带宽瞬间就见了底。
建议在后台设置一个自动处理机制：上传图片的时候，系统直接把图片尺寸压小，或者自动转码成体积更小的格式。做测评只要在屏幕上看清文字、认清图形就行了，完全没有必要去用那种能印巨幅海报的高清无损大图，强行加载只会白白消耗所有人宝贵的时间。
Q：明天就要大规模测试了，有没有什么立竿见影的办法，能马上缓解可能出现的卡顿？
A：马上就要考试，这时候去改系统代码肯定来不及了。临时抱佛脚的话，有两个极其管用的招数。
第一个招数，刚才也提到了，就是直接去云后台操作，把服务器的临时带宽往上拉满，CPU 核心数加上去，用钱砸出一点性能空间。
第二个招数，也是学校里最常用且不花钱的办法：人为错峰分批进场。比如高一年级 8 点开始测，高二年级 8 点 15 分再进场。只要把人群分散开，别让全校所有人都在同一个 10 秒钟内点击“开始答题”或者“提交试卷”，服务器瞬间承受的并发压力就会呈指数级下降。
Q：做完测评后出报告特别慢，甚至直接超时报错，这该怎么查？
A：测评报告的生成往往是整个系统里最耗费计算资源的一步。它不仅要算总分，还要根据不同的维度去匹配评语，甚至还要生成图表、把结果导出成文件。
如果出报告慢，最该排查的就是算分逻辑是不是写得太绕，查数据库次数是不是太多。有些系统每算一个维度的分就要去数据库里拉一次数据，十个维度就拉十次，效率极低。
比较好的做法是答题一结束，系统先立马给用户返回一个“交卷成功”的提示让他安心离开，然后让后台偷偷去慢慢算分生成报告。等几分钟后算好了，再通过系统消息通知用户去查看，这就巧妙地避开了大家死盯屏幕等待带来的卡顿焦虑。