Identity Server 4.0（ASP.NET Core 2.0）高负载下connect/token端点响应缓慢咨询

首先梳理下你的当前环境和核心问题：

• 基于EF Core搭建IdentityServer4，客户端数据存储在AWS同区域的MSSQL
• 配置了内存缓存与客户端/资源缓存，使用AddTestUsers提供测试用户
• 测试环境：2个1.5GB内存容器，/connect/token端点在高并发下出现卡顿，1000并发时平均响应超5秒，远未达成「3秒内处理1000并发」的目标
• 对比同配置的其他服务，IdentityServer的性能差距明显

下面是针对性的优化配置建议，帮你快速提升性能：

1. 替换测试用用户存储（核心优化点） #

你当前用的AddTestUsers是IdentityServer专为测试场景设计的内存用户存储，它的实现没有针对高并发做优化，大量请求下会出现锁竞争或内存操作瓶颈，这是性能卡顿的核心原因之一。

替换为基于EF Core的持久化用户存储：

1. 创建用户实体类继承IdentityUser（或自定义实现IUserStore接口）
2. 在启动配置中移除测试用户配置，替换为EF存储：

// 移除原有的 AddTestUsers(Config.GetUsers())
.AddEntityFrameworkStores<ApplicationDbContext>()
.AddDefaultTokenProviders();

3. 将测试用户（alice、bob）存入MSSQL数据库，并为UserName字段添加唯一索引，提升查询效率。

2. 升级缓存策略为分布式缓存 #

当前的AddInMemoryCaching是单容器内的内存缓存，多容器部署时缓存不共享，会导致每个容器都要重复从数据库加载客户端/资源数据，额外增加数据库压力和延迟。

AWS环境下推荐使用ElastiCache Redis作为分布式缓存，配置示例：

// 替换原有的 AddInMemoryCaching()
.AddRedisCaching(options =>
{
    options.Configuration = "your-elasticache-redis-endpoint:6379";
    options.InstanceName = "IdentityServerCache";
})
// 调整缓存过期时间，减少频繁刷新的开销
.AddClientStoreCache<CachingClientStore<ClientStore>>(options => options.Expiration = TimeSpan.FromHours(1))
.AddResourceStoreCache<CachingResourceStore<ResourceStore>>(options => options.Expiration = TimeSpan.FromHours(1));

3. 优化IdentityServer核心配置 #

3.1 替换测试用签名凭证 #

如果你的代码中使用了AddDeveloperSigningCredential（测试默认配置），请替换为持久化的RSA证书——临时密钥生成会带来额外性能开销，且不稳定：

// 可从文件或AWS Secrets Manager加载证书
var certificate = new X509Certificate2("path-to-cert.pfx", "cert-password");
.AddSigningCredential(certificate);

3.2 关闭不必要的功能 #

如果你的业务场景不需要用户授权确认，在客户端配置中关闭 consent 功能：

new Client
{
    // 其他配置...
    RequireConsent = false,
    // 若不需要刷新令牌，设置 AllowOfflineAccess = false
    AllowOfflineAccess = false
}

3.3 优化令牌序列化 #

如果使用IdentityServer4 v4+版本，默认已采用System.Text.Json，但可进一步调整序列化选项提升性能：

.AddIdentityServer(options =>
{
    options.JsonWebTokenHandler = new JsonWebTokenHandler
    {
        JsonSerializerOptions = new JsonSerializerOptions
        {
            PropertyNamingPolicy = JsonNamingPolicy.CamelCase,
            WriteIndented = false // 关闭格式化，减少序列化开销
        }
    };
})

4. 数据库层优化 #

4.1 索引优化 #

为MSSQL中IdentityServer相关表添加针对性索引：

• Client表：ClientId、GrantTypes、AllowedScopes字段添加索引
• IdentityResource表：Name字段添加唯一索引
• ApiResource表：Name字段添加唯一索引

4.2 调整数据库连接池 #

在appsettings.json中修改连接字符串，增大连接池大小（默认100，高并发场景建议设置为200-300）：

"ConnectionStrings": {
    "IdentityServerDb": "Server=your-mssql-endpoint;Database=IdentityServer;User Id=sa;Password=xxx;Max Pool Size=250;MultipleActiveResultSets=true;"
}

4.3 EF Core查询缓存 #

使用第三方库（如EFCoreSecondLevelCacheInterceptor）为客户端、资源的查询启用二级缓存，减少重复查询数据库的次数。

5. .NET运行时与容器优化 #

5.1 启用服务器GC #

在容器环境变量中添加：

DOTNET_GC_SERVER=1

服务器GC专为多核心、高并发场景设计，比默认的工作站GC性能提升显著。

5.2 调整线程池最小线程数 #

在Program.cs入口处添加线程池配置，避免高并发下线程池饥饿：

// 根据容器CPU核心数调整，2核容器建议设置为200/200
ThreadPool.SetMinThreads(200, 200);

5.3 容器资源调整 #

IdentityServer的令牌签名属于CPU密集型操作，建议：

• 给每个容器分配至少2核CPU
• 调整内存限制为2GB，确保服务器GC有足够的内存空间运作

6. 测试方式优化 #

• 预热请求：正式测试前先发送100-200次低并发请求，让JIT编译完成、缓存加载完毕，避免初始请求的性能波动影响测试结果。
• JMeter配置：使用「吞吐量控制器」模拟稳定的1000并发，而非瞬间发起全部请求导致服务过载。

通过以上优化，你应该能大幅提升/connect/token端点的处理性能，达成1000并发3秒内处理的目标。如果仍有瓶颈，可通过AWS CloudWatch监控容器的CPU、内存、数据库连接数，定位剩余的性能卡点。

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