Lesson 11 练习

改 code.py（零依赖压测器 + mock server）观察压测曲线变化。

练习 1：调 mock server 的容量，看拐点移动

code.py 的 mock server 模拟「超过容量就延迟飙升/报错」。找到容量参数，把它调大一倍，重跑不同并发数的压测，观察 P95 拐点和错误率上升点是否右移。

思考：压测的目的不是「跑出一个 QPS 数字」，是找到拐点——服务在多少并发下开始劣化。容量翻倍，拐点右移，这就是扩容的直接收益。

在压测结果里对比「平均延迟」和「P95 延迟」。构造一个场景：100 个请求里 95 个很快、5 个极慢，看两个指标差多少。

思考：平均值会被「大多数快请求」拉低，掩盖尾部延迟。用户体验由 P95/P99 决定——那 5% 慢请求就是会投诉的用户。这就是为什么 SLA 写 P95 而非平均。

真实 kb-qa 压测时，瓶颈通常不在本地 CPU，而在上游智谱 API 限流。想想：如果瓶颈是上游 API，本地加机器/加并发能提升 QPS 吗？该怎么保护？

思考：LLM 服务的瓶颈画像和传统 Web 服务不同——CPU/内存往往很闲，卡在上游 API 的 RPM/TPM 配额。解法是并发信号量限流（research-assistant 的 max_concurrent_search 就是这个思路）主动排队，而非让请求撞上游 429。