Desempenho ASP.NET MVC

102

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.

GEOCHET
fonte
20
Depois de trabalhar com WebForms desde que eles foram lançados, eu nunca vou voltar voluntariamente! MVC roubou meu <3 - e este site está rodando incrivelmente no Beta 5!
Jarrod Dixon
2
O que há com todos os rollbacks de revisão nesta questão ..?
Nick
@ Nick: O OP está revertendo qualquer uma das edições e excluindo todos os comentários que as explicam.
GEOCHET
@Rich B: Correto, ele excluiu cerca de 5 dos meus comentários.
George Stocker
2
Precisa de uma atualização agora que estamos chegando perto do lançamento do MVC3.
Andrew Lewis

Respostas:

69

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 ...

Haacked
fonte
13
Agora que o MVC foi lançado, há alguma atualização sobre a liberação dos resultados de desempenho?
chris
6
Só votar porque a pontuação de 5.999 representantes antes estava machucando meus olhos :(
Damien
2
A esta altura, você certamente deve ter alguns números. Quer atualizar sua resposta? Ou você descobriu que a política incômoda o proíbe?
tvanfosson
7
O número é 42. :) Em geral, nossos números provavelmente serão inúteis para aplicativos do mundo real, então, via de regra, não os distribuímos. No entanto, conheço outras equipes da Microsoft que estão criando sites de grande escala que apresentam números favoráveis. Em outras palavras, qualquer problema de desempenho provavelmente será devido a erros do programador do que qualquer problema de herança no framework. Normalmente, as interações com o banco de dados e serviços externos são os culpados. :)
Haacked em
Verdade! Por favor, atualize isso! Talvez não sejam benchmarks, mas uma breve ideia, eles estão no mesmo nível ou o mvc é um pouco melhor no desempenho?
gideon
48

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.

Todd
fonte
Ótima resposta, Todd (que surpresa para um desenvolvedor evangelista ter uma resposta pragmática). A única coisa que você errou é que o formulário da web de implementações brutas é de fato substancialmente mais rápido.
Chris Marisic
42

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.

DevelopingChris
fonte
31
você também poderia ter consertado aquele grande viewstate sem o MVC
Andrei Rînea
1
Apenas para elaborar, o ViewState pode ser desativado no nível da página ou em web.config
bbqchickenrobot
8
sim, mas no mvc é um padrão lógico, não uma decisão de design que força você a deixar todos os controles e fornecedores que afirmam trabalhar apenas em formulários da web, fazendo com que os formulários da web "se comportem mal" removendo sua espinha dorsal. Não discordo que você poderia simplesmente recodificar essa página, mas todo o aplicativo era melhor sem viewstate.
DevelopingChris
então você não acha que é a pior decisão sua portar o aplicativo inteiro para MVC em vez de desligar o viewstate em web.config? e não, viewstate não é o backbone. somente se você pesquisou, o viewstate pode ser mantido no cache, bem como nas sessões.
Simple Fellow
29

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.

Ariel
fonte
14

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.

Hrvoje Hudo
fonte
12

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.

Tvanfosson
fonte
Eu realmente adoraria saber por que alguém votou contra esta resposta.
tvanfosson de
Minha sensação é que pode ser rejeitado porque um aplicativo de formulários da Web ASP.NET bem projetado é tão testável quanto um aplicativo MVC. Minha experiência com o desenvolvimento de ambos é que o MVC força você a um modelo de programação limpo (que é um de seus maiores pontos fortes, IMO). Os formulários da web permitem que você faça coisas mais preguiçosas, mas ainda é muito possível ter a mesma superfície testável em formulários da web. Esse é o meu palpite, de qualquer maneira.
dudemonkey de
As visualizações do Razor literalmente encorajam a incorporação de código dentro da visualização. Isso não é testável e não é um bom presságio para a separação de interesses. Só porque o MVC o faz escrever controladores, não significa que você não possa acumular tudo se não souber o que está fazendo. Um desenvolvedor habilidoso obterá tanto desempenho de WebForms (ou mais) do que MVC, e terá uma "superfície testável" virtualmente idêntica.
Richard Hauer
@RichardHauer isso não era literalmente verdade quando escrevi isso, mas eles melhoraram nisso. Como os WebForms não parecem ter futuro no .NET Core, parece ser um ponto discutível.
tvanfosson 01 de
@tvanfosson Concordo - é discutível agora. Não tem certeza de qual parte você acha que não é verdade, talvez você se oponha ao meu uso de "literalmente"? De qualquer maneira, as versões mais recentes do MVC com TagHelpers ajudam a quebrar o hábito de colocar código em layouts que podem finalmente fazer tudo funcionar para mim. Apreciei que este post é bastante antigo, é claro, mas mesmo na época, um formulário WebForms bem construído é muito rápido, sem nenhum dos "fios mágicos" do MVC e nenhum código embutido na visualização.
Richard Hauer,
7

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.

Kibee
fonte
Seus usuários podem - sem viewstate.
UpTheCreek
6

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.

Seb Nilsson
fonte
3

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?

Chris Marisic
fonte
2

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.

Gerald
fonte
2

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.

John Leidegren
fonte
2
Portanto, esta não é uma resposta direta à pergunta? No entanto, está relacionado e traz alguns pontos positivos. Mas hey, é algo que eu construí para minhas próprias necessidades, e é perfeitamente adequado para mim. Também gosto de compartilhar minhas idéias, mesmo que muito poucas pessoas entendam o porquê.
John Leidegren,
1
Bem, você não tem que mudar seu voto, mas não tem que colocar um voto negativo nele, porque não é 'a' resposta. Se você der uma olhada no texto, há várias coisas que apontam para a ASP.NET MVC ser mais rápida do que WebForms e por que esse é o caso. E tudo se resume a coisas como reflexão e modelo de objeto e sobrecarga ViewState de WebForms.
John Leidegren,
@John - agora que o MVC2 foi lançado com vinculação de modelo aprimorada, validação, auxiliares fortemente tipados, etc., como você o avaliaria em comparação com seu método?
tvanfosson
MVC2 é muito melhor, acredito que praticamente substituiu o que eu estava construindo na época (com MVC1 em beta). Eu enfrentei uma grande provação de problemas em relação ao que eu estava tentando construir em cima do ASP.NET sem desativar o conjunto de ferramentas existente. É suficiente dizer que aprendi muito e eventualmente coloquei isso em produção. Agora percebo que o conjunto de ferramentas / estrutura atual (VS / ASP.NET / C #) não é realmente adequado para essas coisas e, eventualmente, se você quiser seguir esse caminho, você precisará investir em seus próprios compiladores / verificação de modelo coisas para algumas coisas funcionarem a seu favor.
John Leidegren de
Eu não pensava muito na ASP.NET MVC naquela época. Faltavam coisas que eu sabia que queria. Mas, eu tive que gastar muito tempo desenvolvendo, testando e descobrindo essas coisas. Ainda acho que o aspecto estático da estrutura da web que estava construindo é superior ao MVC nesse aspecto, mas o compilador C # é ineficiente para resolver esse problema. Você precisa de alguma linguagem / compilador que permita maior flexibilidade quando se trata de meta-programação. Tive que fazer muito isso em tempo de execução e muitas vezes era impossível armazenar em cache as instâncias compiladas, então tive que recompilar muito as coisas dinamicamente.
John Leidegren
2

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?

insira a descrição da imagem aqui

MVC4

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

insira a descrição da imagem aqui

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.

jihe.wei
fonte
1

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 ).

Jeff Lequeux
fonte
-1

insira a descrição da imagem aqui

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.

Shivprasad Koirala
fonte
Sua metodologia de teste é ruim e muito tendenciosa, e suas conclusões são inválidas. Um aplicativo WebForms desenvolvido corretamente pode ser testado, tem uma separação adequada de interesses e uma sobrecarga de carga mínima. Embora o MVC não tenha um loop de evento de ciclo de vida da página, ele tem o roteamento e a execução da visualização para enfrentar. Seus artigos neste tópico sobre CP são fortemente tendenciosos.
Richard Hauer
Um aplicativo desenvolvido de maneira adequada e cuidadosa, mesmo na pior tecnologia, faria milagres. O ciclo de vida da página ASP.NET definitivamente tem mais carga útil em comparação ao roteamento e execução de visualização, pois lida com a geração de IU HTML. O roteamento é uma parte da estrutura ASP.NET, portanto, mesmo em webforms normais, eles existem. Uma coisa que eu concordo se você não escrever código por trás de seu desempenho será equivalente a MVC. Mas a caixa de ferramentas do Webform é tão tentadora que o código por trás se torna parte integrante dela. Embora o MVC não me permita fazer isso de forma alguma. Eu adoro como, no razor, eles desativaram a visualização do design e o código subjacente.
Shivprasad Koirala