Pool de conexões no mssql-django

Este artigo explica como o pool de conexões funciona em mssql-django e como configurá-lo para o seu aplicativo Django.

Como funciona o pool de conexões

Por padrão, mssql-django usa o pool de conexões interno do pyodbc. Quando uma conexão é fechada pelo Django, o pyodbc a retorna para um pool em vez de fechar a conexão ODBC subjacente. Solicitações de conexão subsequentes reutilizam conexões em pool, o que reduz a sobrecarga de estabelecer novas conexões de banco de dados.

Configurar o pool de conexões

O pool de conexões é controlado pela configuração DATABASE_CONNECTION_POOLING, que fica definida no nível do módulo em settings.py (fora do dicionário 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
Valor Behavior
True (padrão) O pool de conexões está habilitado. As conexões fechadas são devolvidas ao pool.
False O agrupamento de conexões está desativado. Cada conexão é totalmente encerrada ao ser liberada.

Quando desabilitar o pool de conexões

Considere desabilitar o pool de conexões nestes cenários:

  • Autenticação baseada em token: ao usar tokens de acesso que expiram, as conexões em pool podem conter tokens obsoletos.
  • Depuração de problemas de conexão: desativar o pooling simplifica a solução de problemas, ao garantir que cada solicitação crie uma nova conexão.
  • Processos de curta duração: para scripts ou comandos de gerenciamento que fazem algumas consultas e saem, o pool não adiciona nenhum benefício.

Configurações de repetição de conexão

Independentemente da configuração de pooling, você pode configurar o comportamento de novas tentativas para tentativas de conexão malsucedidas. Para obter a lista completa de opções de repetição e tempo limite, consulte a referência de configuração.

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 do Django

O Django também fornece uma CONN_MAX_AGE configuração que controla por quanto tempo o Django mantém uma conexão de banco de dados aberta antes de fechá-la. Essa configuração funciona junto com o pool de conexões do 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",
        },
    },
}

Para obter mais informações sobre CONN_MAX_AGE, consulte a documentação de configurações do banco de dados do Django.

Pontos de partida práticos:

  • CONN_MAX_AGE=0: mais seguro para depuração e tarefas de curta duração.
  • CONN_MAX_AGE=600: bom padrão para muitos aplicativos Web.
  • CONN_MAX_AGE=3600: razoável para serviços de alta taxa de transferência constantes após o teste de carga.

Note

Ao usar servidores ASGI (como Daphne ou Uvicorn) ou implantações encadeadas, as conexões persistentes podem vazar em contextos assíncronos. Se você usar CONN_MAX_AGE com um servidor ASGI, defina CONN_HEALTH_CHECKS = True (Django 4.1 e posterior) e teste sob simultaneidade realista. Para obter mais informações, consulte a documentação do Django sobre gerenciamento de conexões.

CONN_HEALTH_CHECKS valida conexões em pool antes da reutilização. Se o Django detectar uma conexão obsoleta, ela abrirá uma conexão nova de forma transparente. Isso adiciona um pequeno custo de verificação por solicitação e geralmente vale a pena habilitar para processos de longa duração.