Introdução ao .NET Core

Já tem algum tempo que ouço burburinhos a respeito da mais nova versão da plataforma .NET, a .NET Core. Inicialmente era apenas uma versão 5 da tradicional plataforma de desenvolvimento para Windows, depois começaram a falar sobre suporte multi-plataforma e um tal de .NET vNext. Recentemente parece que estabilizaram tudo em um tal de .NET Core que rodaria em qualquer plataforma, seria uma versão “capada” do framework, muito mais leve e veloz, open-source, que não precisa de Visual Studio e muitas outras coisas interessantes…

Eu estou longe de ser um early adopter (detesto betas…) mas uma vez que as “boas notícias” acerca da plataforma não param de surgir, eu tive de fazer alguma coisa a respeito. Eu tive de estudar .NET Core.

E não me arrependi.

Hoje trago um resumo do que pude perceber a partir de diversos vídeos, tutoriais e é claro, coloquei a mão na massa testando a plataforma.

Neste artigo você vai ver:

  1. O que é?
  2. Para quê serve?
  3. Como eu programo?
  4. Olá Mundo!
  5. Indo em frente

O que é?

O .NET Core não é a nova versão do .NET como eu imaginava. É um novo .NET, uma bifurcação no desenvolvimento da plataforma. Enquanto o .NET 4.6 segue o seu caminho normal, o .NET Core inicia uma nova jornada.

Se é que é possível resumir em uma frase, o .NET Core é: uma plataforma de desenvolvimento modular, open-source, para múltiplos sistemas operacionais e fundamentada na linguagem C#.

Por modular entenda que não há mais a necessidade de ter o .NET Framework “full” instalado na máquina onde seu sistema irá rodar. Você começa um projeto com apenas as bibliotecas mais básicas do runtime e vai adicionando mais módulos conforme a necessidade. Através de um sistema de gerenciamento de dependências (NuGet), em qualquer máquina que seu sistema for rodar, as bibliotecas serão baixadas automaticamente pela Internet, permitindo inclusive múltiplas configurações diferentes em cada máquina uma vez que são independentes.

Por open-source entenda que o projeto é mantido pela Microsoft, mas que a mesma disponibilizou os fontes no Github e tem se mostrado bem aberta à discussões e contribuições ao mesmo.

Por “múltiplos sistemas operacionais” entenda que, no momento que escrevo este post, já há suporte para Windows, Mac e diversas distribuições Linux, sendo que em breve devemos ter suporte a outras plataformas como Smart TVs, por exemplo. Além disso, há o suporte à Docker, que proporciona uma melhor compatibilidade com as nuvens computacionais atuais.

Para quê serve?

Você pode criar aplicações multiplataformas para console e web com o .NET Core, bem como bibliotecas de classes com C#. Não há Windows Forms aqui, Universal Windows Apps ou Windows Phone Apps, esses tipos de softwares continuam como estão, até onde pude entender.

No momento não se recomenda a migração de sistemas escritos no .NET 4.6 para o .NET Core, pois muitas das bibliotecas antigas não existem na plataforma, bem como não há compatibilidade com bibliotecas C# de terceiros. E mesmo para sistemas novos que venham a exigir um alto desempenho e escala ainda não está se recomendando utilizar a plataforma por ela ainda ser muito recente e imatura em relação à sua antecessora.

Os benchmarks mostram ganhos expressivos de velocidade frente a outras plataformas, mas ainda é cedo para apostar todas as suas fichas na plataforma, que está evoluindo rápido, mas precisa de muita coisa ainda.

Existe uma camada de bibliotecas compartilhadas chamada .NET Standard Library que ainda está em desenvolvimento e que permitirá uma maior compatibilidade entre as duas versões de .NET mais recentes (.NET 4.6 e .NET Core) e que permitirá também, um suporte à mais aplicações. A previsão é que a versão 2.0 da Standard Library, prevista para 2017/Q3 nos traga mais boas notícias neste sentido.

Via de regra, se você ainda for permanecer apenas com servidores Windows, não há um real motivo para migrar. Por enquanto.

Como eu programo?

A primeira notícia interessante em relação ao .NET Core é que ele funciona completamente via linha de comando. Eu não sou fã de linha de comando, mas o que isso traz é muito interessante: maior suporte a editores de texto como VIM, Sublime, Visual Studio Code, OmniSharp e muito mais. Resumindo: você não precisa mais ter o Visual Studio na sua máquina para programar .NET Core. Logo agora que a Microsoft está lançando o VS para Mac
Para quem ainda for usar o VS, estão acontecendo algumas confusões em relação ao wizard de novo projeto, onde você pode escolher rodar o .NET Core no .NET Framework ou rodar o .NET Core no .NET Core.

Como assim?

Como o .NET Core é uma versão capada do .NET Framework, há esse tipo de compatibilidade. No entanto, vale lembrar que somente há VM de .NET Framework para Windows, sendo assim, não vale a pena usar .NET Core rodando no .NET Framework se você gostaria de usar outros SOs. Você ganha em confiança da plataforma mais madura, mas perde em interoperabilidade.

Olá Mundo!

Para fazer um olá mundo com .NET Core é muito fácil. Nem parece a mesma plataforma Microsoft que comecei a ver lá em 2007. 🙂

Primeiro, acesse o site oficial e baixe a versão do utilitário de linha de comando para seu sistema operacional. Instale após baixar. Obviamente. 😐

Depois, abra seu terminal e digite a seguinte linha de comando para criar um novo projeto console na sua pasta atual:

Isso irá criar a pasta do projeto com todo o básico para o Olá Mundo dentro.

Antes de rodar, primeiro você deve restaurar as dependências desse projeto. Para isso, entre na pasta do projeto pelo terminal e mande rodar o seguinte comando:

Isso irá baixar as dependências externas localmente, deixando tudo pronto para rodar. Ainda dentro da pasta do projeto, execute o comando abaixo para executá-lo:

Isso irá compilar o projeto e executá-lo. Caso não exista nada errado, a mensagem de olá mundo será impressa no console.

Note que rodei estes comandos no Mac. Funciona perfeitamente!

Experimente agora criar um projeto web, usando o seguinte comando (lembrando de sair do projeto console):

Entre na pasta do projeto, execute o “dotnet restore” e o “dotnet run”e após o servidor subir, abra seu navegador e digite localhost:5000 para ver o site MVC de exemplo que ele criou para você.

Indo em Frente

O utilitário de linha de comando possui o comando –help que lhe traz toda uma documentação sobre cada um dos comandos e opções existentes, e tem sido muito útil para que eu possa aprender diversas coisas como criar Solutions, adicionar projetos em Solutions, compilar projetos, criar diferentes boilerplates e por aí vai.

Obviamente ficar fazendo tudo assim via linha de comando na tentativa e erro não vai levar você muito longe e escrever sistemas usando Nano (que é o editor que eu uso no terminal) não é muito prático. Você pode optar por se manter com o Visual Studio, a versão Community é gratuita e bem completa, mas consome muito recurso de máquinas modestas. Outra sugestão é baixar e instalar o Visual Studio Code, um editor de texto também da Microsoft mas com as features essenciais que você deve precisar como debug, integração com Github, um marketplace rico de extensões para diversas linguagens e suporte a Mac, Windows e Linux.

Escolha seu editor de texto favorito e acompanhe os tutoriais oficiais no site da Microsoft. De minha parte, pretendo colocar alguns posts ocasionais sobre a plataforma, que tem dividido a minha atenção atualmente com Node.js.

Ah, antes que eu me esqueça: estamos trabalhando com .NET Core em alguns projetos da Umbler e já disponibilizamos suporte à plataforma para o plano Cloud Sites (ambiente virtualizado dedicado). Caso tenha interesse em hospedar algum projeto.

Seguem os slides que usei no vídeo desse post:

ASP.NET Button não dispara postback

Outros nomes possíveis para este post seriam “ASP.NET Button não funciona” ou “Que m**** que está acontecendo com meu formulário?”. De qualquer forma, este post será bem rápido. O objetivo é listar algumas causas comuns que fazem com que botões parem de funcionar com ASP.NET Webforms. Não há nenhuma mágica ou bug conhecido, apenas falta de atenção ou prática com a construção de formulário com este padrão de desenvolvimento web da plataforma .NET. Acredito que este post será vivo, ou seja, irei colocando mais conteúdo conforme for descobrindo mais causas para este problema.

O Problema

O problema é simples e objetivo: você tem um formulário ASP.NET com um botão. Você clica no botão e o que deveria acontecer não acontece. Claro, tem algumas variações, que podemos chamar de sintomas. Para cada sintoma, há um remédio diferente.

A tela apresenta um erro

Se a tela apresenta um erro em ASP.NET, considere-se com sorte pois geralmente os erros são muito bons em dizer onde está o problema. Alguns erros comuns incluem você estar com sua tag ASP.NET mal formada, como falta de runat=”server” ou similar. Dê uma revisada nas linhas do seu ou .cs conforme mencionado no erro e acredito que não terá problemas.

Um erro comum de funcionamento de botão é quando utilizamos eles dentro de algum controle de repetição, como Repeater. Em geral os programadores esquecem que colocando o comportamento de carregar o repeater dentro do Page_Load, o mesmo será chamado toda vez acontecer algum postback, inclusive quando um botão é clicado. Por isso, é uma boa prática colocar uma verificação no Page_Load para somente carregar se não for um postback. Mas o que isso tem a ver com problemas de botão? Quando a página carrega a primeira vez e o botão é renderizado, ele possui um identificador único no ViewState, que, caso seja recarregada a tela, será alterado. Com isso, o botão que originalmente chamou o postback não existe mais e a chamada fica como se fosse anônima ou “injetada”, o que é uma violação de segurança do ASP.NET que causará um erro.

A tela não apresenta erro

Aqui que mora o problema, quando estamos às cegas com um botão não funcionando. Uma dica é, usando o Google Chrome, abrir as ferramentas (F12) e ver no Console se não tem algum erro de Javascript. Isso é bem comum quando usamos UpdatePanel, que por padrão suprime os erros da página. Em geral os erros de Ajax não são muito esclarecedores, mas basta executar tudo novamente com F5, para depurar, que se acontecer o erro novamente o depurador do Visual Studio vai te levar até a linha do erro.

Às vezes o ASP.NET não apresenta erro pois de fato não existe erro. Ou seja, é algum problema de lógica ou algo Javascript seu que está bloqueando a execução do botão. Veja se seu botão não possui um OnClientClick definido, pois se caso possuir, tenha certeza de que o método Javascript associado retorna true para garantir a continuidade da execução do botão. Ainda no assunto Javascript, revise se na sua página não existe alguma tag script mal formada, lembrando que a tag script sempre deve ser fechada com o padrão “>” e jamais com a versão enxuta “/>”, caso contrário lhe trará problemas. Sim isso é muito idiota, mas acontece, então se liga!

Um último adendo cabe aos ASP.NET Validators. Por padrão os Validators, como o RequiredFieldValidator, fazem a validação via Javascript antes de qualquer postback, e caso tenha qualquer problema em sua página impedirá que o postback aconteça. Se você usa validadores em qualquer ponto de seu formulário, pode ser uma boa verificar se não são eles que estão impedindo seu botão de funcionar. Esse ponto se torna ainda mais importante caso você esteja usando WebUserControls na sua página, pois às vezes eles estão escondidos, como em modais, mas mesmo assim com seus Validators ativos, impedindo o postback da página. Uma ideia pode ser dizer que seu botão não causa validação, definindo a propriedade CausesValidation para false. Isso claro, se o click do seu botão não for interferir com os demais dados do seu formulário.

Espero ter ajudado.

Tem mais algum caso em que seu botão não funciona e que deseja compartilhar? Outro detalhe que deixei passar? Escreva nos comentários!

ASP.NET Tunning

Boa noite pessoal, este post é um apanhado de dicas de como aumentar a performance de suas aplicações ASP.NET. Todas foram testadas na prática por mim no projeto do Busca Acelerada, que de tão rápido que é, o pessoal nunca acredita que é feito em ASP.NET, hehehe. Muitas das dicas são para quem programa com WebForms, pois eu não utilizo ASP.NET MVC em meus projetos. É muito provável também que você não poderá utilizar todas essas dicas devido à natureza de sua aplicação, eu uso todas, mas o Busca Acelerada é um projeto bem fora do comum mesmo, então não é parâmetro. Ou seja, nem tudo que eu disser aqui vai se aplicar ao seu caso. Sugiro usar este post em conjunto com os outros dois que tem aqui no blog sobre como aumentar o desempenho de websites.

E por último, pretendo atualizar este post periodicamente conforme for encontrado mais dicas por aí ou for descobrindo coisas novas por minha conta mesmo.

Session

Todo mundo já deve ter ouvido falar mal do uso de sessões em ASP.NET. A sessão é uma área de memória no servidor alocada para cada usuário utilizando seu sistema. Além de um tempo de expiração definido na aplicação e/ou no servidor, a sessão é “apagada” quando o usuário fecha o navegador. Como qualquer coisa salva na memória do servidor, algo extremamente concorrido e limitado, deve ser usado com parcimônia. Ou melhor, não use.

No Busca Acelerada adotamos a política de não utilizar sessão. Em casos raros utilizamos cookies na máquina do cliente ou simplesmente passamos as informações via QueryString. Para deixar de utilizar sessão, não basta não salvar dados na Session, mas sim deve marcar suas páginas com o atributo EnableSessionState=”False”, na diretiva Page. Se você tem a mania de usar sessão apenas para passar um dado de uma página para outra (um ID para editar um cliente, por exemplo), considere passar esta informação via querystring e poupe a memória do seu servidor.

View-State

A menina dos olhos do pessoal que gosta de WebForms e o terror dos webdesigners. O ViewState garante que entre um PostBack e outro, os seus dados ainda estarão persistidos, salvando e criptografando todos em um hidden field no seu HTML. Quanto mais server controls com runat=”server” você possuir em seu ASPX, maior será o tamanho do seu view-state e consequentemente o tempo de download da página. Mais que isso, processar grandes viewstates consome tempo de processamento do servidor, principalmente se você parar pra pensar que este dado é criptografado.

Aqui temos dois ajustes a serem considerados: tamanho do arquivo (e consequente tempo de download) e processamento do servidor. Eu abracei os dois e não utilizamos view-state no Busca Acelerada. Caso tenha que utilizar view-state no seu projeto, mas os campos do seu formulário não possuem dados sensíveis (i.e. sigilosos) ou sua aplicação está sobre SSL, desabilite a criptografia do Viewstate na diretiva page do seu ASPX com o atributo ViewStateEncryptionMode=”Never”. Isso irá diminuir o processamento no servidor.

Caso possa abrir mão completamente do view-state, adicione o atributo ViewStateMode=”Disabled” na diretiva Page, o que vai reduzir o tamanho do HTML gerado. Caso não possa fazer isso pois precisa manter o estado entre os Postbacks, tente reduzir o tamanho do seu ViewState com as seguintes dicas:

  • se o texto jamais é alterado via C#, jamais use uma asp:Label para exibi-lo. Prefira a tag label do HTML ou apenas escreva literalmente na página.
  • use o menor número possível de ASP Controls no seu formulário e elementos com runat=”server”
  • desabilite o viewstate para controles que você não precisa manter estado entre postbacks, como botões e repeaters por exemplo. Use a propriedade ViewStateMode do controle para desativá-lo.

Event Validation

O ASP.NET por padrão é um dos frameworks web mais seguros da atualidade. Por padrão ele já protege contra injeções de script em formulários, por exemplo. Caso você já faça a sua própria validação no lado do servidor e/ou possua outros mecanismos de proteção para isso, considere desabilitar a validação de eventos na diretiva page de suas páginas com o atributo EnableEventValidation=”False”. Note que EventValidation é completamente inútil em páginas que não possuam campos de entrada de dados.

Web.Config

Muitas são as dicas de otimização de performance que podem ser feitas diretamente no web.config. Além de várias das dicas anteriores, que podem ser feitas a nível de página ou de aplicação, tem algumas que são exclusivas deste arquivo. A saber:

  • se sua aplicação não usa nenhum tipo de autenticação, declare o authentication mode como none. Remover a tag não adianta, pois o ASP.NET assumirá o padrão como Windows, que consumirá processamento do servidor durante as requisições de página.
  • em produção, declare  para economizar processamento e memória no servidor, desabilitando o recurso do ASP.NET de registrar todos os “movimentos” dos usuários para uma melhor depuração, visto que em produção não é lugar para depuração!
  • em produção, use compilation em debug=”false”. Você notará que por padrão o web.config já possui uma tag compilation. Substitua ela por essa quando em produção, para diminuir o consumo de memória e o tempo de compilação da aplicação, definindo que não deverá manter informações para debug em memória e já dizendo exatamente a linguagem e framework de sua aplicação.
  • use sessionState em mode=”off” caso queira desabilitar a sessão para toda sua aplicação, reduzindo o consumo de memória no servidor ou  para definir várias configurações de página ao mesmo tempo.
  • use customErrors sempre como On ou RemoteOnly em produção, e aqui o motivo não é performance, mas sim segurança.

Web Services

Ao usar Webservices em sua aplicação ASP.NET, prefira pelos padrões mais modernos como o WCF e sempre que possível, faça-os sobre o protocolo REST, ao invés de SOAP. O intuito do post não é ensinar como se faz webservices de alto desempenho, mas vale lembrar que SOAP utiliza XML, o que cria arquivos maiores e processamento desnecessário nos casos em que não se precisa manter estado ou verificações de integridade. O REST é um padrão mais simples, leve e seguro se bem utilizado, como sobre SSL, por exemplo. Pense nisso, irá diminuir o tempo de comunicação com o webservice.

ASP.NET Ajax

Evite sempre que possível de utilizar o ASP.NET Ajax. Ao invés disso, prefira o uso de JQuery e suas funções load, post, getJSON, entre outras, que fazem muito bem o seu papel e removem overheads desnecessários na sua aplicação, como aumento de viewstate, por exemplo. Nem vou citar o famigerado Ajax Control Toolkit, simplesmente não use ele.

Javascript

Use Javascript sempre que possível para solucionar problemas que não envolvem segurança. Isso irá diminuir seus postbacks e aumentará a velocidade das páginas, melhorando a experiência dos usuários. Muitos desenvolvedores ASP.NET odeiam Javascript, e eu já fui um deles. Coloque na sua cabeça que é muito importante aprendê-lo principalmente para distribuir o processamento entre os usuários ao invés de acumular tudo no seu servidor, sobrecarregando-o. Frameworks como JQuery e Bootstrap ajudam bastante a romper esse estigma do Javascript e são muito produtivos.

Generic Handler

Sempre que você precisar fazer uma comunicação de um código Javascript com o banco de dados ou com algum código C# dentro da mesma aplicação, prefira o uso de Generic Handler (.ashx) a qualquer outro método. O Generic Handler permite tratar requisições feitas de qualquer fonte (JS por exemplo) e permite retornar qualquer tipo de dado sem toda a pilha de execução de uma página ASP.NET tradicional. Quer carregar uma tabela do banco via JS? Chama um generic handler retornando uma lista de JSON. Quer salvar um dado JS no banco ou na sessão? Chama um Generic handler. Quer fazer uma página que a partir de um ID da URL baixa um arquivo? Chama um Generic handler, e por aí vai.

Para retorno de objetos a partir de um Generic Handler, sugiro o uso de JSON e somente em último caso XML, por ser mais pesado.

Postbacks

Evite postbacks sempre que possível. Postbacks geram processamento no servidor, sem contar o tempo dispendido trafegando dados pela rede. Quando postbacks são algo inevitável (botão de salvar formulário, por exemplo), tenha certeza de que no evento Page_Load da sua página existe uma verificação “Page.IsPostback == false” ou similar, para garantir que a página inteira não será carregada novamente para logo em seguida ter a ação do botão executada. Lembre-se que no ciclo de vida de uma página ASP.NET, o Page_Load acontece antes do que qualquer evento Click.

Output-Cache

Essa dica eu não uso, mas sei de vários casos em que foi utilizado e deu grandes melhorias. Eu não uso pelo simples fato de que memória é um recurso valioso para mim e processamento eu tenho sobrando no servidor, ou seja, a principal vantagem do Output-Cache, que é reduzir o processamento das páginas ASPX em páginas HTML tradicionais para serem exibidas no browser, não me serve pra muita coisa, além do fato de que o Busca Acelerada é atualizado em real-time, o que tornaria as páginas armazenadas em cache obsoletas rapidamente.

Se você tem memória sobrando no servidor ou possui páginas que são lentas para processar e quer melhorar seu desempenho, dê uma estudada sobre Output-Cache, que armazena as páginas HTML geradas pela sua aplicação na memória do servidor, evitando retrabalho.

Cache

Caso deseje armazenar dados na memória do servidor de uma forma mais gerenciável que na Session, aumentando o desempenho de sua aplicação, Cache é a solução. Não ensinarei aqui macetes de como usar cache, mas basta saber que é semelhante ao uso de Session mas é possível definir prazos de expiração para seu conteúdo baseados em tempo, em falta de uso por parte dos usuários ou até mesmo vincular a vida de um objeto em cache ao estado de uma arquivo ou pasta de arquivos.

Repeaters, ListViews, etc

Sempre pagine. Óbvio não?! Sempre que for trazer mais do que poucas dezenas de registros, pagine. E a paginação deve ser feita a nível de servidor, e não no lado do cliente. Um erro comum é os desenvolvedores quererem usar fantásticos paginadores escritos como plugins JQuery que puxam todos os dados do banco de uma vez só e depois apenas exibem de forma paginada, sendo que todos os dados tiveram de ser retornados e foram escritos no HTML. Isso é ruim do ponto de vista de performance e use apenas se for com poucos dados.

Outra dica ao usar estes controles é usar o mínimo possível de botões. Se você colocou um botão que leva o usuário para uma tela de edição com um ID como CommandArgument, porque não fazer simplesmente uma âncora (tag “a”) que leva para a tela de edição passando o ID como querystring? Muito mais leve e 100% funcional, evitando um postback desnecessário.

Evite o uso de DataBinder.Eval, pois ele usa Reflection para escrever os dados na tela. Ao invés disso, prefira fazer casting explícito sobre o Container.DataItem e chamar a propriedade que deseja.

Além disso, muito cuidado com os eventos ItemDataBound, que são executados uma vez para cada elemento que será apresentado na tela. Ele pode se tornar um imenso gargalo, principalmente se realizar consultas no banco de dados. O ItemDataBound é uma boa pedida se o seu controle de repetição possui muitas colunas, neste caso, pode ser mais eficiente montar uma string no ItemDataBound e escrever na tela com Response.Write, pois o eval do objeto será feito apenas uma vez dessa forma.

Redirecionamentos HTTP

Sempre que possível, use Server.Transfer para redirecionamentos dentro de uma mesma aplicação. Deixe o Response.Redirect somente para os casos de redirecionar para uma URL externa. E sob o ponto de vista de SEO, use o RedirectPermanent para avisar quando esse redirecionamento é para sempre.

Global.asax

Em aplicações que possuem tal arquivo, tome muito cuidado com o que você faz no mesmo, pois cada requisição feita à sua aplicação (o carregamento de uma imagem, um postback, um acesso pelo browser, etc) invocará este arquivo. Então se pretende colocar alguma lógica de aplicação neste arquivo, faça os testes corretos para garantir que você não efetuará sua lógica sobre requisições inofensivas, como imagens, JS e CSS, por exemplo. Libere tais requisições verificando a extensão de arquivo da requisição, quando houver.

Páginas Grandes e Complexas

Evite criar páginas ASPX muito grandes, especialmente com MultiViews cheias de Views ou páginas cheias de User Controls. Mesmo que a renderização do HTML seja dinâmica e alguns conteúdos não serão exibidos, o servidor dispenderá tempo processando esta página para gerar o HTML correto. prefira criar páginas separadas e menores para aumento de performance. Também evite uma hierarquia muito grande controles ou páginas, como múltiplas MasterPages ou User Controls dentro de User Controls.

Publicação

Aqui seguem algumas dicas de publicação do seu sistema em produção para que aumente a performance e reduza o consumo de memória:

  • compile como Release. Desta forma, suas DLLs ficarão menores, com até 15% de ganho em DLLs grandes. isso reduzirá o tempo de publicação (FTP) e o tempo de compilação da mesma no servidor, fora outros ganhos menores no próprio uso da aplicação.
  • compile para a plataforma de destino. Por padrão o ASP.NET mantém compatibilidade com servidores x32 e x64 sem nenhum ajuste. Entretanto, está cada vez mais comuns servidores com Windows Server 2008 R2, que por padrão, não existe em evrsão 32-bit. Dessa forma, porque manter uma compatibilidade que gera um overhead na compilação sem necessidade? Ajuste a arquitetura de compilação de seu projeto para x64 nas propriedades do mesmo, mas somente na configuração de Build para Release, para evitar problemas com sua máquina local. isso lhe trará ganhos de performance.

Manutenção

Mesmo que sua aplicação ASP.NET esteja pronta e publicada com sucesso, existem algumas dicas para melhorar a performance dela no servidor. Uma delas é reiniciar o seu application pool no IIS com certa frequencia, podendo inclusive deixar isso configurado no próprio pool. Reiniciar o pool limpa completamente a memória da aplicação, eliminando qualquer recurso indesejado que pode ter ficado pra trás e iniciando um novo processo em perfeitas condições de uso. Eu costumo fazer isso no máximo a cada 2 dias.

Conclusões

É muito provável que você faça essas alterações, mande rodar sua aplicação e…não veja diferença. Isso é normal. Cada uma dessas melhorias lhe dará milisegundos de ganho. A vantagem somente se dará quando atingir um volume de requisições, com vários usuários utilizando sua aplicação ao mesmo tempo, pois vários milisegundos virarão segundos, depois minutos e por aí vai. Um sistema ASP.NET bem construído pode ser tão veloz ou até mais do que a maioria das aplicações feitas com frameworks PHP, por exemplo, basta se estudar para isso.

Nos próximos posts sobre Tunning irei abordar otimizações de performance para sistemas escritos em C# e otimizações para modelagem e uso de bancos MS SQL Server. Ou seja, ao final desta série de posts (que começou com os posts sobre melhorias de performance em websites comuns) você terá em mãos muitas das técnicas que utilizo para que o Busca Acelerada consiga honrar o seu nome.

E você, conhece alguma melhoria de ASP.NET que já tenha utilizado e que não listei aqui?