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。