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。正确做法只有一种：
- 全局注册
IHttpClientFactory，用builder.Services.AddHttpClient()注册命名/类型化客户端 - Controller 或 Service 中通过构造函数注入
IHttpClientFactory，再用CreateClient("name")获取实例 —— 它内部自动复用连接、处理 DNS 刷新、支持 Polly 熔断 - 绝对不要在 using 块里 new
HttpClient，也别把它声明为 static 字段（DNS 变更无法感知，连接长期不释放）
// Program.cs
builder.Services.AddHttpClient<IUserService, UserService>()
.ConfigurePrimaryHttpMessageHandler(() => new HttpClientHandler
{
MaxConnectionsPerServer = 100 // 关键：提高单服务连接上限
});JSON 序列化和数据库访问的隐性开销
高并发下，System.Text.Json 默认行为仍可能拖慢响应：深度嵌套对象、大量字符串拼接、未关闭 WriteIndented = true。数据库侧常见问题是连接池耗尽或命令超时未设。
- API 返回 DTO 时，禁用
JsonSerializerOptions.WriteIndented（默认 false，但有人显式设为 true）；对含敏感字段的类型，用[JsonIgnore]比运行时条件判断快 -
DbContext必须作用域生命周期（AddDbContextPool），池大小按压测结果调：默认1024，但若平均请求 DB 耗时，可降到 <code>256减少内存占用 - 所有
async数据库调用必须配CommandTimeout，例如context.Database.GetDbConnection().ConnectionTimeout不起作用，得在OnConfiguring里设optionsBuilder.UseSqlServer(connStr, o => o.CommandTimeout(30))
真正卡住高并发的，往往不是框架上限，而是某次 await dbContext.Users.ToListAsync() 没加 AsNoTracking()，或前端反复发未带 ETag 的全量 GET 请求——这些细节比调 Kestrel 参数影响更大。
