Kestrel性能瓶颈主因非线程数不足，而是同步阻塞和配置不当；需调优ThreadPool最小线程、Kestrel连接/请求参数，并禁用AllowSynchronousIO，避免.Wait()/.Result等隐式同步操作。
为什么 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观察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 上挂起。
Outlook 日历 / Microsoft 365 日历 SECURE API CLI。当用户需要列出、搜索或读取 Outlook / Microsoft 365 日历事件，以及创建……
- 绝对避免在中间件或控制器中使用
.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 协议层配置是否匹配真实流量特征。
