Respostas:
Uma lista compilada de possíveis fontes de melhoria está abaixo:
Geral
Armazenamento em cache
CompiledQuery.Compile()
recursivamente evitando a recompilação de suas expressões de consultaOutputCacheAttribute
para salvar execuções desnecessárias e de açãoActionResultmétodos personalizados , se necessárioRouteNamepara organizar suas rotas e, em seguida, use-o para gerar seus links e tente não usar o método ActionLink baseado em árvore de expressão.PartialViews, evite renderizá-lo xxxx vezes: se você acabar chamando as mesmas parciais 300 vezes na mesma exibição, provavelmente há algo errado com isso. Explicação e BenchmarksEncaminhamento
Use Url.RouteUrl("User", new { username = "joeuser" })para especificar rotas. Desempenho do MVC do ASP.NET por Rudi Benkovic
Resolução de rota de cache usando este auxiliar UrlHelperCached ASP.NET MVC Perfomance por Rudi Benkovic
Segurança
DAL
Balanceamento de carga
Utilize proxies reversos para distribuir a carga do cliente em toda a instância do aplicativo. (Estouro de pilha usa HAProxy ( MSDN ).
Use Controladores assíncronos para implementar ações que dependem do processamento de recursos externos.
Lado do cliente
Configuração global
Se você usa o Razor, adicione o código a seguir no seu global.asax.cs, por padrão, o Asp.Net MVC é renderizado com um mecanismo aspx e um mecanismo razor. Isso usa apenas o RazorViewEngine.
ViewEngines.Engines.Clear();
ViewEngines.Engines.Add(new RazorViewEngine());
Adicione gzip (compactação HTTP) e cache estático (imagens, css, ...) no seu web.config
<system.webServer>
<urlCompression doDynamicCompression="true" doStaticCompression="true" dynamicCompressionBeforeCache="true"/>
</system.webServer>
<pages buffer="true" enableViewState="false">A sugestão básica é seguir os princípios REST e os seguintes pontos vinculam alguns desses princípios à estrutura do ASP.NET MVC:
O Code Climber e esta entrada de blog fornecem maneiras detalhadas de aumentar o desempenho do aplicativo.
A consulta compilada aumentará o desempenho do seu aplicativo, mas não tem nada em comum com o ASP.NET MVC. Ele irá acelerar todos os aplicativos de banco de dados, por isso não se trata realmente de MVC.
Isso pode parecer óbvio, mas execute o site no modo Release, não no modo Debug, quando estiver em produção e também durante a criação de perfil de desempenho. O modo de lançamento é muito mais rápido. O modo de depuração pode ocultar problemas de desempenho em seu próprio código.
Ao acessar dados via LINQ, confie no IQueryable ...
Por que usar AsQueryable () em vez de List ()?
... e aproveite um bom padrão de repositório:
Carregando sub-registros no padrão de repositório
Isso otimizará o acesso aos dados para garantir que apenas os dados necessários sejam carregados e quando somente eles forem necessários.
Não é uma otimização de abalar a terra, mas eu pensei que eu ia jogar isso lá fora - Use CDN para jQuery, etc .
Citação do próprio ScottGu: O CDN do Microsoft Ajax permite melhorar significativamente o desempenho dos aplicativos ASP.NET Web Forms e ASP.NET MVC que usam ASP.NET AJAX ou jQuery. O serviço está disponível gratuitamente, não requer nenhum registro e pode ser usado para fins comerciais e não comerciais.
Até usamos o CDN para nossas peças da Web no Moss que usam jQuery.
Além disso, se você usar o NHibernate, poderá ativar e configurar o cache de segundo nível para consultas e adicionar ao escopo e ao tempo limite das consultas. E existe um excelente perfil para EF , L2S e NHibernate - http://hibernatingrhinos.com/products/UberProf . Isso ajudará a ajustar suas consultas.
Vou acrescentar também:
Usar Sprites : Sprites são ótimos para reduzir uma solicitação. Você mescla todas as suas imagens em uma única e usa CSS para obter boa parte do sprite. A Microsoft fornece uma boa biblioteca para isso: Sprite e Image Optimization Preview 4 .
Armazenar em cache o objeto do servidor : se você tiver algumas listas de referências ou dados que serão alterados raramente, poderá armazená-los na memória em vez de consultar o banco de dados todas as vezes.
Use o ADO.NET em vez do Entity Framework : EF4 or EF5são ótimos para reduzir o tempo de desenvolvimento, mas será difícil otimizar. É mais simples otimizar um procedimento armazenado do que o Entity Framework. Portanto, você deve usar os procedimentos de armazenamento o máximo possível. O Dapper fornece uma maneira simples de consultar e mapear SQL com desempenho muito bom.
Página de cache ou página parcial : o MVC fornece um filtro fácil para armazenar em cache a página de acordo com alguns parâmetros, portanto, use-o.
Reduzir chamadas de banco de dados : você pode criar uma solicitação de banco de dados exclusiva que retorne vários objetos. Verifique no site Dapper.
Sempre tenha uma arquitetura limpa : tenha uma arquitetura limpa de n camadas, mesmo em um projeto pequeno. Isso ajudará você a manter seu código limpo e será mais fácil otimizá-lo, se necessário.
Você pode dar uma olhada neste modelo "Modelo Neos-SDI MVC ", que criará uma arquitetura limpa para você com muitas melhorias de desempenho por padrão (consulte o site do MvcTemplate ).
Além de todas as ótimas informações sobre como otimizar seu aplicativo no lado do servidor, eu diria que você deve dar uma olhada no YSlow . É um excelente recurso para melhorar o desempenho do site no lado do cliente.
Isso se aplica a todos os sites, não apenas ao ASP.NET MVC.
Uma coisa super fácil de fazer é pensar de forma assíncrona ao acessar os dados que você deseja para a página. Quer esteja lendo um serviço da Web, arquivo, banco de dados ou outra coisa, use o modelo assíncrono o máximo possível. Embora não necessariamente ajude qualquer página a ser mais rápida, ajudará seu servidor a ter um desempenho melhor no geral.
1: Obter horários. Até você saber onde está a desaceleração, a pergunta é ampla demais para responder. Um projeto no qual estou trabalhando tem esse problema preciso; Não há registro para saber quanto tempo certas coisas levam; só podemos adivinhar as partes lentas do aplicativo até adicionar horários ao projeto.
2: Se você tiver operações seqüenciais, não tenha medo de multithread levemente. ESPECIALMENTE se houver operações de bloqueio. PLINQ é seu amigo aqui.
3: Pregere suas exibições do MVC ao publicar ... Isso ajudará em alguns dos 'hits da primeira página'
4: Alguns defendem as vantagens da velocidade do procedimento armazenado / ADO. Outros defendem a velocidade de desenvolvimento da EF e uma separação mais clara dos níveis e seus objetivos. Vi projetos muito lentos quando o SQL e as soluções alternativas para usar Sprocs / Views para recuperação e armazenamento de dados. Além disso, sua dificuldade para testar aumenta. Nossa base de código atual que estamos convertendo de ADO para EF não está apresentando desempenho pior (e em alguns casos melhor) que o antigo modelo Hand-Rolled.
5: Dito isto, pense no aplicativo Warmup. Parte do que fazemos para ajudar a eliminar a maioria dos problemas de desempenho da EF foi adicionar um método especial de aquecimento. Ele não pré-compila nenhuma consulta ou qualquer coisa, mas ajuda com grande parte do carregamento / geração de metadados. Isso pode ser ainda mais importante ao lidar com os modelos Code First.
6: Como já foi dito, não use o estado da sessão ou o ViewState, se possível. Elas não são necessariamente otimizações de desempenho nas quais os desenvolvedores pensam, mas quando você começa a escrever aplicativos da Web mais complexos, deseja capacidade de resposta. O estado da sessão impede isso. Imagine uma consulta de longa duração. Você decide abrir uma nova janela e tentar uma menos complexa. Bem, você também pode ter esperado com o estado da sessão ativado, porque o servidor aguardará até que a primeira solicitação seja concluída antes de passar para a próxima para essa sessão.
7: Minimize as viagens de ida e volta ao banco de dados. Salve as coisas que você usa com freqüência, mas não muda de maneira realista para o seu cache .Net. Tente agrupar suas inserções / atualizações sempre que possível.
7.1: Evite o código de acesso a dados em suas visualizações do Razor sem uma boa razão. Eu não diria isso se não tivesse visto. Eles já estavam acessando seus dados ao montar o modelo, por que diabos eles não estavam incluídos no modelo?
Só queria adicionar meus 2 centavos. A maneira MAIS eficaz de otimizar a geração de rotas de URL em um aplicativo MVC é ... não gerá-las.
A maioria de nós, mais ou menos, sabe como os URLs são gerados em nossos aplicativos de qualquer maneira; portanto, simplesmente usando estática em Url.Content("~/Blahblah")vez de Url.Action()ou sempre Url.RouteUrl()que possível, supera todos os outros métodos quase 20 vezes e até mais.
PS. Fiz uma referência de algumas milhares de iterações e publiquei resultados no meu blog, se estiver interessado.
Em seu clamor para otimizar o lado do cliente, não se esqueça da camada do banco de dados. Tivemos um aplicativo que passou de 5 segundos para carregar até 50 segundos durante a noite.
Na inspeção, fizemos várias alterações no esquema. Depois que atualizamos as estatísticas, de repente ela se tornou tão responsiva quanto antes.
A seguir estão as coisas a fazer
Se você estiver executando o aplicativo ASP.NET MVC no Microsoft Azure (IaaS ou PaaS), faça o seguinte pelo menos antes da primeira implantação.
Eu fiz todas as respostas acima e simplesmente não resolveu o meu problema.
Por fim, resolvi meu problema de carregamento lento do site com a configuração PrecompileBeforePublish no perfil de publicação como true . Se você deseja usar o msbuild, pode usar este argumento:
/p:PrecompileBeforePublish=trueIsso realmente ajuda muito. Agora meu MVC ASP.NET carrega 10 vezes mais rápido.