Verbindungspooling in mssql-django

In diesem Artikel wird erläutert, wie Connection Pooling in mssql-django funktioniert und wie Sie es für Ihre Django-Anwendung konfigurieren.

Funktionsweise von Verbindungspooling

Standardmäßig verwendet mssql-django Verbindungspooling auf Treiberebene. Der Standardpfad von pyodbc verwendet pyodbc-pooling, und der mssql-python-pfad verwendet mssql-python pooling. Wenn Django eine Verbindung schließt, gibt der aktive Treiber sie an einen Pool zurück, anstatt die zugrunde liegende Datenbankverbindung zu schließen. Nachfolgende Verbindungsanforderungen verwenden gepoolte Verbindungen, wodurch der Aufwand für die Einrichtung neuer Datenbankverbindungen reduziert wird. Für Details zur Treiberauswahl siehe Select the database driver for mssql-django.

Konfigurieren von Verbindungspooling

Das Verbindungspooling wird durch die Einstellung DATABASE_CONNECTION_POOLING gesteuert, die sich auf Modulebene in settings.py (außerhalb des DATABASES Wörterbuchs) befindet:

DATABASES = {
    "default": {
        "ENGINE": "mssql",
        "NAME": "<your-database>",
        "USER": "<your-username>",
        "PASSWORD": "<your-password>",
        "HOST": "<your-server>",
        "PORT": "1433",
        "OPTIONS": {
            "driver": "ODBC Driver 18 for SQL Server",
        },
    },
}

# Set to False to disable driver-level connection pooling
DATABASE_CONNECTION_POOLING = False
Wert Behavior
True (Standardwert) Verbindungspooling ist aktiviert. Geschlossene Verbindungen werden an den Pool zurückgegeben.
False Das Verbindungspooling auf Fahrerebene ist deaktiviert. Der pyodbc-Pfad setzt Database.pooling=False, und der mssql-python-Pfad ruft PoolingManager.disable().

Wann Verbindungspooling deaktiviert werden sollte

Erwägen Sie die Deaktivierung von Verbindungspooling in diesen Szenarien:

  • Tokenbasierte Authentifizierung: Wenn Zugriffstoken verwendet werden, die ablaufen, können gepoolte Verbindungen veraltete Token enthalten.
  • Debuggen von Verbindungsproblemen: Durch deaktivieren des Poolings wird die Problembehandlung vereinfacht, indem sichergestellt wird, dass jede Anforderung eine neue Verbindung erstellt.
  • Kurzlebige Prozesse: Für Skripte oder Verwaltungsbefehle, die nur einige Abfragen ausführen und dann enden, bietet Pooling keinen Vorteil.

Verbindungs-Wiederholungseinstellungen

Unabhängig von der Pooleinstellung können Sie das Wiederholungsverhalten für fehlgeschlagene Verbindungsversuche konfigurieren. Die vollständige Liste der Optionen für Wiederholung und Timeout finden Sie in der Konfigurationsreferenz.

DATABASES = {
    "default": {
        "ENGINE": "mssql",
        "NAME": "<your-database>",
        "USER": "<your-username>",
        "PASSWORD": "<your-password>",
        "HOST": "<your-server>",
        "PORT": "1433",
        "OPTIONS": {
            "driver": "ODBC Driver 18 for SQL Server",
            "connection_retries": 3,
            "connection_retry_backoff_time": 10,
            "connection_timeout": 30,
        },
    },
}

Djangos CONN_MAX_AGE-Wert

Django bietet auch eine CONN_MAX_AGE Einstellung, die steuert, wie lange Django eine Datenbankverbindung geöffnet hält, bevor sie geschlossen wird. Diese Einstellung arbeitet zusammen mit dem Connection-Pooling auf Treiberebene:

DATABASES = {
    "default": {
        "ENGINE": "mssql",
        "NAME": "<your-database>",
        "USER": "<your-username>",
        "PASSWORD": "<your-password>",
        "HOST": "<your-server>",
        "PORT": "1433",
        "CONN_MAX_AGE": 600,  # Keep connections open for 10 minutes
        "OPTIONS": {
            "driver": "ODBC Driver 18 for SQL Server",
        },
    },
}

Weitere Informationen finden Sie in der Dokumentation zu CONN_MAX_AGEden Django-Datenbankeinstellungen.

Praktische Ausgangspunkte:

  • CONN_MAX_AGE=0: am sichersten für Debugging- und kurzlebige Aufträge.
  • CONN_MAX_AGE=600: Gute Standardeinstellung für viele Web-Apps.
  • CONN_MAX_AGE=3600: vertretbar für Services mit konstant hohem Durchsatz nach Lasttests.

Note

Wenn Sie ASGI-Server (wie Daphne oder Uvicorn) oder threaded Deployments verwenden, können persistente Verbindungen über asynchrone Kontexte hinweg durchsickern. Wenn du CONN_MAX_AGE mit einem ASGI-Server verwendest, setze CONN_HEALTH_CHECKS = True in unterstützten Django-Versionen und teste unter realistischer Parallelität. Weitere Informationen finden Sie in der Django-Dokumentation zur Verbindungsverwaltung.

CONN_HEALTH_CHECKS überprüft poolierte Verbindungen vor der Wiederverwendung. Wenn Django eine veraltete Verbindung erkennt, öffnet sie transparent eine frische Verbindung. Dies fügt pro Anfrage geringe zusätzliche Kosten für eine Prüfung hinzu und lohnt sich in der Regel bei langlebigen Prozessen.

Verwandte Inhalte

  • Last updated on