Pourquoi un site Web ASP.Net peut-il se charger lentement? [fermé]

Pour l'anecdote, j'ai visité de nombreux sites Web .aspx qui nécessitent un temps de chargement important pour chaque page.

Mon expérience est-elle unique?

Sinon, pourquoi un site Web ASP.Net pourrait-il se charger lentement?

Edit: C'est maintenant environ 7 ans plus tard (29/12/2017). La bonne nouvelle est que je ne vois plus ce problème, peut-être parce que Google a commencé à pénaliser les sites qui se chargent trop lentement. J'utilise maintenant ASP.NET MVC avec de bons résultats, fonctionnant actuellement sur des serveurs virtuels privés Vultr (Azure était beaucoup trop lent lorsque nous l'avons essayé.) Certains des pires contrevenants que je vois maintenant sont les systèmes CMS comme Wordpress et Drupal, fonctionnant probablement sur matériel trop lent ou trop faible pour le trafic généré par le site. -HK1

Cinq possibilités auxquelles je peux penser (à part quelques techniques avancées de mise en cache et autres):

• Dimensionnement incorrect du serveur Web pour ASP.NET (c.-à-d. Pensé qu'un serveur dimensionné pour ASP classique conviendrait)

• Oublier de supprimer <compilation debug="true"/> du web.config et obtenir un code moins qu'optimal .

• JIT pour la première visite

• Code incorporé dans la page (par opposition au code compilé) qui nécessite une compilation avant et en plus du JIT.

• ViewState (pour ASP.NET WebForms) devient trop grand .

Comme apparemment, cela pourrait être une réponse digne.

Cela pourrait être dû à de nombreux facteurs. Le site que vous utilisez en ce moment est construit sur .NET, et il est généralement très rapide (moins les temps d'arrêt / périodes de maintenance).

Les développeurs de ces sites vers lesquels vous vous rendez pourraient vous pousser des tonnes de données, ou des connexions lentes, des serveurs surchargés, etc. etc. etc. Cela pourrait également être une perception en jeu. De plus, peut-être un javascript fou en jeu et vous utilisez IE? Ou flash?

Si vous ne savez pas vraiment ce que vous faites, ASP.NET WebForms vous permet de créer une application Web en déposant des contrôles sur un formulaire, allant même jusqu'à masquer la nature sans état de http. Cela fonctionne, mais ce type de développement ne produira jamais de code efficace, surtout si votre couche d'accès aux données implique des requêtes générées sélectionnant tout dans une base de données SQL Express sans index.

Il existe de nombreux sites Web asp.net rapides, développés par des personnes qui comprennent le fonctionnement réel des applications Web. Cela inclut ce site - il utilise ASP.NET MVC qui fournit beaucoup plus de contrôle sur la gestion des demandes individuelles et n'affiche pas l'extension .aspx.

Juste spéculation ici car j'ai remarqué la même chose. Je soupçonne que les sites .asp ont tendance (notez le mot tendance ) à être auto-hébergés sur les serveurs d'une entreprise, par opposition à hébergés dans ou dans des centres de données. Ils sont donc souvent exécutés sur du matériel et des connexions qui ne sont pas vraiment conçus pour le trafic Web à haut débit. Je soupçonne que les sites basés sur la fusion froide en souffrent également.

Lorsqu'un site Web se charge (événement application.start), il faut du temps pour tout charger en mémoire. Selon les paramètres IIS, après environ 20-30 minutes d'inactivité, il se déchargera. Je ne suis pas tombé sur un moyen décent de faire fonctionner l'application en permanence sans qu'un service ne le fasse GETtoutes les 10+ minutes.

Un backend / datalayer mal conçu peut ralentir tout ce qui se passe (quelle que soit la vitesse à laquelle l'ordinateur l'exécute). Le profilage vous aidera à identifier où se trouvent les problèmes.

Vous l'imaginez très certainement. :)

De nombreux facteurs entrent en jeu avec tout logiciel. L'architecture, la redondance du flux de code, la qualité du code, etc. Trop pour même commencer à lister.

Voulez-vous la preuve que ASP est bon pour une utilisation au niveau de l'entreprise? Ce site Web (et tous les sites Web SE) sont créés à l'aide d'ASP.Net - en particulier MVC.

À quand remonte la dernière fois que ce site était lent? Je suis ici depuis plus d'un an et jamais je n'ai remarqué de choses bouger malgré sa base d'utilisateurs massive.

Le viewstate peut vraiment ralentir les publications. Si vous avez plusieurs grandes listes déroulantes sur une page, vous ne devez pas utiliser l'état d'affichage sur celles-ci.

Le viewstate vous permet de faire semblant de travailler sur une application Winforms avec état. Cela peut parfois vous causer des ennuis.

Tout ce qui précède est probablement vrai. Le plus grand facteur unique affectant les performances du site ASP.NET sur lequel j'ai travaillé était que tout ce qui s'y rapportait était ancien. La version du framework .NET, les serveurs, l'infrastructure de base de données et le code lui-même vieillissaient tous mal.

Je soupçonne que de nombreux sites ASP.NET ont tendance à être des sites d'entreprise. Ceux-ci ne reçoivent pas beaucoup d'amour, car ils ont tendance à simplement fonctionner . Les gens ne les réécrivent que lorsqu'ils le doivent, ce qui est souvent très long.

Je sais que le site avec lequel j'ai travaillé qui utilise ASP.NET a obtenu une accélération énorme simplement en passant à la dernière version du cadre, qui avait des paramètres JITing et de mise en cache sains beaucoup plus efficaces.

L'autre chose que j'ai vue, c'est que beaucoup de sites ASP.NET ne savent pas comment évoluer correctement. Ils ne disposent pas d'un équilibrage de charge approprié, car la conception de leur site pour fonctionner correctement avec les jardins Web n'est pas courante ou bien documentée dans la communauté. Si vous ne concevez pas votre site pour les jardins Web depuis le début, vous ne pouvez pas utiliser le mécanisme de mise à l'échelle intégré d'IIS. L'équilibrage de la charge logicielle avec Windows NLB n'est pas très courant et est complexe à gérer. (Cela rappelle que ASP.NET a tendance à être un logiciel d'entreprise et à être géré par la société qui gère le site plutôt que par les professionnels de l'informatique qui savent comment configurer correctement ces éléments.)

L'équilibrage de la charge matérielle avec les F5 est très très coûteux, mais semble être le mécanisme le plus courant et le plus simple pour la mise à l'échelle des sites ASP.NET au sein des réseaux d'entreprise. Je pense que parmi la foule open source, on s'attend à ce que vous intégriez l'équilibrage de charge depuis le début en utilisant des outils open source librement disponibles qui évoluent automatiquement en fonction de l'utilisation. Ce n'est pas courant dans le monde ASP.NET d'après ce que j'ai vu.