Eu encontrei alguns comentários selvagens de que o ASP.NET MVC é 30x mais rápido do que o ASP.NET WebForms. Que diferença real de desempenho existe, isso foi medido e quais são os benefícios de desempenho.

Isso é para me ajudar a considerar a mudança de ASP.NET WebForms para ASP.NET MVC.

Não realizamos o tipo de testes de escalabilidade e desempenho necessários para chegar a nenhuma conclusão. Acho que ScottGu pode estar discutindo alvos de desempenho em potencial. À medida que avançamos para Beta e RTM, faremos internamente mais testes de desempenho. No entanto, não tenho certeza de qual é a nossa política de publicação de resultados de testes de desempenho.

Em qualquer caso, qualquer um desses testes realmente precisa considerar as aplicações do mundo real ...

Acho que essa será uma pergunta difícil de responder definitivamente, pois muito dependerá de A) como você implementa o aplicativo WebForms e B) como você implementa o aplicativo MVC. Em suas formas "brutas", o MVC é provavelmente mais rápido do que os WebForms, mas anos e anos de ferramentas e experiência produziram várias técnicas para a construção de aplicativos WebForms rápidos. Eu estaria disposto a apostar que um desenvolvedor ASP.NET sênior poderia produzir um aplicativo WebForms que rivalizasse com a velocidade de qualquer aplicativo MVC - ou pelo menos atingir uma diferença insignificante.

A verdadeira diferença - como sugeriu @tvanfosson - está na testabilidade e no SoC limpo. Se melhorar o desempenho é sua principal preocupação, não acho que seja um grande motivo para pular do barco no WebForms e começar a reconstruir no MVC. Não pelo menos até que você tenha experimentado as técnicas disponíveis para otimizar WebForms.

Ele diminuiu uma das minhas páginas de carga útil de 2 MB para 200k, apenas eliminando o viewstate e tornando-o suportável programaticamente para trabalhar com a saída enviada.

O tamanho sozinho, embora o processamento seja o mesmo, criará grandes melhorias nas conexões por segundo e na velocidade das solicitações.

Acho que muitas das pessoas que pensam que os WebForms são inerentemente lentos ou consomem muitos recursos, estão colocando a culpa no lugar errado. 9 em cada 10 vezes que sou chamado para otimizar um aplicativo de formulários da web, há muitos lugares onde os autores do aplicativo interpretam mal o propósito do viewstate. Não estou dizendo que o viewstate é perfeito ou algo assim, mas é muito fácil abusar dele, e é esse abuso que está causando o campo viewstate inchado.

Este artigo foi inestimável para me ajudar a entender muitos desses abusos. https://weblogs.asp.net/infinitiesloop/truly-understanding-viewstate

Para fazer uma comparação válida entre MVC e WebForms, precisamos ter certeza de que ambos os aplicativos estão usando as arquiteturas corretamente.

Meu teste mostra algo entre 2x e 7x mais req / seg no MVC, mas depende de como você constrói seu aplicativo de formulários da web. Com apenas o texto "hello world" nele, sem nenhum controle do lado do servidor, o mvc é cerca de 30-50% mais rápido.

Para mim, a verdadeira melhoria de "desempenho" no MVC é o aumento da superfície testável do aplicativo. Com WebForms havia muitos aplicativos que eram difíceis de testar. Com o MVC, a quantidade de código que se torna testável basicamente dobra. Basicamente, tudo o que não é facilmente testável é o código que gera o layout. Toda a sua lógica de negócios e lógica de acesso a dados - incluindo a lógica que preenche os dados reais usados ​​na exibição - agora pode ser testada. Embora eu espere que ele também tenha mais desempenho - o ciclo de vida da página é muito simplificado e mais acessível para a programação da web - mesmo se fosse o mesmo ou um pouco mais lento, valeria a pena mudar para a partir de uma perspectiva de qualidade.

Acho que o problema aqui é que não importa o quão mais rápido o ASP.Net MVC seja do que os webforms antigos, não fará diferença, porque a maior parte do tempo gasto está no banco de dados. Na maioria das vezes, seus servidores web ficarão com 0-10% de uso da CPU apenas esperando no servidor de banco de dados. A menos que você obtenha um número extremamente grande de acessos em seu site e seu banco de dados seja extremamente rápido, você provavelmente não notará uma grande diferença.

Os únicos números concretos que posso encontrar que são do desenvolvimento inicial da ASP.NET MVC estão neste tópico do fórum:

http://forums.asp.net/p/1231621/2224136.aspx

O próprio Rob Connery confirma de certa forma a declaração de que ScottGu afirmou que a ASP.NET MVC pode atender a 8.000 solicitações por segundo.

Talvez Jeff e sua equipe possam dar algum tipo de dica com o desenvolvimento deste site.

Ao contrário da opinião aceita, o uso de webforms otimizado mata completamente o MVC em termos de desempenho bruto. O Webforms foi hiper-otimizado para a tarefa de servir html por muito mais tempo do que o MVC.

As métricas estão disponíveis em http://www.techempower.com/benchmarks/#section=data-r7&hw=i7&test=db

Cada mvc de comparação está nas classificações inferior-médio / inferior-superior da lista, enquanto o uso de webforms otimizado é colocado nas classificações superior-média / superior-inferior.

Para validação anedótica, mas muito séria, dessas métricas, o www.microsoft.com é servido por formulários da web, não por MVC. Alguém aqui acredita que não teria escolhido o MVC se fosse empiricamente mais rápido?

Realmente não há como responder a isso. O MVC usa o mecanismo de visualização de Web Forms por padrão e pode ser configurado para usar qualquer número de mecanismos de visualização customizados, portanto, se você quiser uma comparação de desempenho, terá que ser mais específico.

Comecei a trabalhar em MVC há cerca de um ano, fiquei inspirado, mas não impressionado.

Eu detesto o estado de exibição e o vejo como a raiz de todos os males em termos de ASP.NET. É por isso que eu simplesmente não o uso e, para ser totalmente honesto, por que você usaria?

Peguei basicamente o conceito do ASP.NET MVC Framework e o construí do meu próprio jeito. Porém, mudei algumas coisas. Criei meu código de empacotamento do controlador ou código de roteamento de URL em torno da recompilação dinâmica.

Agora, eu iria mais longe e diria que os aplicativos ASP.NET MVC serão mais rápidos com base em como você os usa. Se você abandonar completamente os WebForms, será mais rápido porque o ciclo de vida do ASP.NET e o modelo de objeto são enormes.

Quando você está escrevendo, está instanciando um exército ... não espere, uma legião de objetos que participarão da renderização de sua visão. Isso vai ser mais lento do que se você expressasse a quantidade mínima de comportamento na própria página ASPX. (Eu não me importo com a abstração do mecanismo de exibição porque o suporte para páginas ASPX no Visual Studio é decente, mas eu abandonei completamente WebForms como um conceito e basicamente qualquer estrutura ASP.NET devido ao inchaço do código ou não ser capaz de alterar o coisas que conectam meu aplicativo).

Eu encontrei maneiras de confiar na recompilação dinâmica (System.Reflection.Emit) para emitir códigos e objetos de propósito especial sempre que necessário. A execução desse código é mais rápida do que a reflexão, mas inicialmente construída por meio do serviço de reflexão. Isso deu ao meu framework com sabor MVC um ótimo desempenho, mas também com tipos muito estáticos. Eu não uso strings e coleções de pares de nome / valor. Em vez disso, meus serviços de compilador personalizado reescrevem um post de formulário para uma ação do controlador que está passando um tipo de referência. Nos bastidores, há muitas coisas acontecendo, mas esse código é rápido, muito mais rápido do que WebForms ou MVC Framework.

Além disso, eu não escrevo URLs, eu escrevo expressões lambda que são traduzidas em URLs que mais tarde informam qual ação do controlador invocar. Isso não é particularmente rápido, mas é melhor do que ter URLs quebrados. É como se você tivesse recursos com tipos estáticos, bem como objetos com tipos estáticos. Um aplicativo da Web com tipagem estática? Isso e o que eu quero!

Eu encorajaria mais pessoas a experimentar isso.

Os projetos criados com visual studio. Um é o modelo mvc4, outro é o WebForm (tradicional). E ao fazer o teste de carga com WCAT, este é o resultado,

MVC4 é bem lento que WebForms, alguma ideia?

MVC4

• poderia obter cerca de 11 rps
• rps é bastante baixo para o servidor 2-cpu ou 4-cpu

WebForms (aspx)

• poderia ficar acima de 2500 rps

• o assassino de desempenho descobriu que é um bug do MVC Bata ou RC. E o desempenho seria melhorado uma vez que eu removesse as coisas dos Bundles. Agora, a versão mais recente corrigiu isso.

O desempenho depende do que você está fazendo ... Normalmente MVC é mais rápido que asp.net principalmente porque Viewstate está ausente e porque MVC funciona mais com Callback do que Postback por padrão.

Se você otimizar sua página de formulário da web, você pode ter o mesmo desempenho do MVC, mas será muito trabalhoso.

Além disso, há muitos nugets para MVC (e também para Webform) para ajudá-lo a melhorar o desempenho do site, como combinar e minificar seu css e javascripts, agrupar suas imagens e usá-las como sprite, e assim por diante.

O desempenho do site depende muito de sua arquitetura. Um código limpo com boa separação de interesses trará a você um código mais limpo e uma ideia melhor de como melhorar o desempenho.

Você pode dar uma olhada neste modelo " Neos-SDI MVC Template " que criará para você uma arquitetura limpa com muitas melhorias de desempenho por padrão (verifique o site MvcTemplate ).

Fiz um pequeno experimento de teste de carga VSTS com algum código básico e descobri que o tempo de resposta do ASP.NET MVC é duas vezes mais rápido em comparação com os formulários da Web do ASP.NET. Acima está o gráfico anexo com o gráfico.

Você pode ler este experimento de teste de carga em detalhes neste artigo CP https://www.codeproject.com/Articles/864950/ASP-NET-MVC-vs-ASP-NET-WebForm-performance-compari

O teste foi realizado com as especificações abaixo usando o software de teste de carga VSTS e telerik: -

Carga de 25 usuários.

A duração da execução do teste foi de 10 minutos.

Configuração da máquina DELL 8 GB de RAM, Core i3

O projeto foi hospedado no IIS 8.

O projeto foi criado usando MVC 5.

A conexão de rede LAN foi assumida. Portanto, este teste não leva em consideração o atraso da rede por enquanto.

O navegador no teste selecionado Chrome e Internet explorer.

Leituras múltiplas foram feitas durante o teste para a média de eventos desconhecidos. Foram feitas 7 leituras e todas as leituras foram publicadas neste artigo como leituras 1, 2 e assim por diante.