IIS 7.x Meilleures pratiques du pool d'applications
Nous sommes sur le point de déployer un tas de sites sur de nouveaux serveurs. J'ai les questions suivantes sur les pools d'applications:
Il semble conseillé d'avoir un pool d'applications par site Web. Y a-t-il des réserves à cette approche? Un pool d'applications monopolisera-t-il tout le CPU, la mémoire, etc.?
Quand devez-vous autoriser plusieurs processus de travail dans un pool d'applications? Quand ne devriez-vous pas?
La limite de mémoire privée peut-elle être utilisée pour empêcher un pool d'applications d'interférer avec un autre? Une valeur trop basse entraînera-t-elle des demandes valides pour recycler le pool d'applications sans obtenir de réponse valide?
Quelle est la différence entre les limites de mémoire privée et virtuelle?
Existe-t-il des raisons impérieuses de NE PAS exécuter un pool d'applications par site?
1) Il semble conseillé d'avoir un pool d'applications par site Web. Y a-t-il des réserves à cette approche? Un pool d'applications peut-il, par exemple, monopoliser tout le CPU, la mémoire, etc.?
C'est une assez bonne approche; il n'y a pas de bonnes raisons pour lesquelles je puisse penser que différents "sites" (applications) partagent le même pool. Sauf s'ils ont besoin de partager une seule ressource quelconque. Une application pourrait théoriquement monopoliser beaucoup de CPU ou de mémoire, mais changer la façon dont les applications sont mises en commun n'affectera pas vraiment beaucoup.
2) Quand devez-vous autoriser plusieurs processus de travail dans un pool d'applications. Quand ne devriez-vous pas?
Il vaut mieux laisser seul, en utilisant les paramètres par défaut. Sauf si vous savez vraiment ce que vous faites, cela peut avoir un impact négatif sur votre site Web/application.
3) La limite de mémoire privée peut-elle être utilisée pour empêcher un pool d'applications d'interférer avec un autre? Une valeur trop basse entraînera-t-elle des demandes valides pour recycler le pool d'applications sans obtenir de réponse valide?
a) Théoriquement
b) Oui, le régler à un niveau plus bas peut avoir des effets négatifs. Encore une fois, sauf si vous avez des besoins spécifiques et savez ce que vous faites, laissez-les tranquilles.
4) Quelle est la différence entre les limites de mémoire privée et virtuelle?
C'est très compliqué, voici un petit article que j'ai trouvé qui pourrait aider: http://cybernetnews.com/cybernotes-windows-memory-usage-explained/
5) Y a-t-il des raisons impérieuses de NE PAS exécuter un pool d'applications par site?
Encore une fois, la seule raison pour laquelle je peux penser est qu'il existe une sorte de "ressource partagée" dont les multiples applications ont besoin, alors vous voudrez les exécuter dans le même processus.
Pour les applications et les sites Web à usage général, IIS est assez bien configuré avec ses valeurs par défaut.
****MISE À JOUR****
En ce qui concerne votre demande d'informations supplémentaires sur # 2, vous ne devriez pas le faire, sauf si vous en avez un besoin spécifique. Même avec des actions de serveur qui prennent du temps, les demandes sont servies à l'aide de plusieurs threads, et vous voudrez utiliser des "demandes asynchrones" pour gérer les tâches de longue durée (ce qui libère un thread de pool de threads pour gérer les autres requêtes). De manière réaliste, je ne vois aucune bonne raison d'autoriser plusieurs processus pour un seul pool.
Une fois que vous commencez à parler de plusieurs processus, vous risquez de tomber sur des choses comme: la perte de l'état de session car une session est active dans le processus 1, mais la demande est gérée par le processus 2. Ou pire encore, vous devez comprendre comment faire de la communication inter-processus, ce qui est vraiment pénible.
Peu importe ce que vous proposez en ce qui concerne une raison pour plusieurs processus, je serais prêt à parier qu'il existe une meilleure façon de le gérer (plutôt que de lancer un autre processus).
Je configure toujours un pool d'applications dédié pour un site Web. Les scénarios d'hébergement de sites Web à faible coût sont ceux où il est logique d'avoir un grand nombre de sites par pool d'applications.
Les limites de mémoire ne sont en réalité que des seuils de sécurité primitifs pour empêcher un site de consommer toutes les ressources système. Notez qu'il s'agit davantage d'un problème potentiel sur Windows 2008 R2 x64 que sur IIS 6.0 x86, car les applications x86 avaient un plafond de mémoire naturel de 2 Go. C'est beaucoup plus facile sur IIS 7.5 pour une application avec une fuite de mémoire pour consommer de grandes quantités de mémoire.
Je ne suis pas non plus un grand fan du recyclage des pools d'applications. Si j'ai un pool d'applications et que je suis la seule application en cours d'exécution, s'il n'y a rien de mal avec notre code, il n'est probablement pas nécessaire de recycler le pool d'applications. Et s'il y a un défaut dans l'application, l'ultime action appropriée serait de corriger le code.