c# - Linux系统上的Azure表/Blob/队列随机超时(k8s .net core 3应用程序)

Question

这是我的场景:

Microsoft.Azure.Storage.Blob 11.2.0
Microsoft.Azure.Storage.Queue 11.2.0
Micorosoft.Azure.Cosmos.Table 1.0.7

我已将大量代码从 Azure 函数移至 Google k8s 和 Google Cloud，运行 Core .Net 应用程序，基本上使用 .net Standard 2.0 中内置的相同库，没有任何问题。

几天后，我注意到 Linux 系统中出现了不同的行为。与 Azure 服务(blob、表、队列)交互的很少有调用会超时(子系统似乎失败，我尝试了不同的重试策略，但结果相同)。在 10,000 次调用中，我遇到 10 到 50 个错误(或者在我更改超时之前，很长的调用 180 秒)。这种情况发生在所有 Azure 服务中:表、blob 和队列。

我尝试了不同的解决方案来找出原因:

• 我每次调用都会实例化客户端(blobClient、TableClient 等)，或者回收相同的客户端但没有区别
• 我更改了所有超时来处理此行为。我研究 ServerTimeout 和 MaximumExecutionTime，并在上面放置一个层，使用我的重试机制，这样我就可以最大限度地减少错误。现在我“只有”几次 20 秒的调用(而不是例如 2/3 秒)。
• 我尝试了 Stackoverflow 上发现的具有类似问题的所有解决方案:D ...但没有任何效果(目前)

相同的 dll 代码在 azure 函数上运行没有任何问题。

所以我得出的结论是，http 客户端中有一些东西，由 azure sdk 内部使用，这取决于您运行代码的操作系统。我认为在几篇文章之后它可能是 Keep-Alive header ，所以我尝试在我的组合根上:

ServicePointManager.SetTcpKeepAlive (true, 120000, 10000);

但没有任何改变。

有什么想法或建议吗？ ...也许我走错了路，或者我错过了一些东西。

Answer 1

更新

阅读完最后一条评论中 @KrishnenduGhosh-MSFT 链接的最后一篇文章后，我尝试更改此设置:

ServicePointManager.DefaultConnectionLimit = 100;

这是转折点。

由于它过去是随机发生的，所以我仍然不能 100% 确定问题是否得到解决。但经过 50,000 个电话之后，我相当乐观。显然在生产中会有另一种行为，但我已经预料到了:)

更新 2 - 在产品中发布后

最后还是不行:(我已经在评论中写过，但在这里更新似乎是公平的(更具可读性)。我仍然有很长的调用(缩写为 MaximumExecutionTime)，但我看不到隧道尽头的曙光。现在我正在考虑将部分 Azure 存储迁移到 Google 存储，但还没有完全放弃。