Artigo Clube Delphi 87 - Performance no Firebird e ADO.NET

Para instalar no Delphi 2006, acesse o menu Component>Installed Components. No editor, digite “Firebird” em Category, clique no botão Select an Assembly e escolha o arquivo FirebirdSql.Data.Firebird.dll, que por padrão encontra-se  em: C:\Arquivos de programas\FirebirdNETProvider1.7. Clique em OK e veja na Tool Palette os componentes instalados para acesso ao Firebird.

Connection Pooling

Inicie uma nova aplicação ASP.NET no Delphi 2006. A partir da Component Palette, coloque um FbConnection no Web Form. Selecione o componente e no Object Inspector acesse o editor da propriedade ConnectionString. No editor que aparece informe os parâmetros para acesso ao banco Employee.fdb do Firebird.

Com isso, configuramos a conexão ao Firebird usando o provider nativo, a primeira dica de performance (jamais use OleDB,  ODBC ou outro provider nesse caso).

Figura 1. Parâmetros de conexão ao Firebird

Observe que em User Name e Password informamos um usuário e senha padrão para acesso ao banco. Aqui vai a segunda dica valiosa para otimização: forneça um usuário e senha fixos, de forma que todos os usuários que conectem à aplicação utilizem as mesmas credenciais.

Se for necessário restringir acesso a determinado usuário, defina isso na forma de autorizações no Web.config. Fornecer um usuário fixo fará o ADO.NET utilizar de forma efetiva o recurso de Connection Pooling, sem ter perda de desempenho.

Connection Pooling é o mecanismo que permite ao ADO.NET reaproveitar conexões ao banco de dados. Imagine a seguinte situação: um usuário acessa a aplicação, conectamos ao BD para extrair informações e a exibimos no formulário. A seguir, fechamos a conexão e devolvemos o resultado ao browser.

Como aplicações Web são state less (sem estado), se esse mesmo ou outro usuário se conectar à aplicação, uma nova conexão precisará ser restabelecida. Conectar ao BD a cada requisição de usuário é literalmente um suicídio em ambiente Web, onde uma aplicação pode ter centenas e até milhares de conexões simultâneas.

O ADO.NET resolve isso de forma bastante elegante: após a página ser enviada ao browser, a conexão com o BD não é liberada, mesmo que você tenha chamado explicitamente o método Close do FbConnection. O ADO.NET guarda automaticamente a conexão em pool (imagine isso como uma espécie de cache de conexões).

Ou seja, a conexão fica aberta com o banco de dados e persiste entre requisições. Quando outro usuário conectar na aplicação, o ADO.NET verifica se existe uma conexão disponível no pool e caso encontre, a utiliza. Com isso, todo o tempo necessário para localizar o servidor de BD, estabelecer uma conexão, autenticar um usuário e verificar permissões não será mais consumido a cada requisição.

E o melhor de tudo, você não precisa fazer nada para usar esse recurso, pois ele já é ativado por padrão. Criar um mecanismo de Connection Pooling “no braço” via código é algo extremamente complicado (infelizmente já tive que passar por esse esforço em uma ocasião). No ADO.NET já temos isso pronto no próprio framework. Produtividade é um dos pontos fortes do .NET.