Qu’est-ce que le recyclage d’Appdomain?

J’essaie de comprendre ce qu’est exactement le recyclage Appdomain? Lorsqu’une page aspx est demandée pour la première fois à partir d’une application DotNet, je comprends qu’un domaine d’application est créé pour cette application et que les assemblys requirejs sont chargés dans cet domaine et que la demande sera envoyée. Maintenant, si le fichier web.config ou le contenu du dossier bin, etc. sont modifiés, le domaine d’application sera “recyclé”. Ma question est la suivante: à la fin du processus de recyclage, l’appdomain sera-t-il chargé d’assemblages et prêt à répondre à la demande suivante? ou une page doit être demandée pour déclencher le chargement des assemblages?

Eh bien, je pense que le fil s’est bien passé jusqu’à une conclusion finale, mais au final, c’était le contraire.

Je vais essayer de répondre à la question en fonction de ma compréhension et en tirant parti de ce que je viens de lire dans d’autres sites Web.

Tout d’abord, j’essaie moi-même d’éviter le terme recyclage autre que pour les pools d’applications, car cela peut rendre quelqu’un confus. Maintenant, pour traiter, les pools et AppDomain, je vois l’image comme suit:

Un pool d’applications est, en bref, une région de la mémoire qui est maintenue et exécutée par un processus appelé W3WP.exe, également appelé Worker Process. Recycler un pool d’applications signifie mettre fin à ce processus, l’éliminer de la mémoire, puis générer un tout nouveau processus de travail, avec un ID de processus nouvellement atsortingbué.

En ce qui concerne les domaines d’application, je le vois comme des sous-ensembles de régions de mémoire, dans la région susmentionnée, qui joue le rôle de conteneur. En d’autres termes, le processus en mémoire, W3WP.exe dans ce cas, est une région de mémoire macro pour les applications qui stockent des régions de sous-ensemble, appelées domaines d’application. Cela dit, un processus en mémoire peut stocker différents domaines d’application, un pour chaque application à exécuter dans un pool d’applications donné.

En ce qui concerne le recyclage, comme je l’ai dit au départ, c’est quelque chose que je réserve moi-même uniquement pour les pools d’applications. Pour AppDomains, je préfère utiliser le terme «redémarrer» afin d’éviter les idées fausses. Sur cette base, le redémarrage d’un AppDomain signifie le démarrage d’une application donnée avec les nouveaux parameters ajoutés, tels que l’actualisation de la configuration existante. Cela se produit dans les limites de cette sous-région de la mémoire, appelée AppDomain, qui se situe finalement dans le processus associé à un pool d’applications respectif. Ces nouveaux parameters peuvent provenir de fichiers tels que

web.config, machine.config, global.asax, répertoire bin, code_app,

et il peut y en avoir d’autres.

AppDomain sont isolés les uns des autres, ce qui est tout à fait logique. Dans le cas contraire, si les modifications apscopes à l’application Web, disons, de l’application 1, requièrent le recyclage du pool, toutes les autres applications affectées à ce pool seraient redémarrées, ce qui n’était définitivement pas souhaité par Microsoft et par quiconque.

Résumer mon point,

  • Process (W3WP.exe)
    • AppDomain 1
    • AppDomain 2
    • AppDomain 3
    • AppNomain n

n = le nombre d’applications atsortingbuées au pool d’applications géré par le fichier W3WP.exe donné

  • Les processus sont des régions de mémoire isolées les unes des autres
  • AppDomains sont des régions de sous-mémoire isolées les unes des autres, dans le même processus
  • Les modifications apscopes aux parameters IIS globaux peuvent nécessiter le recyclage du pool d’applications (suppression et démarrage d’un nouveau processus de travail, W3WP.exe)
  • Les parameters à l’échelle de l’application modifient les problèmes liés à AppDomains et peuvent être redémarrés après des modifications dans certains fichiers spécifiques, tels que ceux décrits ci-dessus.

Pour plus d’informations, je recommande:

http://blogs.msdn.com/b/david.wang/archive/2006/03/12/thoughts-on-iis-configuration-changes-and-when-it-takes-effect.aspx

Qu’est-ce qui provoque le recyclage d’un pool d’applications dans IIS?

http://blogs.msdn.com/b/tess/archive/2006/08/02/asp-net-case-study-lost-session-variables-and-appdomain-recycles.aspx

Cordialement du Brésil!

Jetez un oeil à cela – cela pourrait expliquer:

http://weblogs.asp.net/owscott/archive/2006/02/21/ASP.NET-v2.0- 2D00 -AppDomain-recycles_2C00_-more-common-than-before.aspx # 440333

En général. Ce qui est appelé “premier succès” sur un site Web ASP.NET prend généralement plus de temps, en raison de la compilation et de la création d’un AppDomain.

Chaque fois que vous déployez un site, assurez-vous d’utiliser la fonction “Publier un site Web” dans Visual Studio pour pré-comstackr votre site Web. Ensuite, la pénalité “premier coup” est réduite. Et rappelez-vous de définir la configuration sur Release, et non sur Debug!

Recycle arrête le processus hébergeant le domaine d’application. Vous remarquerez que le PID change lorsque vous le recyclez.

Le déchargement de AppDomin décharge simplement tous les assemblys dans AppDomain, qui peuvent ensuite être réutilisés.

La chose importante à retenir est que, une fois le CLR chargé dans un processus, il ne peut plus être supprimé. Donc, si vous deviez faire quelque chose dès que le CLR est chargé, le simple déchargement de l’AppDomain ne vous aidera pas, car le CLR ne sera pas rechargé.

De plus, IIS n’est pas le seul processus capable d’héberger AppDomain – n’importe quel processus le peut, et vous ne voulez pas toujours tuer tout le processus uniquement pour décharger vos assemblys.

Si vos pages sont “modifiables”, elles doivent être compilées avant utilisation. Cela signifie que oui, lors de la première demande, les assemblages sont chargés, compilés et prêts pour l’access. Chaque fois que ces fichiers sont modifiés (même certains logiciels antivirus peuvent déclencher cela en modifiant la date de modification des fichiers!), Le domaine d’application est recyclé.

Vous pouvez configurer votre application Web pour ne pas pouvoir être mise à jour. Tout est compilé dans les DLL et vous ne verrez aucun fichier .ASPX ou .CS dans le répertoire virtuel. Cela rend votre code plus difficile à mettre à jour (vous devez append du texte supplémentaire sur votre page Web? Temps de recompilation!), Mais cela augmente la disponibilité de votre application Web.

Cependant, cela n’empêche pas que votre application Web soit recyclée si l’un des fichiers est modifié. Par exemple, si vous modifiez web.config, votre domaine d’application sera recyclé même s’il est compilé.