Sdružování připojení v mssql-django

Tento článek vysvětluje, jak funguje mssql-django sdružování připojení a jak ho nakonfigurovat pro vaši aplikaci Django.

Jak funguje sdružování připojení

Ve výchozím nastavení používá mssql-django vestavěné sdružování připojení v pyodbc. Když je připojení uzavřeno frameworkem Django, pyodbc je vrátí do poolu připojení namísto uzavření podkladového připojení ODBC. Následné požadavky na připojení znovu využívají sdružená připojení, což snižuje režii spojenou s navazováním nových databázových připojení.

Konfigurace sdružování připojení

Sdružování připojení se řídí pomocí nastavení DATABASE_CONNECTION_POOLING, které je umístěno na úrovni modulu v settings.py (mimo slovník DATABASES):

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 pyodbc's connection pooling
DATABASE_CONNECTION_POOLING = False
Value Behavior
True (výchozí) Sdružování připojení je povolené. Uzavřená připojení se vrátí do fondu.
False Sdružování připojení je zakázané. Každé připojení je po uvolnění zcela uzavřeno.

Kdy zakázat sdružování připojení

Zvažte zakázání sdružování připojení v těchto scénářích:

  • Ověřování na základě tokenů: Při použití přístupových tokenů, jejichž platnost vyprší, můžou připojení ve fondu obsahovat zastaralé tokeny.
  • Ladění problémů s připojením: Zakázání sdružování připojení zjednodušuje odstraňování potíží tím, že každý požadavek vytvoří nové připojení.
  • Krátkodobé procesy: Pro skripty nebo příkazy pro správu, které provedou jen několik dotazů a skončí, nepřináší poolování žádnou výhodu.

Nastavení opakování připojení

Bez ohledu na nastavení poolingu můžete nakonfigurovat chování při opakovaných pokusech o navázání připojení po selhání. Úplný seznam možností opakování a vypršení časového limitu najdete v referenčních informacích ke konfiguraci.

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,
        },
    },
}

Parametr CONN_MAX_AGE v Djangu

Django také poskytuje CONN_MAX_AGE nastavení, které určuje, jak dlouho Django udržuje připojení k databázi otevřené před zavřením. Toto nastavení funguje spolu se sdružováním připojení v pyodbc:

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",
        },
    },
}

Další informace o CONN_MAX_AGEnastavení databáze Django naleznete v dokumentaci k nastavení databáze Django.

Praktické výchozí body:

  • CONN_MAX_AGE=0: Nejbezpečnější pro ladění a krátkodobé úlohy.
  • CONN_MAX_AGE=600: Dobré výchozí nastavení pro mnoho webových aplikací.
  • CONN_MAX_AGE=3600: přiměřené pro stabilní služby s vysokou propustností po zátěžových testech.

Note

Při použití serverů ASGI (například Daphne nebo Uvicorn) nebo ve vícevláknových nasazeních mohou perzistentní připojení prosakovat mezi asynchronními kontexty. Pokud používáte CONN_MAX_AGE se serverem ASGI, nastavte CONN_HEALTH_CHECKS = True (Django 4.1 a novější) a otestujte v rámci reálné souběžnosti. Další informace najdete v dokumentaci Django ke správě připojení.

CONN_HEALTH_CHECKS ověřuje sdružená připojení před jejich opětovným použitím. Pokud Django zjistí zastaralé připojení, transparentně otevře nové připojení. To přidává malou režii na kontrolu každého požadavku a obvykle se vyplatí to povolit pro dlouho běžící procesy.

Související obsah

  • Last updated on