.NET Core Web API最大工作进程与队列长度配置咨询

一、是否需要这类配置？ #

• QueueLength（队列长度）：默认值一般为1000，是否调至10000需结合实际场景判断。.NET Core在IIS上通过AspNetCoreModule托管，请求先进入IIS队列再转发至Core进程。只有当测试中出现请求排队超时（503 Service Unavailable），且确认是IIS队列满导致时，才需要调大该值。盲目设为10000会让后端Core进程承受远超处理能力的请求积压，反而导致响应时间暴涨，甚至进程崩溃。
• MaxWorkProcess（最大工作进程数）：你的EC2实例是4vCPU，同一应用池托管两个API项目，设置2和1的总进程数为3，这个范围基本合理，但要注意：
  • .NET Core本身支持多线程，单个进程即可利用多个CPU核心，并非进程越多越好。4vCPU机器的总工作进程数建议控制在2-4之间（与CPU核心数匹配），避免进程切换开销过大。
  • 若两个API资源占用差异大（比如一个CPU密集、一个IO密集），分开设置不同进程数是合理的，但需确保总进程数不超过CPU核心数的1.5倍，避免资源竞争。

二、对并发用户负载的影响 #

• QueueLength的影响：
  • 调大QueueLength能让IIS容纳更多等待处理的请求，避免直接返回503，在短时间高并发冲击下可暂时缓冲请求。但如果后端Core进程处理能力跟不上，排队请求会导致用户等待时间变长，并发用户数看似提升，但实际服务质量（响应时间）会下降。
  • 若QueueLength设得太小，高并发时会直接拒绝新请求，虽响应快但并发上限低。
• MaxWorkProcess的影响：
  • 增加工作进程数，在CPU有空闲的情况下，能提升整体请求处理吞吐量，多个进程可并行处理请求，从而支持更多并发用户。
  • 但如果进程数超过CPU核心数，会导致CPU上下文切换频繁，反而降低处理效率，并发负载能力不升反降。结合你的4vCPU实例，总进程数3处于合理范围，但需测试不同进程数（比如总2、3、4）的性能差异，找到最优值。

总结建议 #

1. 先做基准测试：保留默认配置（QueueLength=1000，MaxWorkProcess=1），测试并发负载下的表现，观察是否出现队列满、CPU利用率不足等问题。
2. 针对QueueLength：仅当基准测试中出现大量503错误且IIS日志显示队列溢出时，再逐步调大（比如先设为2000），测试后再调整，不要直接设为10000。
3. 针对MaxWorkProcess：测试总进程数2、3、4的情况，监控CPU利用率、响应时间、吞吐量，找到能让CPU利用率维持在70%-80%左右的进程数，此时并发负载能力最优。
4. 同步关注.NET Core自身配置：比如Kestrel的线程数、请求队列配置，因为最终处理请求的是Core进程，IIS仅作为反向代理，Core自身配置也会影响并发能力。

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