Réponses:
Une liste compilée des sources possibles d'amélioration est ci-dessous:
Général
Mise en cache
CompiledQuery.Compile()
récursivement en évitant la recompilation de vos expressions de requêteOutputCacheAttribute
pour enregistrer les exécutions inutiles et les actionsActionResultméthodes personnalisées si nécessaireRouteNamepour organiser vos itinéraires, puis utilisez-le pour générer vos liens et essayez de ne pas utiliser la méthode ActionLink basée sur l'arborescence des expressions.PartialViews, évitez de le rendre xxxx fois: si vous finissez par appeler le même partiel 300 fois dans la même vue, il y a probablement quelque chose qui ne va pas. Explication et repèresAcheminement
Utilisez Url.RouteUrl("User", new { username = "joeuser" })pour spécifier les itinéraires. ASP.NET MVC Perfomance par Rudi Benkovic
Résolution de la route du cache à l'aide de cette aide UrlHelperCached ASP.NET MVC Perfomance par Rudi Benkovic
Sécurité
DAL
L'équilibrage de charge
Utilisez des proxys inverses pour répartir la charge client sur votre instance d'application. (Stack Overflow utilise HAProxy ( MSDN ).
Utilisez des contrôleurs asynchrones pour implémenter des actions qui dépendent du traitement des ressources externes.
Côté client
Configuration globale
Si vous utilisez Razor, ajoutez le code suivant dans votre global.asax.cs, par défaut, Asp.Net MVC effectue le rendu avec un moteur aspx et un moteur razor. Cela utilise uniquement RazorViewEngine.
ViewEngines.Engines.Clear();
ViewEngines.Engines.Add(new RazorViewEngine());
Ajoutez gzip (compression HTTP) et cache statique (images, css, ...) dans votre web.config
<system.webServer>
<urlCompression doDynamicCompression="true" doStaticCompression="true" dynamicCompressionBeforeCache="true"/>
</system.webServer>
<pages buffer="true" enableViewState="false">La suggestion de base est de suivre les principes REST et les points suivants relient certains de ces principes au framework MVC ASP.NET:
Code Climber et cette entrée de blog fournissent des moyens détaillés d'augmenter les performances de l'application.
La requête compilée augmentera les performances de votre application, mais elle n'a rien en commun avec ASP.NET MVC. Cela accélérera chaque application db, il ne s'agit donc pas vraiment de MVC.
Cela peut sembler évident, mais exécutez votre site en mode Release, et non en mode Debug, lorsqu'il est en production et également pendant le profilage des performances. Le mode de libération est beaucoup plus rapide. Le mode débogage peut masquer les problèmes de performances dans votre propre code.
Lors de l'accès aux données via LINQ, utilisez IQueryable ...
Pourquoi utiliser AsQueryable () au lieu de List ()?
... et tirez parti d'un bon modèle de référentiel:
Chargement de sous-enregistrements dans le modèle de référentiel
Cela optimisera l'accès aux données pour garantir que seules les données nécessaires sont chargées et uniquement lorsqu'elles sont nécessaires.
Pas une optimisation bouleversante, mais je pensais que je jetterais ce là - bas - Utilisez CDN est pour jQuery, etc. .
Citation de ScottGu lui-même: le Microsoft Ajax CDN vous permet d'améliorer considérablement les performances des formulaires Web ASP.NET et des applications MVC ASP.NET qui utilisent ASP.NET AJAX ou jQuery. Le service est disponible gratuitement, ne nécessite aucune inscription et peut être utilisé à des fins commerciales et non commerciales.
Nous utilisons même le CDN pour nos composants WebPart dans Moss qui utilisent jQuery.
Aussi si vous utilisez NHibernate vous pouvez activer et configurer le cache de deuxième niveau pour les requêtes et l'ajouter à la portée et au délai d'expiration des requêtes. Et il existe un profileur kick ass pour EF , L2S et NHibernate - http://hibernatingrhinos.com/products/UberProf . Cela vous aidera à régler vos requêtes.
J'ajouterai également:
Utiliser des sprites : les sprites sont une bonne chose pour réduire une demande. Vous fusionnez toutes vos images en une seule et utilisez CSS pour accéder à une bonne partie du sprite. Microsoft fournit une bonne bibliothèque pour le faire: Sprite et Image Optimization Preview 4 .
Cachez votre objet serveur : si vous avez des listes de références ou des données qui changeront rarement, vous pouvez les mettre en cache au lieu d'interroger la base de données à chaque fois.
Utilisez ADO.NET au lieu d'Entity Framework : EF4 or EF5sont parfaits pour réduire le temps de développement, mais il sera difficile d'optimiser. Il est plus simple d'optimiser un procédure stockée qu'Entity Framework. Vous devez donc utiliser autant que possible les procédures de stockage. Dapper fournit un moyen simple d'interroger et de mapper SQL avec de très bonnes performances.
Page de cache ou page partielle : MVC fournit un filtre facile pour mettre en cache la page en fonction de certains paramètres, alors utilisez-le.
Réduisez les appels à la base de données : vous pouvez créer une demande de base de données unique qui renvoie plusieurs objets. Vérifiez sur le site Web de Dapper.
Ayez toujours une architecture propre : Ayez une propre à n niveaux, même sur un petit projet. Cela vous aidera à garder votre code propre et il sera plus facile de l'optimiser si nécessaire.
Vous pouvez jeter un œil à ce modèle " Modèle MVC Neos-SDI " qui créera une architecture propre pour vous avec de nombreuses améliorations de performances par défaut (consultez le site Web MvcTemplate ).
En plus de toutes les bonnes informations sur l'optimisation de votre application côté serveur, je dirais que vous devriez jeter un œil à YSlow . C'est une superbe ressource pour améliorer les performances du site côté client.
Cela s'applique à tous les sites, pas seulement à ASP.NET MVC.
Une chose super simple à faire est de penser de manière asynchrone lors de l'accès aux données que vous souhaitez pour la page. Que vous lisiez depuis un service Web, un fichier, une base de données ou autre, utilisez autant que possible le modèle asynchrone. Bien que cela n'aidera pas nécessairement une page à être plus rapide, cela aidera votre serveur à mieux fonctionner dans l'ensemble.
1: Obtenez les horaires. Jusqu'à ce que vous sachiez où se situe le ralentissement, la question est trop large pour y répondre. Un projet sur lequel je travaille a ce problème précis; Il n'y a aucune journalisation pour savoir combien de temps certaines choses prennent; nous ne pouvons que deviner les parties lentes de l'application jusqu'à ce que nous ajoutions des minutages au projet.
2: Si vous avez des opérations séquentielles, n'ayez pas peur de légèrement multithread. SURTOUT si des opérations de blocage sont impliquées. PLINQ est votre ami ici.
3: Pré-générer vos vues MVC lors de la publication ... Cela vous aidera avec certains des `` premiers coups de page ''
4: Certains plaident pour les avantages de la procédure stockée / ADO de la vitesse. D'autres plaident pour la rapidité de développement des FE et une séparation plus claire des niveaux et de leur objectif. J'ai vu des conceptions très lentes lorsque SQL et les solutions de contournement pour utiliser Sprocs / Views pour la récupération et le stockage de données. De plus, votre difficulté à tester augmente. Notre base de code actuelle que nous convertissons d'ADO en EF ne fonctionne pas moins bien (et dans certains cas mieux) que l'ancien modèle roulé à la main.
5: Cela dit, pensez au préchauffage de l'application. Une partie de ce que nous faisons pour aider à éliminer la plupart de nos problèmes de performance EF était d'ajouter une méthode spéciale de préchauffage. Il ne précompile aucune requête ni rien, mais il aide à une grande partie du chargement / génération des métadonnées. Cela peut être encore plus important lorsqu'il s'agit de modèles Code First.
6: Comme d'autres l'ont dit, n'utilisez pas l'état Session ou ViewState si possible. Ce ne sont pas nécessairement des optimisations de performances auxquelles les développeurs pensent, mais une fois que vous commencez à écrire des applications Web plus complexes, vous voulez de la réactivité. L'état de session empêche cela. Imaginez une requête longue. Vous décidez d'ouvrir une nouvelle fenêtre et d'en essayer une moins complexe. Eh bien, vous pouvez aussi avoir attendu avec l'état de session activé, car le serveur attendra jusqu'à ce que la première demande soit effectuée avant de passer à la suivante pour cette session.
7: Minimisez les allers-retours vers la base de données. Enregistrez les éléments que vous utilisez fréquemment mais qui ne changeront pas de manière réaliste dans votre cache .Net. Essayez de regrouper vos insertions / mises à jour dans la mesure du possible.
7.1: Évitez le code d'accès aux données dans vos vues Razor sans une putain de bonne raison. Je ne dirais pas ça si je ne l'avais pas vu. Ils accédaient déjà à leurs données lors de la création du modèle, pourquoi diable ne l'incluaient-ils pas dans le modèle?
Je voulais juste ajouter mes 2 cents. Le moyen le plus efficace d'optimiser la génération de routes URL dans une application MVC est ... de ne pas les générer du tout.
La plupart d'entre nous savent plus ou moins comment les URL sont générées dans nos applications, donc il suffit d'utiliser statique Url.Content("~/Blahblah")au lieu de Url.Action()ouUrl.RouteUrl() si possible, bat toutes les autres méthodes de près de 20 fois et même plus.
PS. J'ai exécuté une référence de quelques milliers d'itérations et publié des résultats sur mon blog si cela m'intéresse.
Dans votre demande d'optimiser le côté client, n'oubliez pas la couche de base de données. Nous avions une application qui passait de 5 secondes à charger jusqu'à 50 secondes pendant la nuit.
Lors de l'inspection, nous avions fait tout un tas de changements de schéma. Une fois que nous avons actualisé les statistiques, elles sont soudainement devenues aussi réactives qu'auparavant.
Voici les choses à faire
Si vous exécutez votre application ASP.NET MVC sur Microsoft Azure (IaaS ou PaaS), procédez comme suit au moins avant le premier déploiement.
J'ai fait toutes les réponses ci-dessus et cela n'a tout simplement pas résolu mon problème.
Enfin, j'ai résolu mon problème de chargement lent du site en définissant PrecompileBeforePublish dans Publish Profile sur true . Si vous souhaitez utiliser msbuild, vous pouvez utiliser cet argument:
/p:PrecompileBeforePublish=trueÇa aide vraiment beaucoup. Maintenant, mon MVC ASP.NET se charge 10 fois plus rapidement.