Clique aqui para ler todos os artigos desta edição
DataReaders, SP’s, Cache, DataSets e Connection Pooling
Neste artigo destaco algumas dicas interessantes para otimizar aplicações ASP.NET. Veremos como a tecnologia oferece poderosos recursos para tornar suas aplicações Web robustas e escaláveis, usando o mínimo de esforço possível. Conheceremos os poderosos recursos de cache de dados, uso efetivo de stored procedures, connection pooling e outras técnicas avançadas.Você aprenderá como usar DataSets em memória para evitar consultas desnecessárias ao servidor SQL e otimizar assim o tráfego de dados. Você também conhecerá um pouco sobre o interessante recurso de connection pooling do ADO.NET.
Para construir os exemplos desta série, utilizarei o Visual Studio .NET 2003 e o SQL Server 2000 como banco de dados. As aplicações serão feitas usando C#, mas podem ser facilmente escritas em VB.NET, caso queira utilizar essa linguagem.
Connection Pooling
No Visual Studio, clique em File>New>Project (ou aperte Shift+Ctrl+N) e na janela New Project escolha ASP.NET Web Application no item Visual C# Projects. Na opção Location dê um nome para aplicação e a seguir clique em Ok.
A partir da ToolBox, coloque um SqlConnection no Web Form. Selecione o componente e na janela Properties escolha New Connection na propriedade ConnectionString. No editor que aparece informe o nome ou endereço IP do servidor na primeira caixa de entrada. Em User name e Password informe o usuário e senha padrão para acesso ao banco. E finalmente, escolha o banco de dados Northwind e clique em Ok. Caso queira, clique no botão Test Connection para verificar se os parâmetros estão corretos. Com isso, configuramos a conexão ao SQL Server usando o provider SQL, a primeira dica de performance (jamais use OleDB ou ODBC nesse caso).
Observe que em User name e Password informamos um usuário e senha padrão para acesso ao banco, mas poderíamos ter usado a autenticação integrada. No entanto, 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 SqlConnection. 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.
Nota: O Connection Pooling só pode ser usado em ambiente multi-thread (uma aplicação Web, por exemplo), onde temos várias "
