为什么 Kestrel 默认线程数可能成为瓶颈
Kestrel 本身不直接管理“线程池线程”，它依赖
ThreadPool处理 I/O 完成回调和同步上下文任务，但真正影响吞吐的关键是
ThreadPool.SetMinThreads和底层 I/O 复用机制（如 Linux 的 epoll / Windows 的 IOCP）。默认情况下，.NET 的线程池最小线程数偏低（通常为
Environment.ProcessorCount），在突发短连接或高并发小请求场景下，容易出现
ThreadPool饥饿——表现为延迟陡增、
HttpRequest堆积、CPU 利用率却不高。 不要盲目调大
ThreadPool.SetMinThreads：过高的最小线程数会增加内存开销（每个线程约 1MB 栈空间）和上下文切换成本 优先确认是否真被线程池卡住：用
dotnet-counters --process-id <pid> --counters System.Runtime</pid>观察
ThreadPool.QueueLength和
ThreadPool.ThreadCount是否持续偏高 Linux 上更应关注
epoll_wait效率，而非线程数；Windows 上 IOCP 本身高效，瓶颈常出现在应用层同步阻塞（如
Task.Wait()、
.Result）
如何配置 Kestrel 的连接与请求处理参数
Kestrel 的性能敏感项集中在连接生命周期和请求缓冲策略，而非“线程模型”本身——它本质是异步 I/O 驱动的事件循环式服务器。关键配置需通过
KestrelServerOptions显式设置，而非依赖默认值。
LimitMaxConcurrentConnections：设为
0（不限制）仅在可信内网安全；公网服务建议根据负载测试结果设硬上限，防止连接耗尽文件描述符
LimitMaxRequestBodySize：默认
30_000_000（约 28.6 MB），若业务无大上传，应下调（如
10_485_760）以减少内存压力和 DoS 风险
Http2.MaxStreamsPerConnection：HTTP/2 场景下，默认 100 常不够，高并发长连接建议提高到 200–500，但需配合客户端调整 禁用
AllowSynchronousIO（默认
false）：确保所有
HttpContext.Request.Body读取都走
ReadAsync，避免隐式同步阻塞线程池
webBuilder.ConfigureKestrel(options =>
{
options.Limits.MaxConcurrentConnections = 5000;
options.Limits.MaxRequestBodySize = 10 * 1024 * 1024;
options.Limits.Http2.MaxStreamsPerConnection = 300;
options.AddServerHeader = false; // 减少响应头开销
});同步阻塞是 Kestrel 性能杀手，比线程数更致命
绝大多数 Kestrel 吞吐下降并非因为“线程不够”，而是代码中存在隐式同步等待，把异步 I/O 桥接成了同步执行路径，导致线程池线程被长期占用。典型表现是
dotnet-trace抓到大量
ThreadPoolWorkerThread在
WaitHandle.WaitOne或
Monitor.Enter上挂起。 绝对避免在中间件或控制器中使用
.Wait()、
.Result、
.GetAwaiter().GetResult()检查第三方库：如旧版
Microsoft.Data.SqlClient（Pooling=false 时可能触发同步 DNS 查询 数据库访问必须用
ExecuteReaderAsync、
ExecuteScalarAsync等异步方法；EF Core 中启用
async所有路径（包括
ToListAsync、
SaveChangesAsync） 日志写入若用同步
FileLogger，高并发下极易拖垮整个请求管道——改用
Microsoft.Extensions.Logging.Console+ 日志聚合（如 Seq、Loki）
Linux 下 Kestrel 性能优化的几个硬性前提
在容器或 Linux 服务器部署时，Kestrel 表现受系统级限制直接影响，很多问题和 .NET 配置无关。
确保ulimit -n≥ 65536：Kestrel 连接数直接受 open files 限制，Docker 需加
--ulimit nofile=65536:65536关闭透明大页（THP）：
echo never > /sys/kernel/mm/transparent_hugepage/enabled，否则 GC 暂停时间可能翻倍 使用
libuv已废弃，Kestrel 6+ 强制使用
System.IO.Pipelines+ 原生 socket，无需额外安装运行时组件 若启用了 HTTPS，证书链过长或 OCSP Stapling 配置不当会导致 TLS 握手延迟——用
openssl s_client -connect host:443 -servername host验证握手耗时
Kestrel 没有所谓“可调的线程模型”，它的扩展性来自异步 I/O 和高效的内存管道，而不是线程数量。真正要盯住的是同步阻塞点、系统资源上限、以及 HTTP 协议层配置是否匹配真实流量特征。
