Quelle est la meilleure pratique pour décider du nombre de processus de travail à autoriser pour une application Web ASP.NET ?
Sur l'un des serveurs que je gère, la création d'un nouvel AppPool donne lieu par défaut à 10 processus de travail (maximum). D'autres personnes suggèrent que le paramètre normal est de un.
Quel problème les processus à travailleurs multiples résolvent-ils et quelles sont les techniques pour décider du nombre de travailleurs ?
Les processus de travail sont un moyen de segmenter l'exécution de votre site web entre plusieurs exe. Il y a plusieurs raisons à cela : si l'un des workers se fait démolir par des problèmes d'exécution, les autres ne tomberont pas pour autant. Par exemple, si une requête html arrive et provoque l'arrêt du processus, seules les autres requêtes traitées par ce processeur sont tuées. Un autre exemple est qu'une requête pourrait bloquer les autres threads gérés par le même processeur.
Pour ce qui est du nombre dont vous avez besoin, faites des tests de charge. Lancez l'application à fond et voyez ce qui se passe avec une seule. Ensuite, ajoutez-en d'autres et recommencez. À un moment donné, vous atteindrez un point où le réseau, le disque, le processeur et la mémoire vive de la machine seront vraiment saturés. C'est alors que vous saurez que vous avez trouvé le bon équilibre.
Par ailleurs, vous pouvez contrôler le nombre de threads utilisés par processus de travail via le fichier machine.config. Je crois que la clé est maxWorkerThreads.
Maintenant, attention, si vous utilisez la session, l'état de la session n'est pas partagé entre les processus de travail. Je recommande généralement d'éviter la session de toute façon mais c'est quelque chose à considérer.
À toutes fins utiles, vous pouvez considérer chaque processus de travail comme un serveur web distinct. Sauf qu'ils sont exécutés sur la même machine.
Les directives ici sont assez bonnes : http://msdn.microsoft.com/en-us/library/ms998549.aspx
Fuites de mémoire
L'autre grand avantage est la gestion des fuites de mémoire. Parfois, même si vous essayez d'optimiser votre code, il y a des fuites de mémoire dans le framework lui-même et dans des bibliothèques tierces. Nous avons remarqué que notre application finit par atteindre une mémoire très élevée et commence à donner des exceptions de mémoire.
Nous avons donc dû fixer une limite de mémoire virtuelle maximale pour le processus de travail à 1 Go et permettre à plusieurs processus de fonctionner. Vous pourriez fixer une limite virtuelle maximale même pour un seul processus de travail, mais cela conduit à des pics de ralentissement, car lorsque le processus de travail est recyclé, toutes les demandes sont lentes jusqu'à ce que le processus de travail retrouve une bonne vitesse. Comme notre application a une mise en cache interne (Entity Framework Query Cache, certains pools d'objets), chacun de ces éléments ralentit le démarrage de l'application. C'est là que le processus de travailleur unique est le plus pénible.
S'il y a plusieurs processus de travail, seul un des processus en mode recyclage est lent, mais les autres gardent une bonne vitesse.
Un autre cas où il est judicieux d'avoir plusieurs processus de travail est celui où votre application contient des verrous qui empêchent sa parallélisation. Le traitement d'images basé sur GDI+ en est un exemple.
Je l'ai trouvé lorsque j'ai essayé de trouver une solution pour mon problème .
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.
