c# ASP.NET Core 如何处理高并发请求 asp.net core 性能优化

ASP.NET Core 默认单实例可稳定处理3000–5000并发连接，QPS取决于业务逻辑：纯API可达15k+，含IO操作则降至200–800；瓶颈多在ThreadPool、HttpClient复用、JSON序列化和DB连接池。

ASP.NET Core 默认能扛住多少并发请求？

不调优的 ASP.NET Core 应用在 Linux + Kestrel 下，单实例通常能稳定处理 3000–5000 并发连接（非每秒请求数），但实际吞吐量取决于业务逻辑：纯 API 返回 JSON 且无 IO 等待时，QPS 可达 15k+；一旦涉及数据库查询、HTTP 外部调用或大对象序列化，QPS 可能跌到 200–800。Kestrel 本身不是瓶颈，瓶颈常出在 ThreadPool 配置、HttpClient 复用、JSON 序列化和数据库连接池上。

必须改的三个 Kestrel 和线程池配置

默认配置在高并发下会因线程饥饿或连接排队导致延迟飙升。关键项不是“越多越好”，而是匹配硬件与负载特征：

• ThreadPool.SetMinThreads(100, 100) —— 避免初期线程创建延迟，尤其在 Linux 上默认最小工作线程仅 8；但设太高会浪费内存，建议按 CPU 核数 × 10 初设
• Kestrel 的 Limit.MaxConcurrentConnections 设为 null（不限制）或至少 5000；默认是 null，但某些反向代理（如 Nginx）可能限制了 upstream 连接数，需同步检查
• WebHostBuilder.ConfigureKestrel(...) 中启用 AllowSynchronousIO = false（默认已禁用），强制所有 I/O 走 async，避免线程被 ReadAsStringAsync() 这类同步方法阻塞

var builder = WebApplication.CreateBuilder(args);
builder.WebHost.ConfigureKestrel(serverOptions =>
{
    serverOptions.Limits.MaxConcurrentConnections = null;
    serverOptions.Limits.MaxRequestBodySize = 10 * 1024 * 1024; // 按需调大
});
// 启动前调用
ThreadPool.SetMinThreads(64, 64); // 示例：8 核机器

HttpClient 不复用 = 并发杀手

每次 new HttpClient() 会新建 TCP 连接池，耗尽端口（Linux 默认 ephemeral port range 约 28K）、触发 TIME_WAIT 堆积，500+ 并发就可能报 SocketException: Too many open files。正确做法只有一种：

ChatBA

AI幻灯片生成工具

下载

• 全局注册 IHttpClientFactory，用 builder.Services.AddHttpClient() 注册命名/类型化客户端
• Controller 或 Service 中通过构造函数注入 IHttpClientFactory，再用 CreateClient("name") 获取实例 —— 它内部自动复用连接、处理 DNS 刷新、支持 Polly 熔断
• 绝对不要在 using 块里 new HttpClient，也别把它声明为 static 字段（DNS 变更无法感知，连接长期不释放）

// Program.cs
builder.Services.AddHttpClient()
    .ConfigurePrimaryHttpMessageHandler(() => new HttpClientHandler
    {
        MaxConnectionsPerServer = 100 // 关键：提高单服务连接上限
    });

JSON 序列化和数据库访问的隐性开销

高并发下，System.Text.Json 默认行为仍可能拖慢响应：深度嵌套对象、大量字符串拼接、未关闭 WriteIndented = true。数据库侧常见问题是连接池耗尽或命令超时未设。

• API 返回 DTO 时，禁用 JsonSerializerOptions.WriteIndented（默认 false，但有人显式设为 true）；对含敏感字段的类型，用 [JsonIgnore] 比运行时条件判断快
• DbContext 必须作用域生命周期（AddDbContextPool），池大小按压测结果调：默认 1024，但若平均请求 DB 耗时 ，可降到 256 减少内存占用
• 所有 async 数据库调用必须配 CommandTimeout，例如 context.Database.GetDbConnection().ConnectionTimeout 不起作用，得在 OnConfiguring 里设 optionsBuilder.UseSqlServer(connStr, o => o.CommandTimeout(30))

真正卡住高并发的，往往不是框架上限，而是某次 await dbContext.Users.ToListAsync() 没加 AsNoTracking()，或前端反复发未带 ETag 的全量 GET 请求——这些细节比调 Kestrel 参数影响更大。