Pourquoi ASP.NET recompile-t-il (re-JIT) tout quand une seule chose change?

Question

J'ai une application ASP.NET 2.0 (installée sur IIS 6.0 à partir d'un fichier MSI) qui a été compilée en tant que & "site Web"! et précompilée / packagée à l'aide d'un projet de déploiement Web, en Visual. Studio 2005. (J'ai demandé aux développeurs d'envisager de passer à une application Web pour la prochaine version, mais cela ne changera pas pour cette version).

Chaque fois que l'application est recyclée (par exemple, une modification est apportée à web.config), ASP.NET lance le premier coup sur l'application. Dans ce cadre, il prend tous les assemblys requis pour la page de connexion et les compile en code natif dans le répertoire "assembly \ dl3" de fichiers ASP.NET temporaires, ce qui prend entre 20 et 60 secondes. Cela ne se produit que lors d'un recyclage, ce qui arrive rarement & # 8212; mais lorsque cela se produit, le chargement de la page prend beaucoup plus de temps et je pense qu’il sera peut-être possible de l’optimiser.

Il semble y avoir 122 DLL à prendre en compte, certaines d'entre elles étant le code précompilé, d'autres sont des composants tiers du site Web (par exemple, NHibernate.dll, des composants de génération de rapports, etc.)

Pourquoi recompile-t-il / re-JIT tout ? Pourquoi ne détecte-t-il pas que la plupart des assemblages n'ont pas changé et n'essaye-t-il pas de les changer? Puis-je prouver que ce n'est pas la compilation par lots qui pose problème? (J'ai <compilation debug="false" & Gt; défini dans le fichier Web.config.)

D'autres questions suggèrent que NGEN pourrait être utile, mais j'ai lu que ce n'était pas possible. l'utiliser sur ASP.NET 1.x; nous utilisons la version 2.0 et je ne trouve pas de réponse claire dans les deux cas.

Answer 1

De par mon expérience personnelle, NHibernate / ActiveRecord provoque souvent un recyclage lent si vous avez beaucoup d’entités. Voir http://nhibernate.info/blog /2009/03/13/an-improvement-on-sessionfactory-initialization.html pour une explication + une solution possible.

Answer 2

Utilisez-vous IIS? Je suis à peu près certain que si vous redémarrez votre site dans IIS, il enregistrera toutes les modifications apportées à la configuration sans copier les dll.

Answer 3

Vous pourrez peut-être améliorer votre temps de recyclage en installant des DLL communes qui changent peu fréquemment - telles que NHibernate ou des outils de génération de rapports - dans le GAC. Cela devrait les empêcher d’être refaits.

Comment: installer un assembly dans le Global Assembly Cache

Answer 4

Il est étrange que la copie de la dll ne prenne que 20 secondes. Je suggèrerais de faire un autre contrôle et de m'assurer où se trouve le goulot d'étranglement.

Answer 5

Comment pouvez-vous être certain que tout est en bon état sans recycler / réinitialiser (ou quoi que ce soit d'autre) le domaine d'application? Imaginez que vous avez quelque chose dans l'application start (global.asax) qui définit la valeur d'un champ statique en fonction d'une valeur de configuration. Si vous ne réinitialisez pas l'ensemble de l'AppDomain, vous ne pouvez en être sûr.

Autre raison: il n’existe aucun moyen de décharger une dll .NET une fois chargée, vous devez donc recréer le domaine de l’application lorsque quelque chose est mis à jour.