Zufälliges Azure Table/Blob/Queue-Timeout auf Linux-System (k8s .net Core 3 App) ⇐ C#

[Anonymous]

Das ist mein Szenario:

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

Ich bin viel umgezogen meines Codes von der Azure-Funktion zu Google k8s und Google Cloud, wobei die .NET Core-App ausgeführt wird, im Wesentlichen mit der gleichen Bibliothek, die in .NET Standard 2.0 erstellt wurde, ohne Probleme.
Nach ein paar Tagen bemerke ich ein anderes Verhalten im Linux-System.
Bei wenigen Aufrufen, die mit dem Azure-Dienst (Blob, Tabelle, Warteschlange) interagieren, kommt es zu Zeitüberschreitungen (das Subsystem scheint fehlzuschlagen, ich habe eine andere Wiederholungsmethode mit dem gleichen Ergebnis ausprobiert).
In Bei 10.000 Anrufen erhalte ich 10 bis 50 Fehler (oder sehr lange Anrufe von 180 Sekunden, bevor ich die Timeouts geändert habe). Dies geschieht in allen Azure-Diensten: Tabelle, Blob und Warteschlange.
Ich habe verschiedene Lösungen ausprobiert, um herauszufinden, warum:

• Ich instanziiere den Client (blobClient, TableClient usw.) bei jedem Aufruf oder verwende denselben Client erneut, aber ohne Unterschied
• Ich ändere alle Zeitüberschreitungen, um dieses Verhalten zu behandeln. Ich arbeite an ServerTimeout und MaximumExecutionTime und lege mit meinem Wiederholungsmechanismus eine Ebene darüber, damit ich Fehler minimieren kann. Jetzt habe ich „nur“ ein paar Aufrufe von 20 Sekunden (anstelle von beispielsweise 2/3 Sekunden).
• Ich habe alle Lösungen mit ähnlichen Problemen ausprobiert, die auf Stackoverflow gefunden wurden ... aber nichts funktioniert (im Moment)

Derselbe DLL-Code läuft ohne Probleme auf Azure-Funktion.
Also bin ich zu dem Schluss gekommen, dass es etwas im HTTP-Client gibt, der intern vom Azure SDK verwendet wird Hängt vom Betriebssystem ab, auf dem Sie Ihren Code ausführen.
Ich denke, nach ein paar Artikeln könnte es der Keep-Alive-Header sein, also versuche ich es mit meinem Kompositionsstamm:

Code: Select all

ServicePointManager.SetTcpKeepAlive (true, 120000, 10000);

aber es ändert sich nichts.
Irgendwelche Ideen oder Vorschläge?