Por que um site ASP.Net pode carregar lentamente? [fechadas]

Curiosamente, visitei muitos sites .aspx que exigem uma quantidade significativa de tempo de carregamento para cada página.

Minha experiência é única?

Caso contrário, por que um site ASP.Net pode carregar lentamente?

Edit: agora é cerca de 7 anos depois (29/12/2017). A boa notícia é que não vejo mais esse problema, talvez porque o Google começou a penalizar sites que carregam muito lentamente. Agora, uso o ASP.NET MVC com bons resultados, atualmente em execução nos servidores virtuais privados Vultr (o Azure estava muito lento quando tentamos). Alguns dos piores criminosos que vejo agora são os sistemas CMS como Wordpress e Drupal, provavelmente em execução no hardware muito lento ou subespecificado para a quantidade de tráfego que o site recebe. -HK1

Cinco possibilidades em que posso pensar (além de algumas técnicas avançadas de cache e outras):

• Dimensionamento inadequado do servidor Web para ASP.NET (ou seja, considerou que um servidor dimensionado para ASP clássico seria bom)

• Esquecendo de remover <compilation debug="true"/> do web.config e obtendo um código abaixo do ideal .

• JIT para a primeira visita

• Código incorporado na página (em oposição ao code-behind compilado) que requer compilação antes e além do JIT.

• O ViewState (para ASP.NET WebForms) fica muito grande .

Aparentemente, isso pode ser uma resposta digna.

Pode haver muitos fatores em jogo. O site que você está usando neste exato momento é baseado no .NET e normalmente é muito rápido (menos períodos de inatividade / manutenção).

Os desenvolvedores desses sites podem estar enviando toneladas de dados para você, conexões lentas ou servidores sobrecarregados, etc. etc. etc. Também pode ser uma percepção em jogo. Além disso, talvez javascript insano em jogo e você esteja executando o IE? Ou flash?

Se você realmente não sabe o que está fazendo, o ASP.NET WebForms permite criar um aplicativo Web soltando controles em um formulário, chegando a esconder a natureza apátrida do http. Funciona, mas esse tipo de desenvolvimento nunca produzirá código eficiente, especialmente se a camada de acesso a dados envolver consultas geradas, selecionando tudo a partir de um banco de dados sql express sem índices.

Existem muitos sites rápidos do asp.net por aí, desenvolvidos por pessoas que entendem como os aplicativos da Web realmente funcionam. Isso inclui este site - ele usa o ASP.NET MVC, que fornece muito mais controle sobre o processamento de solicitações individuais e não mostra a extensão .aspx.

Apenas especulação aqui, como eu notei a mesma coisa. Suspeito que os sites .asp tendam (observe a palavra tendem ) a serem auto-hospedados nos servidores de uma empresa, em vez de hospedados em ou em data centers. Por isso, eles geralmente são executados em hardware e conexões que não são realmente projetadas para tráfego na web de alta velocidade. Suspeito que sites movidos a fusão a frio também sofram disso.

Quando um site é carregado (evento application.start), leva tempo para carregar tudo na memória. Dependendo das configurações do IIS, após cerca de 20 a 30 minutos de inatividade, ele será descarregado. Não me deparei com uma maneira decente de manter o aplicativo em execução constantemente sem que algum serviço faça a GETcada 10 minutos ou mais.

Um backend / datalayer mal projetado pode fazer com que tudo corra devagar (não importa a rapidez com que o computador o executa). A criação de perfil ajudará você a identificar onde estão os problemas.

Você certamente está imaginando isso. :)

Muitos fatores entram em jogo com qualquer software. A arquitetura, a redundância do fluxo do código, a qualidade do código, etc. Muitos para começar a listar.

Deseja provar que o ASP é bom para uso em nível empresarial? Os sites deste site (e todos os SE) são criados usando ASP.Net - especificamente MVC.

Quando foi a última vez que este site ficou lento? Estou aqui há mais de um ano e nunca notei coisas acontecendo apesar de sua enorme base de usuários.

O viewstate pode realmente desacelerar as postagens. Se você possui várias listas suspensas em uma página, não deve usar o estado de exibição nelas.

O viewstate permite que você finja que está trabalhando em um aplicativo stateform winforms. Isso pode causar problemas às vezes.

Todos os itens acima provavelmente são verdadeiros. O maior fator que afetou o desempenho no site ASP.NET em que trabalhei foi que tudo relacionado a ele era antigo. A versão do framework .NET, os servidores, a infraestrutura do banco de dados e o próprio código estavam com um envelhecimento muito ruim.

Eu suspeito que muitos sites ASP.NET tendem a ser sites corporativos. Eles não recebem muito amor, pois tendem a funcionar . As pessoas não as reescrevem até que tenham que fazê-lo, o que costuma demorar muito tempo no caminho.

Eu sei que o site com o qual trabalhei que utilizava o ASP.NET obteve uma enorme velocidade apenas ao migrar para a versão mais recente da estrutura, que possuía padrões de JITing e cache de cache muito mais eficientes.

A outra coisa que eu já vi é que muitos sites do ASP.NET não sabem como dimensionar corretamente. Eles não têm o balanceamento de carga adequado configurado, porque projetar seu site para funcionar corretamente com jardins da web não é comum ou está bem documentado na comunidade. Se você não projetou seu site para jardins da Web desde o início, não poderá usar o mecanismo interno de expansão que o IIS possui. O balanceamento de carga de software com o Windows NLB não é muito comum e é complexo de gerenciar. (Isso remete ao fato de que o ASP.NET tende a ser software corporativo e a ser gerenciado pela empresa que administra o site, e não por profissionais de TI que sabem como configurar essas coisas corretamente.)

O balanceamento de carga de hardware com F5s é muito muito caro, mas parece ser o mecanismo mais comum e simples para dimensionar sites ASP.NET em redes corporativas. Eu acho que, entre a multidão de código aberto, a expectativa é que você construa um balanceamento de carga desde o início, usando ferramentas de código aberto disponíveis gratuitamente, que se expandem automaticamente com base no uso. Isso não é comum no mundo do ASP.NET pelo que vi.