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, par exemple, peut-il 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 peux 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 inférieur 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 requêtes sont servies à l'aide de plusieurs threads, et vous voudrez utiliser des "requêtes asynchrones" pour gérer les tâches de longue durée (ce qui libère un thread de pool de threads pour gérer d'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).