Come vengono assegnati i thread IIS7?

Question

Ho aggiunto log4net alla mia applicazione e ora è possibile vedere gli ID dei thread delle attività dell'utente mentre navigano nel mio sito web. Esiste un algoritmo specifico sul modo in cui l'assegnazione dei thread avviene con IIS7, o è solo un'assegnazione di numeri casuali (ho il sospetto che non sia del tutto casuale perché il mio sito a basso traffico mostra i thread per lo più nell'intervallo 10-30)? Qualunque numero massimo di thread disponibili? E noto che il mio programma di pianificazione si presenta con un codice di identificazione strano, qualsiasi ragione per questo? Lo scheduler è Quartz.net e l'id mostra "Scheduler_Worker-10", e non solo un numero.

Answer 1

This spiega tutto ciò che è necessario sapere.

un estratto:

Quando ASP.NET è ospitato su IIS 7.0 in modalità integrata , l'uso di fili è un po 'diverso. Prima di tutto, le code a livello di applicazione non ci sono più. La loro esibizione era sempre in realtà male, non c'era alcuna speranza nel risolvere questo, e così ci siamo sbarazzati di loro. Ma forse la più grande differenza è che in IIS 6.0 , o in modalità ISAPI, ASP.NET limita il numero di thread simultaneamente esecuzione richieste, ma in IIS 7.0 modalità integrata, ASP.NET limita il numero di eseguire contemporaneamente richieste . La differenza interessa solo quando le richieste sono asincrone (la richiesta ha un gestore asincrono o un modulo in la pipeline completa in modo asincrono). Ovviamente se il Richiesta di vieo sono sincroni, allora il numero di eseguire contemporaneamente richieste è uguale al numero di fili contemporaneamente esecuzione richieste, ma se le richieste sono asincrone allora questi due numeri può essere molto diverso come si potrebbe hanno molte più domande per i thread.

Quindi, in pratica, se le richieste sono sincrone, lo stesso numero di thread per richiesta. Vedi qui per vari parameters.

Answer 2

ho spiegato che questo è un post sul blog sul mio blog ASP.NET Performance-Instantiating Business Layers

Il titolo non coincide con la tua domanda, ma spiego il modo in cui IIS gestisce le richieste e credo che avrai la tua risposta.

Una citazione dall'articolo

Quando IIS campi una richiesta per la vostra applicazione che lo consegna al processo lavoratore. Il processo di lavoro nel turno crea e l'istanza della classe globale (che è di tipo HttpApplication). Da questo punto su si verifica il flusso tipico di un'applicazione ASP.NET (la pipeline di ASP.NET ).Tuttavia, ciò che è necessario conoscere e capire è che il processo di lavoro (pensare ad esso come IIS davvero) mantiene l'istanza del vostro HttpApplication (un'istanza della classe globale ) vivi, al fine di mettere in campo altre richieste . Infatti per default sarebbe creare e memorizzare nella cache fino a 10 istanze della tua classe globale, se necessario (pigro esemplificazione) a seconda del carico del numero di richieste di tuo sito web riceve altri fattori. Nella Figura 1 sopra le istanze della tua applicazione ASP.NET sono visualizzate come caselle rosse. Lì potrebbe contenere fino a 10 di questi nella cache del processo . Questi sono in realtà i thread che il processo di lavoro ha creato e memorizzato nella cache e ogni thread ha la propria istanza della classe Globale. Si noti che ciascuno di questi thread si trova nello stesso Dominio app. Pertanto, tutte le classi statiche che si possono avere nell'applicazione sono condivise tra ciascuna delle istanze o le istanze .

Ti suggerisco di leggere questo articolo e sarò felice di rispondere a qualsiasi domanda tu possa avere. Tieni presente che ho intenzionalmente mantenuto l'articolo in modo semplice in quanto non parlo di ciò che accade nel kernel o nei dettagli dei vari componenti che partecipano. Mantenerlo semplice aiuta le persone a capire i concetti molto meglio (mi sento).

io rispondere ad alcune delle vostre domande qui:

1. Esiste un algoritmo specifico per quanto assegnazione discussioni succede con IIS7?

No, per tutti gli scopi è casuale. Questo è spiegato nell'articolo che ho indicato. La risposta breve è che se un thread in cache è disponibile, IIs lo userà. In caso contrario, creerà una nuova discussione, creerà e un'istanza della tua HttpApplication (Globale) e assegnerà tutto il contesto ad essa. Pertanto, in un sito non occupato, è possibile che gli stessi thread gestiscano le richieste. Ma non ci sono garanzie. Se c'è più di un thread libero, IIS selezionerà un thread a caso per servire quella richiesta. Qui dovresti notare che, anche in un sito non così occupato, se le tue richieste impiegano molto tempo, IIS sarà costretto a creare nuovi thread per soddisfare altre richieste in entrata.

1. Qualunque numero massimo di thread disponibili?

Sì (come spiegato nell'articolo) in genere 10 thread per processo di lavoro. Questo può essere regolato, ma ho lavorato su un numero di siti Web estremamente occupati e non ho mai dovuto. La chiave è fare in modo che le vostre applicazioni rispondano il più velocemente possibile. Tenendo presente che un'applicazione può avere più processi di lavoro ad essa assegnati (configurati nel pool di app) in modo che nei siti occupati si desideri effettivamente più processi di lavoro per l'applicazione, tuttavia l'implicazione è che si dispone dell'hardware richiesto (core CPU e memoria).

1. Lo scheduler è Quartz.net e l'id mostra come "Scheduler_Worker-10", e non solo un numero

thread possono avere nomi invece di Ids. Se al thread è stato assegnato un nome, lo vedrai invece di un id.Ovviamente per i thread che IIS crea non hai tale controllo. Intendiamoci, non ho usato (né conosco il quarzo), quindi non lo so, ma credo che sia così.