ASP.NET IIS - lorsque les demandes sont en attente?

Question

La suite de l'article de Thomas Marquardt décrit comment IIS traite ASP.Net les demandes, max/min CLR threads/Géré IO threads qui peuvent être configurés pour s'exécuter, les différentes demandes des files d'attente impliqués et leurs tailles par défaut.

Désormais, selon l'article, les suivants se produit dans IIS 6.0:

1. ASP.NET ramasse les demandes à partir d'un IIS IO Fil et des postes "HSE_STATUS_PENDING" de IIS IO Fil
2. La demande est transmise à un CLR thread de travail
3. Si les demandes sont de latence élevée, et tous les fils sont occupés (le nombre de threads approches httpRuntime.minFreeThreads), puis les demandes sont validées pour l'Application demande au niveau de la file d'attente (cette file d'attente est par domaine d'application)
4. Aussi ASP.NET vérifie le nombre de simultanément à l'exécution des demandes. L'article stipule que "si le nombre d'simultanément à l'exécution de demandes est trop élevé" il les files d'attente les demandes entrantes à un ASP.NET mondial de la demande de la file d'attente (c'est par Processus de travail) (Veuillez vérifier la mise à Jour 2)

Je veux savoir quelle est la "valeur seuil", à quel point ASP.NET estime que le nombre de demandes en cours d'exécution trop haut et puis commence files d'attente les demandes pour le mondial ASP.NET demande de file d'attente?

Je pense que ce seuil dépend de la configuration du nombre maximal de threads de travail, mais il pourrait y avoir une formule qui ASP.NET permettra de déterminer que le nombre de simultanément à l'exécution de demandes est trop élevé et commence files d'attente les demandes à l'ASP.NET mondial de la demande de la file d'attente. Qu'en est-il de la formule? ou est-ce paramètre configurable?

---

Mise à jour

J'ai lu l'article et dans les commentaires des articles, j'ai trouvé ceci:

1) Sur IIS 6 et dans IIS 7 en mode classique, chaque application (domaine d'application) a une file d'attente qu'il utilise pour maintenir la disponibilité du travailleur les threads. Le nombre de demandes dans cette file d'attente augmente si le nombre de threads disponibles tombe en dessous de la limite spécifiée par httpRuntime minFreeThreads. Lorsque la limite spécifiée par httpRuntime appRequestQueueLimit est dépassé, la demande est rejeté avec un 503 code d'état, et le client reçoit un HttpException avec le message "Serveur trop occupé." Il y a aussi un ASP.NET compteur de performance, "les Demandes En Application de la File d'attente", qui indique le nombre de demandes dans la file d'attente. Oui, le CLR fil la piscine est celle exposée par l' .NET classe ThreadPool.

2) La requestQueueLimit est mal nommée. Il en fait des limites de la nombre maximal de demandes qui peuvent être desservis par ASP.NET en même temps. Cela comprend à la fois les demandes qui sont en attente et demandes en cours d'exécution. Si les Demandes de "Courant" de la performance compteur dépasse requestQueueLimit, de nouvelles requêtes entrantes seront rejeté avec un code d'état 503.

Donc, essentiellement, requestQueueLimit limite le nombre de demandes qui sont en attente (je suis en supposant qu'elle sera la somme du nombre de demandes en attente dans l'Application des files d'attente plus le mondial ASP.Net demande de file d'attente, plus le nombre de demandes en cours d'exécution) et sont en cours d'exécution. Tout bien que cela ne répond pas à la question d'origine, il fournit de l'information sur le moment où nous pourrions recevoir un 503 serveur occupé d'erreur en raison du nombre élevé de demandes simultanées/temps de latence élevé de demandes. (Vérifier la mise à jour 2)

---

Mise à jour 2 Il y avait une erreur de ma part dans la compréhension. J'avais mélangé les descriptions pour IIS 6 et IIS 7.
Essentiellement quand ASP.NET qui est hébergé sur IIS 7.5 et 7.0 en mode intégré, le niveau de l'application des files d'attente ne sont plus présents, ASP.NET maintient un mondial des demandes en file d'attente.
Si IIS 7j / 7.5 va commencer à la file d'attente de demandes global à la demande de la file d'attente si le nombre de l'exécution de demandes est considérée comme élevée. La question s'applique plus à IIS 7j / 7.5 au lieu de 6.

Autant IIS 6.0 , il n'y a pas de mondial ASP.NET demande de file d'attente, mais la suivante est vraie:
1. ASP.NET ramasse les demandes à partir d'un IIS IO Fil et des postes "HSE_STATUS_PENDING" de IIS IO Fil
2. La demande est transmise à un CLR thread de travail
3. Si les demandes sont de latence élevée, et tous les fils sont occupés (le nombre de threads approches httpRuntime.minFreeThreads), puis les demandes sont validées pour l'Application demande au niveau de la file d'attente (cette file d'attente est par domaine d'application)
4. Aussi ASP.NET vérifie le nombre de demandes en attente et en cours d'exécution avant d'accepter une nouvelle demande. Si ce nombre est supérieur à la valeur spécifiée par processModel.requestQueueLimit ensuite les demandes entrantes seront rejetées avec 503 serveur occupé d'erreur.

Answer 1

Cet article peut vous aider à comprendre les paramètres un peu mieux.

minFreeThreads: Ce paramètre est utilisé par le processus de travail de la file d'attente de toutes les demandes entrantes si le nombre de threads disponibles dans le pool de threads tombe au-dessous de la valeur de ce paramètre. Ce paramètre pour effet de limiter le nombre de demandes qui peuvent s'exécuter simultanément pour maxWorkerThreads minFreeThreads. Ensemble minFreeThreads 88 * # de Les processeurs. Cela limite le nombre de requêtes simultanées à 12 (en supposant que maxWorkerThreads est de 100).

Edit:

Dans cette SORTE de post, Thomas fournit plus de détails et des exemples de traitement de la demande dans le pipeline intégré. Assurez-vous de lire les commentaires sur la réponse des explications supplémentaires.

Originaire de rappel (en webengine.dll) ramasse demande sur CLR travailleur fil, nous comparons maxConcurrentRequestsPerCPU * CPUCount total les demandes actives. Si nous avons dépassé la limite, demande est insérée dans mondial de la file d'attente (en code natif). Sinon, il sera exécuté. Si c'était en file d'attente, il sera retiré lorsque l'on active de la demande complète.