Пул соединений в mssql-django

В этой статье объясняется, как в mssql-django работает пул подключений и как настроить его для вашего приложения Django.

Принцип работы пула подключений

По умолчанию mssql-django использует встроенный пул подключений pyodbc. При закрытии подключения Django pyodbc возвращает его в пул вместо закрытия базового подключения ODBC. Последующие запросы на подключение повторно используют пулы подключений, что снижает затраты на установку новых подключений к базе данных.

Настройка пула подключений

Пул подключений управляется параметром DATABASE_CONNECTION_POOLING, который размещается на уровне модуля в settings.py (вне словаря 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
Ценность Behavior
True (по умолчанию) Пул подключений включен. Закрытые подключения возвращаются в пул.
False Пул подключений отключен. Каждое соединение полностью закрывается при освобождении.

Когда следует отключать пул подключений

Рассмотрите возможность отключения пула подключений в следующих сценариях:

  • Проверка подлинности на основе токенов. При использовании маркеров доступа, истекающих срок действия, пуловые подключения могут содержать устаревшие маркеры.
  • Проблемы с отладкой подключения. Отключение пула упрощает устранение неполадок, гарантируя, что каждый запрос создает новое подключение.
  • Кратковременные процессы: для сценариев или команд управления, которые делают несколько запросов и выхода, пул не добавляет преимущества.

Параметры повторных попыток подключения

Независимо от параметра пула можно настроить поведение повторных попыток для неудачных попыток подключения. Полный список параметров повтора и времени ожидания см. в справочнике по конфигурации.

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

CONN_MAX_AGE в Django

Django также предоставляет CONN_MAX_AGE параметр, который определяет, сколько времени Django сохраняет подключение к базе данных открытым перед закрытием. Этот параметр работает вместе с пулом подключений 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",
        },
    },
}

Дополнительные сведения см. в документации по CONN_MAX_AGEпараметрам базы данных Django.

Практические начальные точки:

  • CONN_MAX_AGE=0: самый безопасный для отладки и кратковременных заданий.
  • CONN_MAX_AGE=600: по умолчанию для многих веб-приложений.
  • CONN_MAX_AGE=3600: разумно для устойчивых служб высокой пропускной способности после нагрузочного тестирования.

Note

При использовании серверов ASGI (таких как Daphne или Uvicorn) или при многопоточных развертываниях постоянные подключения могут просачиваться между асинхронными контекстами. Если вы используете CONN_MAX_AGE с сервером ASGI, установите CONN_HEALTH_CHECKS = True (Django 4.1 и более поздних версий) и проверьте на реалистичном параллелизме. Дополнительные сведения см. в документации Django по управлению подключениями.

CONN_HEALTH_CHECKS проверяет подключения из пула перед повторным использованием. Если Django обнаруживает устаревшее соединение, он прозрачно открывает свежий. Это добавляет небольшие дополнительные затраты на проверку каждого запроса, и эту возможность обычно стоит включать для долгоживущих процессов.