压测报告上写着支持五千人同时在线，听起来很稳，可真到普查那天，两千人陆续交卷时接口反而先卡了。问题出在压测用错了指标：把同时在线当成压力上限，却忽略了心理测评真正的压力峰值来自交卷这一下。
同时在线衡量的是连接数或停留人数，这些人大部分时间在读题、思考、翻页，请求稀疏，而且多是轻量的读操作。五千人在线，服务器实际承受的每秒请求可能并不高。读操作还常有缓存兜着，压力被进一步摊薄，这更让在线人数这个数字显得漂亮。它适合用来看长连接和会话保持撑不撑得住，却代表不了写入压力，拿它当容量结论会高估系统的真实余量。
为什么交卷 QPS 更接近真实峰值
交卷是一次典型的重操作：要落库答案、触发计分、生成报告，可能还要写预警和回调。心理普查又有个特点，铃声一响或临近截止，大量学生会在几分钟内集中提交，交卷请求瞬间冲高。真正决定接口扛不扛得住的，是这个每秒交卷数，也就是提交接口的 QPS，而不是同时挂着的人数。橙星云在为学校做普查前的容量评估时，就是按预估的集中交卷峰值去压提交链路，而不是只看在线人数好不好看。
瓶颈常常不在接口本身
交卷这条写链路上，最先垮的常常不是接口本身，而是它拖着的下游：写库的连接池、算分的计算、生成报告的排版、推预警和回调的外部调用。任何一环在尖峰下变慢，都会顺着链路把交卷接口一起拖住。所以压测要连着下游一起压，只压一个空接口，测出来的数字再漂亮也测不出真实瓶颈。
更贴近真实的压测，应该把两类指标分开设计。用同时在线数去验证连接层和读接口的承载，用集中交卷的 QPS 去压提交、计分、报告这条写链路，还要模拟短时间内扎堆提交的形状，而不是把请求平摊到一小时。只测平均值，系统会在真实的尖峰面前露怯。
光看 QPS 也不够，还要盯住尖峰下的响应时间和错误率。交卷高峰时平均延迟可能还好看，可 P99 已经飙到几秒，个别学生转圈半天提交不了、甚至超时后反复点击，反而制造出更多请求。所以压测的通过标准，应该是在目标交卷 QPS 下，P99 延迟和错误率都守在可接受范围内，而不是只看吞吐量的数字够不够大。
所以选指标的标准很朴素：看哪个动作最重、最容易扎堆。心理测评里那个动作是交卷，压测就该以交卷 QPS 为主、同时在线为辅。把峰值形状测对了，上线当天才不会被一个本该早发现的瓶颈打个措手不及。