Comment les threads IIS7 sont-ils attribués?

Question

J'ai ajouté log4net à mon application et je peux maintenant voir les identifiants de thread des activités des utilisateurs lorsqu'ils naviguent sur mon site Web. Y a-t-il un algorithme spécifique à l'assignation des threads avec IIS7, ou est-ce juste une assignation aléatoire (je suppose que ce n'est pas complètement aléatoire parce que mon site à faible trafic affiche des threads entre 10 et 30)? Un maximum au nombre de threads disponibles? Et je remarque que mon planificateur apparaît avec un identifiant de threads étrange - une raison pour cela? Le planificateur est Quartz.net et l'identifiant est "Scheduler_Worker-10", et pas seulement un nombre.

Answer 1

This explique tout ce que vous devez savoir.

Un extrait:

Lorsque ASP.NET est hébergé sur IIS 7.0 en mode intégré , l'utilisation de threads est un peu différent. Tout d'abord, les files d'attente au niveau de l'application ne sont plus. Leur performance était toujours vraiment , il n'y avait aucun espoir de régler cela, et donc nous nous sommes débarrassés d'eux. Mais peut-être la plus grande différence est que dans IIS 6.0 , ou en mode ISAPI, ASP.NET limite le nombre de threads simultanément l'exécution des demandes, mais dans IIS 7.0 mode intégré, ASP.NET limite le nombre d'exécuter simultanément demandes . La différence importe seulement lorsque les demandes sont asynchrones (la demande a un gestionnaire asynchrone ou un module dans le pipeline termine de façon asynchrone). Il est évident que si les reqeusts sont synchrones, le nombre d'exécuter simultanément demandes est le même que le nombre de threads d'exécuter simultanément demandes, mais si les demandes sont asynchrones alors ces deux nombres peut être tout à fait différent que vous pourriez ont beaucoup plus de reqeusts que de threads.

Donc, fondamentalement, si les requêtes sont synchrones, le même nombre de threads par requête. Voir ici pour divers parameters.

Answer 2

Je l'ai expliqué c'est un blog sur mon blog ASP.NET Performance-Instantiating Business Layers

Le titre ne correspond pas à votre question, mais j'expliquer la façon dont IIS traite les demandes et je crois que vous aurez votre réponse.

Une citation de l'article

Lorsque IIS champs une demande de votre application il le remet au processus de travail . Le processus de travail dans tour crée et instance de votre classe globale (qui est de type HttpApplication). À partir de ce point, le flux typique d'une application ASP.NET a lieu (pipeline ASP.NET ).Cependant, ce que vous devez connaître et de comprendre est que le processus de travail (penser comme IIS vraiment) garde l'instance de votre HttpApplication (une instance de votre classe mondiale) en vie, afin de champ autres demandes . En fait par défaut il créer et mettre en cache jusqu'à 10 instances de votre classe mondiale, si nécessaire (instanciation Lazy) en fonction de la charge du nombre de demandes votre site Web reçoit d'autres facteurs . Dans la figure 1 ci-dessus, les instances de votre application ASP.NET sont représentées par des zones rouges. Il pourrait être jusqu'à 10 de ceux-ci mis en cache par le processus de travail. Ce sont vraiment des threads que le processus de travail a créé et mis en cache et chaque thread a sa propre instance de votre classe globale. Notez que chacun de ces threads est dans le même App Domain. Donc toutes les classes statiques que vous pourriez avoir dans votre application sont partagées entre chacun de ces threads ou applications instances.

Je vous suggère de lire cet article et je serai heureux de répondre à toutes vos questions. S'il vous plaît noter que j'ai intentionnellement gardé l'article simple en ce que je ne parle pas de ce qui se passe dans le noyau ou d'entrer dans les détails des différentes composantes qui participent. Garder les choses simples aide les gens à mieux comprendre les concepts (je me sens).

Je vais répondre à certaines de vos questions ici:

1. Y at-il algorithme spécifique à la façon dont l'affectation de threads se produit avec IIS7?

Non, à toutes fins utiles, c'est aléatoire. C'est expliqué dans l'article que j'ai pointé. La réponse courte est que si un thread mis en cache est disponible, les IIs l'utiliseront. Sinon, il va créer un nouveau thread, créer et une instance de votre HttpApplication (Global) et lui assigner tout le contexte. Ainsi, dans un site qui n'est pas occupé, vous pouvez voir les mêmes threads gérer les demandes. Mais il n'y a aucune garantie. S'il y a plus d'un thread libre, IIS sélectionne un thread au hasard pour répondre à cette requête. Vous devriez noter ici, que même dans un site pas si occupé, si vos demandes prennent beaucoup de temps, IIS sera forcé de créer de nouveaux threads pour desservir d'autres demandes entrantes.

1. Un maximum au nombre de threads disponibles?

Oui (comme expliqué dans l'article) généralement 10 threads par processus de travail. Cela peut être ajusté, mais j'ai travaillé sur un certain nombre de sites Web extrêmement occupés et je n'ai jamais eu à le faire. La clé est de faire en sorte que vos applications répondent le plus rapidement possible. Une application peut avoir plusieurs processus de travail qui lui sont assignés (configurés dans votre pool d'applications), donc dans les sites occupés, vous voulez plusieurs processus de travail pour votre application, mais vous avez le matériel requis (cœurs de processeur et mémoire).

1. Le planificateur est Quartz.net et l'ID montre que "Scheduler_Worker-10", et pas seulement un numéro

threads peuvent avoir des noms au lieu de Ids. Si un nom a été affecté au thread, vous le verrez à la place d'un identifiant.Bien sûr, pour les threads créés par IIS, vous n'avez aucun contrôle de ce type. Rappelez-vous, je n'ai pas utilisé (ni connu sur Quartz) donc je ne sais pas à ce sujet mais je suppose que c'est le cas.