Skip Navigation Links



Translate this page now :



»Programação
»Programação.NET
»Banco de Dados
»Webdesign
»Office
» Certificações Microsoft 4
»Treinamentos4
»Programação 4
»Webdesign«
»Office & User Tips«
»Grupos de UsuĆ”rios
»CĆ©lulas AcadĆŖmicas«
intcontpiada : 118
O melhor teclado da microsoft
Você já está cadastrado e participa do grupo de usuários de sua cidade ? Se não, comente o porque.
 
 
FaƧa um pequeno teste com 10 questƵes de VB
.:.
Teste seus conhecimentos em Visual Basic, SQL Server e ASP 3.0 com nossas provas on-line
.:.
Aprimore seus conhecimentos em programaĆ§Ć£o com nosso treinamento on-line de lĆ³gica de programaĆ§Ć£o
.:.
Veja nosso calendƔrio de treinamentos
Gostou da PƔgina?
Então

para um amigo!

Pesquisa personalizada
Pesquisar Dicas:

 






Saiba mais sobre o assunto

::Faça um treinamento Búfalo e
garanta sua profissionalização::

Inscreva-se Já!


Otimizando a performance no ASP.NET

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

 

Indices\Aplicação
A1
A2
A3
A4
A5
A6
A7
A8
A9
ATLBI 541.26 535.14 509.97 510.52 507.00 510.54 501.56 239.14 166.36
ATLB 90.21 89.19 85.00 85.09 84.50 85.09 83.59 39.86 27.73
ATFB 85.08 84.02 79.61 79.83 79.12 79.65 78.65 39.52 27.32

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.

Índices\Aplicações
A7
A8
A9
ATLBI 509.80 234.50 175.82
ATLB 84.97 39.08 29.30
ATFB 80.97 38.74 28.29

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.

Índices\Aplicações
A10
A11
ATLBI 280.51 229.06
ATLB 15.58 12.73
ATFB 15.22 12.34

 

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





Envie seus comentįrios sobre este artigo

Nome :

E-mail :

Comentários :


Avise-me quando houverem novos comentįrios nesta pįgina

Veja abaixo os comentários já enviados :

Nome : ernane E-Mail : nanincrato@hotmail.com
Vc tem os fontes dessa aplicação que vc realizou os testes ? pois tem opções que vc utilizou e que foram melhores que ainda não sei como implememtar , gostaria muito de aprendetr
Nome : cesar meneguzzi E-Mail : cesarmene@gmail.com
muito interessante, muito bom, parabens...

a proposito, estou fazendo um sistema de consultas e preciso de uma sugestao.

meu sistema é desktop....

o usuario parametriza as condicoes e o sistema vai executando..

exemplo: todos os valores salariais do ano 2005 de mes 03..
o que eu preciso fazer é executar esta consulta acho que
com um datareder e depois gravar o resultado em talvez um xml,
porque o usuario depois pode ficar na tela de resultado e fazer
n pesquisa somente na consulta retornada...
será que usando datareader e depois gerando o xml e depois
jogar isto para um datagrid eu estou no caminho certo???

Nome : Bruno Kenj E-Mail : obruto@gmail.com
Muito bom Dennes. Montei um relatório de chamados com DataSet em sessão e é impressionante como ficou. Carrega 100.000 chamados bem rápido (segundos) e depois de montado, tanto páginação quanto sort, fica por conta da memória, sendo muito rápido. SmartNavegation ajudou pra não perder o foco do scrollbar. k+
Nome : Benedito Santana E-Mail : bene@igc.com.br
Caros Colegas Desenvolvedores.

Venho a muito acompanhando e aprendendo com muitos artigos de você, principalmente sobre DataSet Tipado.

Agora gostaria de saber como aplicar o uso de um TableAdapter.UPDATE em uma transação.

Obrigado
Bene
Nome : Ivan E-Mail :
Azgavdá?
Nome : 1 E-Mail : 1
-1'
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
-1'
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
-1'
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : Yjg3205aj2q E-Mail : j0uejqjd@yahoo.com
I am trying to riceeve DASH streaming in VLC (ver. 2.1.0-git) through an HTTP proxy, with http-proxy option set in VLC. However, DASH plugin seems to ignore this setting. The old version of the plugin (VLC 2.0.3) respected this setting. Is it a known problem?
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : hwZFyGkN E-Mail : ddnxuu7aw7g@yahoo.com
I believe it was a mistake to remove gadgets&games, there are a lot of kids who don't want to troll through all the juirknudity/p/ofannty etc that ends up in Entertainment to find their favourite game videos to watch, please bring back gadgets&games for the kids sake.

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

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



Quer saber mais?
Faça um curso na Búfalo Informática, Treinamento e Consultoria e
Prepare-se para o Mercado!
Veja o que a Búfalo tem para você.

ļæ½ BĆŗfalo InformĆ”tica, Treinamento e Consultoria - Rua Ɓlvaro Alvim, 37 Sala 920 - CinelĆ¢ndia - Rio de Janeiro / RJ
Tel.: (21)2262-1368 (21) 9240-5134 (21) 9240-7281 e-Mail:
contato@bufaloinfo.com.br