Quelqu'un peut-il expliquer les différences, dans IIS, entre les pools d'applications, les processus de travail et les domaines d'applications ? Et comment fonctionnent-ils ensemble ? J'ai lu quelques articles mais c'est toujours un peu confus.
J'essaie de les dire avec d'autres mots.
Dans un serveur, vous pouvez avoir plusieurs sites asp.net qui fonctionnent ensemble. Chaque site est un domaine des applications .
Vous devez attribuer à chacun d'eux un parc de candidatures . Plusieurs domaines d'application (sites) peuvent avoir le même pool d'applications, et parce qu'ils ont le même pool d'applications, ils fonctionnent sous les mêmes processus, et sous le même compte - et ils ont les mêmes paramètres du pool. Si ce pool redémarre, alors tous les sites sous ce pool redémarrent.
Maintenant, chaque pool peut avoir un ou plusieurs processus de travail . Chaque processus de travail est un programme différent qui exécute votre site, possède ses propres variables statiques, ses différents appels de démarrage et d'arrêt, etc. Les différents processus de travail ne peuvent pas communiquer ensemble, et la seule façon d'échanger des données est à partir de fichiers communs ou d'une base de données commune. Si vous avez plus d'un processus de travail et que l'un d'entre eux effectue des calculs de longue durée, l'autre peut se charger de gérer les appels Internet et de montrer le contenu.
Lorsque vous attribuez plusieurs processus de travail à un seul pool, vous faites en sorte que le processus appelé jardin virtuel et votre site doit être exécuté à partir de plus d'un ordinateur si un ordinateur est une seule machine de traitement.
Chaque processus de travailleur peut avoir plusieurs threads.
Comment le processus "plus de travail" vous affecte :
Lorsque vous avez un processus de travail tout est plus simple, au sein de votre application toutes les variables statiques sont les mêmes, et vous utilisez la fonction lock pour les synchroniser.
Lorsque vous attribuez plus d'un processus de travail alors vous continuez à utiliser le lock pour les variables statiques, les variables statiques ne sont pas différentes parmi les nombreuses exécutions de votre site, et si vous avez une ressource commune (par exemple la création d'une vignette sur le disque) alors vous devez synchroniser votre processus de travail avec Mutex .
Une dernière remarque. Il semble que lorsque vous faites plus de processus de travail alors vous pourrez avoir des chargements de pages asynchrones plus fluides. Il existe un petit problème avec le gestionnaire de session d'asp.net qui bloque l'ensemble du processus de chargement d'une page - ce qui est bon et moins bon dépend de ce que vous savez et gérez - ou changez.
Parlons donc d'un seul site avec plusieurs processus de travail. Ici, vous êtes confronté à un problème : vous devez synchroniser les changements de vos ressources communes avec Mutex . Mais les pages/handlers qui utilisent la session ne sont pas asynchrones car la session les verrouille. C'est une bonne chose pour commencer car vous évitez de faire vous-même la synchronisation de nombreux points.
Quelques questions sur ce sujet :
Une application Web est bloquée lors du traitement d'une autre application Web sur le partage de la même session.
Les appels Ajax de jQuery au service web semblent être synchrones
Le serveur ASP.NET ne traite pas les pages de manière asynchrone.
Remplacer entièrement la session d'ASP.Net
Maintenant, ce verrouillage de session n'affecte pas les différents sites.
Entre différents sites, le processus le plus travaillé peut aider à éviter qu'un site ne bloque l'autre avec un processus long.
De même, parmi les différents sites, le plus grand nombre de pools peut également aider, car chaque pool a au moins un processus de travail, mais rappelez-vous et voyez par vous-même en utilisant l'explorateur de processus, chaque processus de travail prend plus de mémoire de votre ordinateur, et un grand serveur avec 16G de mémoire et un serveur SQL ne peut pas avoir trop de processus de travail différents - par exemple sur un serveur avec 100 sites partagés, vous ne pouvez pas avoir 100 pools différents.
La signification pour les développeurs ASP.NET : pour rendre votre site web évolutif, n'utilisez pas de session in-proc et n'utilisez pas de verrou de variable de classe statique pour la synchronisation.
Oui, mais toutes les applications ne sont pas des sites web. Vous pouvez avoir une application qui est imbriquée sous un site web.
Oui, chaque application doit avoir un processus de travail (pool d'applications), bien qu'un pool d'applications puisse servir à plusieurs applications. Une seule application web peut être distribuée (web garden/farm), ce qui signifie qu'elle s'exécutera dans plusieurs processus.
Chaque processus sera exécuté dans son propre domaine d'applications (chaque pool d'applications est un domaine d'applications distinct).
De MSDN.
Une application est un regroupement de contenu au niveau de la racine d'un site Web ou un regroupement de contenu dans un dossier séparé sous le répertoire racine du site Web.
Un pool d'applications définit un groupe d'un ou plusieurs processus de travail, configurés avec des paramètres communs qui servent des requêtes à une ou plusieurs applications qui sont assignées à ce pool d'applications. Comme les pools d'applications permettent à un ensemble d'applications Web de partager un ou plusieurs processus de travail configurés de manière similaire, ils constituent un moyen pratique d'isoler un ensemble d'applications Web des autres applications Web sur l'ordinateur serveur. Les limites de processus séparent chaque processus de travail ; par conséquent, les problèmes d'application dans un pool d'applications n'affectent pas les sites Web ou les applications dans d'autres pools d'applications. Les pools d'applications augmentent considérablement la fiabilité et la facilité de gestion de votre infrastructure Web.
Depuis le lien source : http://weblogs.asp.net/owscott/archive/2007/09/02/application-vs-appdomain.aspx
Une application est un terme IIS, mais c'est un terme utilisé par ASP.NET. Essentiellement, il crée un bac à sable, ou un ensemble de frontières pour séparer différents sites, ou parties de sites, des autres.
Un AppDomain est un terme .NET. (Dans IIS7, les AppDomains jouent un rôle plus important dans IIS, mais pour la plupart, c'est un terme ASP.NET).
Le processus worker est utilisé pour traiter la requête de l'application web.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
