为何Azure C# WebAPI环境下Task.WhenAll未带来预期性能收益？

架构老林

2026-9-29

该现象的成因主要包含以下几点：

数据库层面的资源竞争与限制：你使用的S3层级SQL Server属于低性能服务层级，本身IO吞吐、并发处理能力上限较低。并行发起大量DeleteAsync请求时，一方面会触发数据库行锁/表锁竞争，严重时会产生死锁导致事务回滚重试，额外增加耗时；另一方面ADO.NET默认数据库连接池存在容量上限（通常为100），并发请求数超过连接池上限时会进入连接等待队列，反而比callingFunction2串行复用连接的开销更高。
异步方法的隐性同步开销：虽然你提到DeleteAsync内大部分是异步操作，但如果实际代码中隐含同步阻塞逻辑（比如未正确使用await的CPU密集计算、同步IO调用），并行启动大量任务时会快速占满线程池工作线程，而线程池扩容存在秒级延迟，此时任务调度的排队成本远高于并行带来的收益。
下游依赖的限流限制：DeleteAsync包含推送消息到服务总线的操作，大部分消息中间件都有默认的请求频率限流规则，并行批量推送很容易触发限流重试逻辑，而callingFunction2串行执行的请求速率通常不会触碰限流阈值，反而整体耗时更低。
并行调度的额外开销：如果单个DeleteAsync的执行耗时本身很短，Task.WhenAll并行执行带来的线程上下文切换、任务调度、异常聚合的开销总和，会超过并行执行节省的时间，此时串行执行的效率反而更高。
代码逻辑漏洞：你提供的代码中存在明显逻辑问题：循环遍历id列表时，传入DeleteAsync的是固定的obj而非当前循环的id，如果实际业务中是重复操作同一资源，并行执行会引发大量资源竞争冲突；而串行执行时首次操作完成后后续操作可直接返回无资源的结果，自然耗时更短。