Por que tantas conexões com DataServer SQL Server?

Escrito por Marcos Kirchner em 8 de maio de 2009, 12:09h

As aplicações client-server com SQL Server normalmente utilizam uma ou no máximo duas conexões por usuário. Este número é menor quando se utilizam servidores de aplicação (IIS, COM+, etc), devido ao uso de um pool de conexões (connection pooling).

Quando se utiliza uma aplicação Progress com DataServer SQL, no entanto, este número é muito maior. Observamos alguns casos extremos de mais de 100 conexões por sessão de usuário. A primeira reação do administrador diante destes números é sempre na linha do “mas que desgraça estes desenvolvedores acham que estão fazendo?”.

A maior parte deste número de conexões está relacionado às diferenças de arquitetura de Progress / DataServer / SQL Server, e configurações do DataServer. A estrutura dos programas também pode influenciar no número final de conexões.

Neste post abordaremos o motivo de haver tantas conexões, e nos próximos posts verificaremos como monitorar as conexões e algumas formas de reduzir um pouco este número.

Um dos fatores que contribuem para o alto número de conexões são as diferenças nos métodos de acesso a dados. As estruturas de acesso a dados em um programas Progress 4GL / ABL são baseadas em cursores. O SQL Server suporta utilização de cursores, mas assim como a maior parte dos bancos de dados relacionais foi projetado e otimizado para trabalhar com conjuntos (sets). O acesso aos dados utilizando cursores é, na maioria das vezes, mais lento e consome mais recursos do que a operação correspondente utilizando conjuntos.

Para manter compatibilidade com os programas Progress existentes e garantir o mesmo comportamento de um banco de dados Progress, o DataServer utiliza muitos cursores. A partir da versão 9.1E a Progress introduziu algumas otimizações, fazendo com que leituras de dados em modo NO-LOCK utilizem default result sets ao invés de cursores.

Utilizar default result sets é a forma mais rápida e eficiente de ler dados do SQL Server. Este modo de transferência indica ao servidor para enviar os dados pela rede tão rápido quanto o client consiga processá-los. Não há cursores envolvidos. No entanto, enquanto os dados estão sendo transferidos para o client nenhuma outra requisição pode ser enviada pela mesma conexão. Os default result sets “ocupam” a conexão até que todos os dados tenham sido lidos pelo client.

Este comportamento de “uma requisição de cada vez” normalmente não representa um problema, pois as aplicações podem fazer a solicitação de acesso a dados, processar os dados e fazer uma nova solicitação utilizando a mesma conexão. Aplicações Progress 4GL / ABL, entretanto, são predominantemente baseadas em cursores e freqüentemente utilizam vários cursores simultaneamente. Considere o seguinte código:

FOR EACH Pedidos NO-LOCK:
    FOR EACH ItensPedido NO-LOCK WHERE Pedidos.PedidoID = ItensPedido.PedidoID:
        FIND FIRST Produtos NO-LOCK WHERE ItensPedido.ProdutoID = Produtos.ProdutoID.

        DISP Pedidos.PedidoID Pedidos.Data
            Produtos.ProdutoID Produtos.Nome
            ItensPedido.Quantidade.
    END.
END.

Resumidamente, o programa lê todos os pedidos, para cada pedido localiza os itens correspondentes, e para cada item localiza o produto correspondente. Depois exibe as informações em tela.

Com DataServer SQL, este programa solicitará ao banco de dados todos os pedidos utilizando um default result set. Quando o primeiro pedido estiver sendo processado, será necessário ler os itens deste pedido. A conexão que foi utilizada para ler os dados do pedido está ocupada, pois somente o primeiro pedido foi lido até este momento. Neste ponto o DataServer abre uma nova conexão ao banco de dados para ler os itens do pedido. Depois de ler o primeiro item do pedido, é necessário localizar o produto correspondente ao item. A conexão de pedidos ainda está ocupada, e a conexão de itens também. Logo, será aberta uma terceira conexão para leitura do produto.

O número exato de conexões varia conforme o número de registros, pois o DataServer mantém alguns registros em cache. De forma genérica, podemos dizer que sempre que o DataServer determinar a leitura de dados utilizando default result sets e todas as conexões ao banco de dados estiverem ocupadas, uma nova conexão será aberta.

Mais informações sobre default result sets na documentação do SQL Server.

Categorias: DataServer | SQL Server

Comentar




biuquote
  • Comentário
  • Pré-visualização
Loading


Acesso LogMeIn

Informe o código PIN: