Verwalten von Verbindungen in Azure Functions

Funktionen innerhalb einer Funktions-App nutzen Ressourcen gemeinsam. Unter diesen geteilten Ressourcen bestehen Verbindungen: HTTP-Verbindungen, Datenbankverbindungen und Verbindungen mit Diensten, wie etwa Azure Storage. Werden viele Funktionen gleichzeitig in einem Verbrauchsplan ausgeführt, sind möglicherweise nicht mehr ausreichend verfügbare Verbindungen vorhanden. In diesem Artikel erfahren Sie, wie Sie Ihre Funktionen codieren, um zu vermeiden, dass Sie mehr Verbindungen als erforderlich verwenden.

Hinweis

Die in diesem Artikel beschriebenen Verbindungsgrenzwerte gelten nur bei der Ausführung im Rahmen eines Verbrauchsplans. Die hier beschriebenen Techniken können jedoch bei der Ausführung im Rahmen eines beliebigen Plans von Vorteil sein.

Verbindungsgrenzwert

Die Anzahl der verfügbaren Verbindungen in einem Verbrauchsplan ist teilweise begrenzt, da eine Funktions-App im Rahmen dieses Plans in einer Sandboxumgebung ausgeführt wird. Eine Einschränkung, die die Sandbox Ihrem Code auferlegt, ist eine Grenze für die Anzahl der ausgehenden Verbindungen, die derzeit 600 aktive (insgesamt 1.200) Verbindungen pro Instanz beträgt. Wenn diese Grenze erreicht ist, schreibt die Functions-Runtime die folgende Meldung in die Protokolle: Host thresholds exceeded: Connections. Weitere Informationen finden Sie unter Funktions-Apps: Diensteinschränkungen.

Dieser Grenzwert gilt pro Instanz. Wenn der Skalierungscontroller Funktions-App-Instanzen hinzufügt, um mehr Anforderungen zu verarbeiten, weist jede Instanz einen unabhängigen Verbindungsgrenzwert auf. Das heißt, es gibt keinen globalen Verbindungsgrenzwert, um sie können über alle aktiven Instanzen weit mehr als 600 aktive Verbindungen verwenden.

Stellen Sie bei der Problembehandlung sicher, dass Sie Application Insights für Ihre Funktions-App aktiviert haben. Mit Application Insights können Sie Metriken für Ihre Funktions-Apps wie Ausführungen anzeigen. Weitere Informationen finden Sie unter Anzeigen von Telemetriedaten in Application Insights.

Statische Clients

Um zu vermeiden, dass mehr Verbindungen als nötig gehalten werden, erstellen Sie bei jedem Funktionsaufruf keine neuen Instanzen, sondern verwenden die Clientinstanzen erneut. Wir empfehlen, Clientverbindungen für jede Sprache, in der Sie Ihre Funktion erstellen, wiederzuverwenden. Beispielsweise können .NET-Clients wie HttpClient und DocumentClient sowie Azure Storage-Clients Verbindungen verwalten, wenn Sie einen einzelnen, statischen Client verwenden.

Es folgen einige Richtlinien, die zu beachten sind, wenn Sie einen dienstspezifischen Client in einer Azure Functions-Anwendung verwenden:

  • NEIN Erstellen Sie keinen neuen Client bei jedem Funktionsaufruf.
  • JA Erstellen Sie einen einzelnen, statischen Client, der von jedem Funktionsaufruf verwendet werden kann.
  • VIELLEICHT Denken Sie über die Erstellung eines einzelnen, statischen Clients in einer gemeinsamen Hilfsprogrammklasse nach, wenn verschiedene Funktionen den gleichen Dienst verwenden.

Clientcodebeispiele

Dieser Abschnitt veranschaulicht Best Practices für die Erstellung und Verwendung von Clients über den Funktionscode.

HTTP-Anforderungen

Es folgt ein Beispiel für einen C#-Funktionscode, der eine statische HttpClient-Instanz erstellt:

// Create a single, static HttpClient
private static HttpClient httpClient = new HttpClient();

public static async Task Run(string input)
{
    var response = await httpClient.GetAsync("https://example.com");
    // Rest of function
}

Eine häufig gestellte Frage zum HttpClient in .NET lautet: „Soll ich meinen Client löschen?“. Im Allgemeinen löschen Sie Objekte, die IDisposable implementieren, wenn Sie sie nicht mehr verwenden. Sie löschen jedoch keinen statischen Client, da dessen Verwendung mit dem Funktionsende nicht abgeschlossen ist. Der statische Client soll für die Dauer der Anwendung gültig sein.

Azure Cosmos DB-Clients

DocumentClient stellt eine Verbindung mit einer Azure Cosmos DB-Instanz her. In der Azure Cosmos DB-Dokumentation wird empfohlen, dass Sie einen Singleton-Azure Cosmos DB-Client für die Lebensdauer der Anwendung verwenden. Im folgenden Beispiel wird ein Muster dafür in einer Funktion gezeigt:

#r "Microsoft.Azure.Documents.Client"
using Microsoft.Azure.Documents.Client;

private static Lazy<DocumentClient> lazyClient = new Lazy<DocumentClient>(InitializeDocumentClient);
private static DocumentClient documentClient => lazyClient.Value;

private static DocumentClient InitializeDocumentClient()
{
    // Perform any initialization here
    var uri = new Uri("example");
    var authKey = "authKey";
    
    return new DocumentClient(uri, authKey);
}

public static async Task Run(string input)
{
    Uri collectionUri = UriFactory.CreateDocumentCollectionUri("database", "collection");
    object document = new { Data = "example" };
    await documentClient.UpsertDocumentAsync(collectionUri, document);
    
    // Rest of function
}

Wenn Sie Functions v3.x verwenden, benötigen Sie einen Verweis auf Microsoft.Azure.DocumentDB.Core. Fügen Sie einen Verweis im Code hinzu:

#r "Microsoft.Azure.DocumentDB.Core"

Erstellen Sie außerdem eine Datei mit dem Namen „function.proj“ für Ihren Trigger, und fügen Sie den folgenden Inhalt hinzu:


<Project Sdk="Microsoft.NET.Sdk">
    <PropertyGroup>
        <TargetFramework>netcoreapp3.0</TargetFramework>
    </PropertyGroup>
    <ItemGroup>
        <PackageReference Include="Microsoft.Azure.DocumentDB.Core" Version="2.12.0" />
    </ItemGroup>
</Project>

SqlClient-Verbindungen

Funktionscode kann den .NET Framework-Datenanbieter für SQL Server (SqlClient) verwenden, um Verbindungen zu einer relationalen SQL-Datenbank herzustellen. Dies ist auch der zugrunde liegende Anbieter für Daten-Frameworks, die ADO.NET verwenden, z.B. Entity Framework. Im Gegensatz zu HttpClient- und DocumentClient-Verbindungen implementiert ADO.NET standardmäßig das Verbindungspooling. Da jedoch noch immer nicht genügend Verbindungen verfügbar sein können, sollten Sie die Verbindungen mit der Datenbank optimieren. Weitere Informationen finden Sie unter SQL Server-Verbindungspooling (ADO.NET).

Tipp

Einige Daten-Frameworks, z.B. Entity Framework, rufen Verbindungszeichenfolgen üblicherweise aus dem Abschnitt ConnectionStrings einer Konfigurationsdatei ab. In diesem Fall müssen Sie der Sammlung Verbindungszeichenfolgen der Funktions-App-Einstellungen und der Datei local.settings.json im lokalen Projekt explizit SQL-Datenbank-Verbindungszeichenfolgen hinzufügen. Bei der Erstellung einer Instanz von SqlConnection in Ihrem Funktionscode sollten Sie den Verbindungszeichenfolgenwert zusammen mit den anderen Verbindungen in den Anwendungseinstellungen speichern.

Nächste Schritte

Weitere Informationen zur Empfehlung von statischen Clients finden Sie unter Antimuster für ungeeignete Instanziierung.

Weitere Tipps zur Leistungssteigerung von Azure Functions finden Sie unter Optimieren der Leistung und Zuverlässigkeit von Azure Functions.