Quelle est la différence entre DefaultAppPool et Classic .NET AppPool dans IIS7?
J'ai un problème avec les délais d'attente dans IIS. Dans le web.config, le délai d'expiration de la session a été défini sur 60 minutes, mais après 20 minutes, la session se termine.
Ce problème se produit uniquement dans IIS7 et non dans IIS5.
Après une enquête, j'ai découvert que c'était dû au délai d'expiration du pool d'applications. Si le pool d'applications reste 20 minutes sans rien faire, IIS met fin à la session.
Si l'application utilise defaultAppPool, cela se produit toujours, mais si je change le pool d'applications en pool d'applications .NET classique, le délai d'expiration ne se produit pas.
Les deux modes ont un délai d'inactivité mais niquement dans le DefaultAppPool cela se produit.
- Pourquoi est-ce?
- Quelle est la différence entre être un Classic .NET AppPool et DefaultAppPool?
- Quelle est la différence dans le pipeline entre Classic et Integrated?
IIS7 a subi des changements majeurs pour mieux prendre en charge WCF et l'un des éléments clés est le nouveau pool d'applications intégré. Cette session de PDC parle de certains de ces défis du point de vue de l'amélioration des performances des services WCF: http://channel9.msdn.com/pdc2008/TL38/
Cette page a un bon aperçu de l'architecture IIS7: http://learn.iis.net/page.aspx/101/introduction-to-iis7-architecture/ . J'ai inclus certaines des informations clés de cet article sur l'objectif des deux types de pools d'applications ci-dessous:
Mode de pool d'applications intégré
Lorsqu'un pool d'applications est en mode intégré, vous pouvez tirer parti de l'architecture de traitement des demandes intégrée de IIS et ASP.NET. Lorsqu'un processus de travail dans un pool d'applications reçoit une demande, la demande passe par une liste ordonnée d'événements. Chaque événement appelle les modules natifs et gérés nécessaires pour traiter des parties de la demande et générer la réponse. L'exécution de pools d'applications en mode intégré présente plusieurs avantages. Tout d'abord, les modèles de traitement des demandes de IIS et ASP.NET sont intégrés dans un modèle de processus unifié. Ce modèle élimine les étapes qui étaient précédemment dupliquées dans IIS et ASP.NET, telles que l'authentification. De plus, le mode intégré permet la disponibilité des fonctionnalités gérées pour tous les types de contenu.
Mode de pool d'applications classique
Lorsqu'un pool d'applications est en mode classique, IIS 7.0 gère les demandes comme en IIS 6.0 mode d'isolation du processus de travail. Les demandes ASP.NET passent d'abord par des étapes de traitement natives dans IIS, puis sont acheminées vers Aspnet_isapi.dll pour le traitement du code managé dans le runtime managé. Enfin, la demande est renvoyée via IIS pour envoyer la réponse. Cette séparation des modèles de traitement des demandes IIS et ASP.NET entraîne la duplication de certaines étapes de traitement, telles que l'authentification et l'autorisation. En outre, les fonctionnalités de code managé, telles que l'authentification par formulaire, ne sont disponibles que pour les applications ASP.NET ou les applications pour lesquelles vous avez mappé par script toutes les demandes à gérer par aspnet_isapi.dll. Assurez-vous de tester la compatibilité de vos applications existantes en mode intégré avant de mettre à niveau un environnement de production vers IIS 7.0 et d'attribuer des applications à des pools d'applications en mode intégré. Vous ne devez ajouter une application à un pool d'applications en mode classique que si l'application ne fonctionne pas en mode intégré. Par exemple, votre application peut s'appuyer sur un jeton d'authentification transmis de IIS au runtime géré et, en raison de la nouvelle architecture dans IIS 7.0, le processus interrompt votre application.
Le pool classique traite les demandes dans le pool d'applications en utilisant des pipelines de traitement séparés pour IIS et ISAPI. Integrated utilise un pipeline intégré, IIS et ASP.NET a ( meilleures performances) tire parti des fonctionnalités améliorées de IIS 7.0 en utilisant un seul processus. La bonne pratique consiste à créer un nouveau pool d'applications pour chaque application, puis à configurer séparément en fonction des exigences de l'application.
mode classique suit les étapes ci-dessous:
1.La requête HTTP entrante est reçue via le noyau IIS.
2.La demande est traitée via ISAPI.
3.La demande est traitée via ASP.NET.
4.La demande est renvoyée via ISAPI.
5.La demande repasse par le noyau IIS où la réponse HTTP est finalement livrée
mode intégré utilise:
1.La demande HTTP entrante est reçue via le noyau IIS et ASP.NET.
2.Le gestionnaire approprié exécute la demande et fournit la réponse HTTP
Augmentez le délai d'expiration de la session dans web.config selon
rappelez-vous qu'en augmentant cela, l'application consomme plus de ressources, par exemple de la mémoire
Je pense que votre question contient la réponse. IIS 6 et 7 ont un concept de délai d'expiration du pool d'applications, différent du délai d'expiration de session.
Quelle est la différence entre les modes ... déjà abordée. Je ne sais pas comment vos questions concernant les pipelines et les différences de modes sont liées à votre problème - les délais d'attente.
Une certaine perspective: le délai d'inactivité ne se produira pas sur un site Web avec du trafic. Vous avez probablement un problème qui ne se produit que sur un site QA ou votre boîte de développement. Le paramètre de délai d'inactivité existe pour économiser des ressources sur votre boîte de développement et des sociétés d'hébergement de 5 $/mois avec de nombreux sites Web sous-utilisés (par exemple, mon blog). Vous ne voulez probablement pas de délai d'inactivité sur un site public.
Délai d'expiration de la session - défini dans la configuration Web, si un utilisateur ne touche pas le serveur, sa session expire.
Délai d'inactivité Personne ne touche du tout au serveur Web pendant 20 minutes, alors arrêtez-vous pour économiser des ressources. Dans IIS 6 , cela se trouve dans l'onglet performances du pool d'applications - et il est facile de le désactiver. Dans IIS 7, vous pouvez définir des paramètres avancés dans le pool d'applications ou dans élément processModel . Je n'exécute pas autant IIS 7 que IIS 6, mais il semble que la suppression de l'élément de web.config, ou la définition de 0, obtient un délai d'inactivité infini.
DefaultAppPool ignore les paramètres de délai d'expiration de session dans web.config, mais le pool d'applications ASPNet utilisera les paramètres dans web.config.