Pesquisa personalizada

O ASP.NET é, inegavelmente, muito mais simples do que o ASP 3.0. Os desenvolvedores não precisam ter profundo conhecimento de web/redes para desenvolver com ASP.NET.

Mas a grande facilidade que o ASP.NET fornece pode facilmente se transformar em um problema. Isso porque apesar dos Wizards gerarem aplicações funcionais, eles não levam em consideração as características específicas da web e consequentemente implementam códigos pesados, com muitos problemas de performance.

Vamos analisar alguns problemas de performance que os Wizards podem gerar dentro de um código do .NET

Quando usar um DataSet na página

A grande questão é : Deve-se utilizar um DataSet ou um DataReader ? Já que o DataReader pode em geral ser vinculado aos web Controls, por que utilizar DataSet ?

A resposta é simples : Utilize o DataReader sempre que possível. Na maioria das vezes você não precisa utilizar o DataSet, basta obter os dados do banco em um DataReader e vincula-los.

Então, quando usar um DataSet na Web ?

A grande questão é : DR x DataSets, como escolher ?

Se você baseia todo seu projeto no uso de DataReaders, então você está indo com muita frequencia ao banco. A cada postback você terá que ir ao banco novamente carregar os dados, isso pesa o servidor de banco.

Se você baseia seu projeto no uso de datasets, então o(s) Dataset(s) pode(m) ficar em sessão, aplicação ou cache. Desta forma você faz um mínimo de consultas ao banco, apenas para trazer os dados para a memória do servidor Web, o resto é feito no servidor Web. Com isso você libera o banco de dados, mas pesa o servidor Web.

Qual é melhor ? A escolha depende de muita análise. Ir ou não ir com frequencia ao banco pode depender da natureza dos dados e características da aplicação. Além disso são necessários BenchMarks para definir que metodologia pode ser mais adequada.

Mas uma coisa é fato : Fazer o meio termo entre estas opções é bobagem. Ou seja, utilizar DataSets, mas ainda assim não guarda-lo (session/application/cache) e continuar indo ao banco em cada postback é perder performance com o custo da montagem do dataset e não ganhar escalabilidade, já que os acessos a banco não são reduzidos, pelo contrário, acabam sendo mais pesados do que com um uso planejado de DataReaders.

E os Adapters, qual a melhor forma de trabalhar com eles ?

O Wizard de geração dos adapters gera automaticamente 4 commands : Um para select, um para insert, um para delete e um para update.

Se a sua página não irá realizar todas essas operações (e na maioria das vezes realmente não vai) então você já está consumindo recursos desnecessariamente, gerando mais objetos do que realmente precisa. Esses objetos ao serem criados no designer da página geram códigos no evento Page_INIT que sobrecarregam todos os postBacks realizados na página.

Mas a questão é ainda um pouco mais grave : Mesmo que sua página vá realmente realizar as 4 operações, ela com certeza NUNCA irá realizar as 4 operações no mesmo postBack. Vamos a um exemplo mais claro : se sua página irá realmente realizar essas 4 operações, ou pelo menos 3 delas, posso supor que você está usando uma datagrid do ASP.NET. A DataGrid possui vários eventos que causam o PostBack, como por exemplo, SelectedIndexChanged. O SelectedIndexChanged a principio não precisa de nenhuma programação para que um item da grid seja selecionado. Mas se você está usando um adapter com os 4 commands, a cada vez que um item for selecionado os 4 commands serão inicializados, sem nenhuma utilidade pois nenhum deles será executado, serão apenas destruidos logo em seguida.

Então como fazer ? Simples, siga uma regra básica : Apenas crie no designer aquilo que você tem absoluta certeza que irá precisar em todos os postbacks. O que você não precisar criar em todos os postbacks não precisa criar no Designer.

Uma opção, para manter a facilidade fornecida pelos wizards, é criar todos os objetos através do designer mas posteriormente mover o código de criação para o local adequado, de acordo com os postBacks que a página irá possuir.

E os Commands, tudo bem com eles ?

Não adianta deixar de gerar os commands do adapter, mas em separado incluir 4 commands no designer. Minha sugestão de que você evite a geração dos commands do adapter é justamente para evitar a criação de commands desnecessariamente, portanto é necessário que você crie e destrua commands apenas nos momentos em que realmente vai utiliza-los.

DataGrids

Um dos recursos mais polêmicos da DataGrid é, com certeza, a paginação.

A paginação ficou muito simples na DataGrid, simples até demais. O excesso de simplicidade pode fazer com que muitos desenvolvedores deixem de observar uma característica importante : Se a paginação padrão da grid for utilizada fazendo acesso a banco, então todos os registros (Sabe-se lá quantos, 100.000 talvez) estarão sendo lidos a cada página exibida. Isso é extremamente prejudicial a performance.

Uma solução alternativa é manter o DataSet em sessão, evitando assim múltiplas consultas ao banco. Essa solução, porém, só é viável com pequenos conjuntos de dados, por motivos óbvios.

A solução é utilizar o custom paging da grid, o que exige bastante codificação adicional. Estarei escrevendo um artigo sobre isso posteriormente aqui no site.

Mas não pense que por causa disso a paginação padrão é inútil, já que não ganhará performance no acesso aos dados. A aplicação da paginação padrão evita que a grid gere um viewstate muito grande e consequentemente agiliza (consideravelmente) a performance de cada chamada.

Vamos aos testes

Fiz alguns testes utilizando o Application center test para comparar a performance de várias opções de desenvolvimento. Para saber mais sobre o Application center test você pode ler nosso artigo anterior sobre teste de peformance.

A primeira aplicação que testei foi uma aplicação simples exibindo a tabela customers em uma grid, mostrando um botão "selecionar" e permitindo a seleção de registros. No script de teste inclui a primeira entrada na tela e a seleção de alguns registros. O teste foi realizado com um total de 200 repetições e os resultados estão logo abaixo.

Vale ressaltar alguns pontos :

• Os testes nunca são muito precisos, dependem de muitas configurações na máquina em que são realizados.
• Os testes realizados fazem comparação de performance, não testam a escalabilidade. Assim sendo os testes nos dizem qual opção roda mais rápido, mas NÃO qual consome menos recursos por menos tempo, garantindo o atendimento a um grande volume de usuários.

Testes com DataSets

Legenda

Índices

ATLBI : Tempo médio até o último byte de uma iteração inteira, ou seja, uma repetição de todo o conjunto de requisições gravado.

ATFB : Tempo médio até a chegada do primeiro byte

ATLB : Tempo médio até o último byte de uma requisição

Aplicações

A1 : Aplicação com os objetos criados no designer

A2 : Aplicação criada com restrições no DataAdapter, de forma a gerar apenas um command, o de select, ao invés dos 4.

A3 : Aplicação criada com Connection e DataAdapter (com apenas um command) no designer e um DataSet untyped criado em código.

A4 : Idem A3, mas com DataSet Typed.

A5 : Idem A4, mas utilizando as instruções BeginLoadData/EndLoadData ao dar o Fill no DataSet

A6 : Idem A5, mas com o DataAdapter gerado em código.

A7 : Aplicação utilizando conexão, DataAdapter e dataset tipado em código, fazendo uso também do BeginLoadData e EndLoadData.

A8 : Idem A6 mas sem ViewState

A9 : Idem A7 e com OutputCache de 20 segundos

Conclusões do primeiro teste

Evitar o ViewState e aplicar OutputCache são dois recursos que forneceram grande ganho de performance. São recursos que devem ser aplicados sempre que possível, mas nem toda aplicação permite que se faça isso.

Tivemos dois ganhos de performance observáveis : Quando passamos o DataSet para o código e quando passamos a conexão para o código. Passar o adapter para o código sem passar a conexão não gerou ganho, podendo até ter gerado perda (isso não é certo, pode ser uma simples imprecisão do teste).

Observamos que utilizar um DataSet tipado gerou ganho de performance, desde que seja feito uso do BeginLoadData e EndLoadData, caso contrário os DataSets tipados perdem performance em comparação com os não tipados.

Comparando estes testes com os que realizamos com aplicações ASP 3.0 vemos que se os recursos do ASP.NET forem usados de forma descuidada podem gerar perda de performance, mas se bem utilizados podem gerar aplicações bem mais robustas que as aplicações ASP 3.0.

Testes com DataReaders

Utilizei a mesma aplicação, com uma gravação identica, para fazer testes com DataReaders. Veja os resultados abaixo.

Obs: Os códigos de aplicação indicam a equivalência destes testes com os testes com DataSets. Mas aqui usei apenas DataReaders, não DataSets.

Conclusões do 2o teste

Os resultados são muito parecidos com os do primeiro teste, podem se tratar apenas de imprecisões do teste.

Os resultados tão parecidos deixam claro que a escolha entre os DataSets e DataReaders dependem da escalabilidade (que não foi testada) e não da performance.

Em situação normal um DataSet em código parece ter pequeno ganho de performance. Evitando o ViewState o DataReader é um pouquinho melhor, mas utilizando cache o DataSet volta a ter melhor performance.

Testes com grids complexas

Fiz uma 2a aplicação para comparar o uso de múltiplas chamadas ao banco com a colocação de um DataSet em sessão. Desta forma comparei 2 aplicações : a primeira (chamarei de A10), indo ao banco a cada postback e a segunda (chamarei de A11), mantendo o dataset guardado em sessão.

Por comodidade fiz os testes utilizando apenas componentes criados via Designer. Isso significa que o tempo de ambas as aplicações ainda poderia melhorar consideravelmente.

Conclusões do 3o teste

Apesar dos efeitos na escalabilidade ainda serem uma incógnita, podemos observar que manter o DataSet em sessão claramente nos traz um bom aumento na performance, tal como havia citado anteriormente.

Enfim,

Espero que estas demonstrações ajudem você a ficar atento a características de performance no ambiente do .NET

Dennes Torres
MCSD,MCSE,MCDBA

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Conheça mais sobre o nosso site :

• Visite nossa área de artigos técnicos
• Conheça nossas dicas técnicas (mais de 300 dicas)
• Conheça nosso fórum de discussões
• Conheça nossa área de download com muitos componentes e códigos úteis
• Conheça nosso treinamento de lógica de programação on-line
• Conheça nossa prova de certificação em VB (oferecemos certificado aos aprovados)

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::