我来帮你拆解下这个QPS暴跌的核心原因，以及对应的解决思路：

为什么会出现这个情况？ #

ASP.NET Core依赖.NET线程池处理入站请求，每个请求会占用一个工作线程直到处理完成。当你在hello4接口里加入dbms_lock.sleep(1);这种同步阻塞1秒的操作时：

• 每个请求会死死占用一个线程1秒，理论上要支撑100QPS，你需要至少100个空闲线程同时处理请求。
• 但.NET线程池的默认最小工作线程数并不高（通常是CPU核心数的2倍左右），而且线程池的线程扩容是有延迟的（不会瞬间创建大量线程）。当Vegeta以100QPS的速率发请求时，线程池很快被阻塞的线程占满，后续请求只能排队等待，最终实际处理的QPS就跌到了20左右。

解决思路（按优先级排序） #

1. 把同步阻塞操作改成异步非阻塞 #

这是最优解，能从根本上解决线程浪费的问题。如果你的数据库支持异步休眠操作，改用异步版本；如果没有，可以用await Task.Delay(1000);代替同步的dbms_lock.sleep(1);。

异步操作会把线程释放回线程池，让同一个线程可以处理多个请求，这样即使每个请求需要1秒处理时间，线程池也能轻松支撑100QPS的负载。

2. 调整线程池最小工作线程数（次优解） #

如果暂时无法改成异步，可以手动增加线程池的最小工作线程数，让线程池一开始就有足够的线程来处理阻塞请求。在Program.cs里添加：

ThreadPool.SetMinThreads(100, 100); // 第一个参数是工作线程数，第二个是IO线程数

注意：这种方法只是缓解问题，因为同步阻塞还是会浪费线程资源，高负载下依然可能出现瓶颈，而且过多的线程会带来上下文切换的额外开销。

3. 确认Vegeta的配置细节 #

你的Vegeta命令里-timeout=0是禁用超时，这本身没问题，但可以检查下targets.txt里的目标配置是否正确，比如有没有额外的延迟设置。不过这不是导致QPS暴跌的主要原因。

内容的提问来源于stack exchange，提问作者Alexey