Microsoft Azure 中托管的 .NET CORE API 应用程序超时异常（Redis 缓存、SQL、.NET Core）

Question

我有以下基础结构：.NET Core 3.1 API，它托管在 VNet 中。 在 VNet 内部，我们有 8 台带有负载均衡器 + SQL Server + Redis 缓存的服务器。

我们在登录操作（这不是轻量级操作）上运行 API 负载测试每秒 1200 次操作。 此时所有服务器上的负载为 5-10%。 但问题是我们遇到了 API 超时和 Redis 超时问题。

好像有什么东西阻塞了我们的线程

这是来自我的 Startup.cs（我们正在尝试使用该值，但没有成功）：

  var threadCount = 2000; 
  ThreadPool.GetMaxThreads(out _, out var completionThreads); 
  ThreadPool.SetMinThreads(threadCount, completionThreads);

这是来自 *.csproj 文件：

 <PropertyGroup>
<ThreadPoolMinThreads>315</ThreadPoolMinThreads>

Update1-> Redis 问题信息添加

Redis 错误：StackExchange.Redis.RedisTimeoutException：等待响应超时（出站=0KiB，入站=0KiB，10008 毫秒已过，超时为 10000 毫秒），命令=GET，下一个：SET key_digievents____freeevent_4072，inst：0，qu：0，qs： aw: False, rs: ReadAsync, ws: Idle, in: 2197285, in-pipe: 0, out-pipe: 0, serverEndpoint: 10.0.0.34:6379, mc: 1/1/0, mgr: 10 of 10 available , clientName: akssocial27apiapp-xkkb4, IOCP: (Busy=0,Free=1000,Min=1000,Max=1000), WORKER: (Busy=430,Free=32337,Min=315,Max=32767), v: 2.1 .58.34321 StackExchange.Redis.RedisTimeoutException：等待响应超时（出站=0KiB，入站=0KiB，10008ms已过，超时为10000ms），命令=GET，下一个：SET key_digievents____freeevent_4072，inst：08，qsaw： : False, rs: ReadAsync, ws: Idle, in: 2197285, in-pipe: 0, out-pipe: 0, serverEndpoint: 10.0.0.34:6379, mc: 1/1/0, mgr: 10 of 10 available,客户名称：akssocial27apiapp-xkkb4，IOCP：（忙碌=0，空闲=1000，最小值=1000，最大值=1000），工人：（忙碌=430，空闲=32337，最小值=315，M ax=32767), v: 2.1.58.34321 在 Datadog.Trace.ClrProfiler.Integrations.StackExchange.Redis.ConnectionMultiplexer.ExecuteAsyncImplInternal[T](对象多路复用器，对象消息，对象处理器，对象状态，对象服务器，Func`6 originalMethod)

我会很高兴的任何建议。 提前致谢。

Answer 1

很多人在升级到2.x时遇到TimeoutException

https://github.com/StackExchange/StackExchange.Redis/issues/1226

此解决方案可能对您有所帮助： 您是否在超时异常中看到大量的 busyio 或 busyworker 线程？

在帖子的最后，它说：

在 .Net Core 中，根据环境/注册表配置旋钮，添加环境变量 COMPlus_ThreadPool_ForceMinWorkerThreads 以覆盖默认的 MinThreads 设置 - 您也可以使用与上述相同的 ThreadPool.SetMinThreads() 方法。

Answer 2

下面是我附上关于我提出的问题的笔记的文字。 我希望这可以帮助某人并节省大量时间。

首先，我们没有异常/错误/报告带宽是 Azure 基础架构中的瓶颈。 这只是我们的假设。 但是为了反驳这种假设，我们大幅增加了容量，甚至 MS Azure 团队都说我们过度配置而不是我们的使用量。 所以带宽从来都不是问题。 这是限制：

1. StackExchangeRedis Nuget 包，尤其是当它处理更多数据字节时。

2. 分析表明，我们正在为该页面不需要的页面调用许多不必要的端点或数据。

因此，作为我的 POV，我们需要弄清楚如何使用 StackExchangeRedis 包来处理最少且仅必要的数据以及如何减少对 FE 上不需要的端点的调用等的优化。

我的队友曾与开发 StachExchangeRedis 的人保持联系。 开发人员承认，对于庞大的数据块，它具有局限性。 他还告诉我们，我们并不是唯一遇到此问题的人。

因此，经过所有讨论，我们优化了对 GET/SET 操作的调用。 它允许我们以更精确和有效的方式处理数据字节，以便必要的端点切断所有不需要的端点和呼叫。 我们还在后端实现了某种压缩。

最后，我们添加了额外的区域，使我们能够改善当前的情况。

尽管如此，我们正在考虑跳过使用 Redis 并转向 NoSQL 解决方案。 我们将一次解决几个问题——缓存问题和实时数据+大数据的SQL限制（到目前为止，这只是一个想法层面）

PS影响Redis性能的因素：

• 在许多实际场景中，Redis 的吞吐量在受到 CPU 限制之前会受到网络的限制。 要将多个高吞吐量 Redis 实例整合到单个服务器上，值得考虑放置一个 10 Gbit/s NIC 或多个具有 TCP/IP 绑定的 1 GBit/s NIC。
• CPU是另一个非常重要的因素。 由于是单线程的，Redis 更喜欢具有大缓存但内核不多的快速 CPU。