IIS pools d'applications, processus de travail, domaines d'application
Quelqu'un peut-il expliquer les différences, dans IIS, entre les pools d'applications, les processus de travail et les domaines d'application? Aussi, comment travaillent-ils ensemble? J'ai lu quelques articles mais cela reste un peu déroutant.
- Chaque site Web créé dans IIS devient-il une application?
- Chaque application est-elle associée à un processus de travail?
- Où les domaines d'application entrent-ils dans l'image?
J'essaie de les dire avec d'autres mots.
Sur un serveur, vous pouvez avoir plusieurs sites asp.net qui fonctionnent ensemble. Chaque site est un domaine app.
Vous devez attribuer à chacun d'eux un pool d'applications. De nombreux domaines d'application (sites) peuvent avoir le même pool d'applications et, comme ils ont le même pool d'applications, ils s'exécutent 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, tous les sites situés sous ce pool redémarrent.
Désormais, chaque pool peut avoir un ou plusieurs processus de travail. Chaque processus de travail est un programme différent qui exécute votre site, a ses seules variables statiques, des appels d'arrêt et de démarrage différents, etc. Différents processus de travail ne communiquent pas ensemble et le seul moyen d'échanger des données est d'utiliser des fichiers communs ou une base de données commune. Si vous avez plusieurs processus de production et que l’un effectue des calculs de longue durée, l’autre peut prendre soin de gérer les appels Internet et d’afficher le contenu.
Lorsque vous affectez plusieurs processus de travail à un seul pool, vous créez alors le = jardin Web appelé et votre site est comme s'il était exécuté à partir de plusieurs ordinateurs si l'ordinateur est une machine de traitement.
Chaque processus de travail peut avoir plusieurs threads.
Comment plus de processus de travail vous affecte:
Quand vous avez un processus de travail tout est plus simple, dans votre application, toutes les variables statiques sont identiques et vous utilisez le lock pour les synchroniser.
Lorsque vous affectez plusieurs processus de travail, vous continuez toujours à utiliser le lock pour les variables statiques. Les variables statiques ne diffèrent pas entre les nombreuses exécutions de votre site, et si vous avez des ressources communes (par exemple la création d’une vignette sur le disque), vous devez synchroniser votre processus de travail avec Mutex .
Encore une note. Il semble que lorsque vous créez plus de processus de travail, vous pouvez obtenir des chargements de page asynchrones plus lisses. Il y a un petit problème avec le gestionnaire de session de asp.net qui verrouille tout le processus pour le chargement d'une page - c'est bon et pas bon dépend si vous le connaissez et le manipulez - ou le changez.
Alors, parlons d’un seul site avec plusieurs processus de travail. Ici, vous faites face au problème que vous devez synchroniser votre changement de ressource commune avec Mutex. Mais les pages/gestionnaires qui utilisent session ne sont pas asynchrones car la session les verrouille. C'est bon pour commencer car vous évitez de faire vous-même cette synchronisation de nombreux points.
Quelques questions sur ce sujet:
Application Web bloquée lors du traitement d'une autre application Web lors du partage de la même session
les appels jQuery Ajax au service Web semblent être synchrones
ASP.NET Server ne traite pas les pages de manière asynchrone
Remplacement complet de la session d'ASP.Net
Désormais, ce verrouillage de session n’affecte pas différents sites.
Parmi les différents sites, le processus le plus élaboré peut aider à éviter que l'un des sites ne bloque l'autre avec un processus de longue durée.
De plus, parmi les différents sites, plus de pools peuvent aussi aider, car chaque pool a au moins un processus exécuté, mais souvenez-vous et visualisez vous-même à l’aide de l’explorateur de processus, chaque processus de travail utilise plus de mémoire de votre ordinateur et un seul. Un gros serveur avec 16G de mémoire et un serveur SQL ne peut pas avoir trop de processus différents. Par exemple, sur un serveur avec 100 sites partagés, vous ne pouvez pas avoir 100 pools différents.
- Un serveur IIS peut avoir plusieurs pools d'applications.
- Une application Web est liée à un pool d'applications.
- Un pool d'applications peut avoir plusieurs processus de travail (lorsque Web Garden est activé).
- Un processus de travail peut avoir plusieurs domaines d'application. Un domaine d'application ne réside que dans un seul processus de travail.
- Un domaine d'application peut avoir plusieurs threads. Un fil peut être partagé par différents domaines d'application à différentes heures.
Signification pour les développeurs ASP.NET: pour rendre votre site Web évolutif, n’utilisez pas de session in-proc ni de verrou de variable de classe statique pour la synchronisation.
Oui, bien que toutes les applications ne soient pas des sites Web. Vous pouvez avoir une application qui est imbriquée sous sur 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 (jardin Web/ferme), ce qui signifie qu'elle s'exécutera dans plusieurs processus.
Chaque processus s'exécutera dans son propre domaine d'application (chaque pool d'applications est un domaine d'application distinct).
De MSDN.
Une application est un groupe de contenu situé au niveau racine d'un site Web ou un groupe de contenu situé dans un dossier distinct 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 servant les demandes adressées à une ou plusieurs applications affecté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'applications dans un pool d'applications n'affectent pas les sites Web ni les applications 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 ASP.NET en est un. Il crée essentiellement un bac à sable ou un ensemble de limites permettant de séparer différents sites ou parties de sites des autres.
Un AppDomain est un terme .NET. (Dans IIS7, AppDomains joue un rôle plus important dans IIS, mais il s’agit généralement d’un terme ASP.NET)
Le processus de travail est utilisé pour traiter la demande de l'application Web.