Utilizzo di ThreadPool.QueueUserWorkItem in ASP.NET in uno scenario di traffico elevato

Ho sempre avuto l'impressione che l'utilizzo di ThreadPool per (diciamo non critici) attività in background di breve durata fosse considerata una best practice, anche in ASP.NET, ma poi mi sono imbattuto in questo articolo che sembra suggerire il contrario: il l'argomento è che dovresti lasciare ThreadPool per gestire le richieste relative ad ASP.NET.

Quindi ecco come ho svolto finora piccole attività asincrone:

ThreadPool.QueueUserWorkItem(s => PostLog(logEvent))

E l'articolo suggerisce invece di creare un thread in modo esplicito, simile a:

new Thread(() => PostLog(logEvent)){ IsBackground = true }.Start()

Il primo metodo ha il vantaggio di essere gestito e limitato, ma c'è la possibilità (se l'articolo è corretto) che le attività in background siano quindi in competizione per i thread con gestori di richieste ASP.NET. Il secondo metodo libera il ThreadPool, ma a costo di essere illimitato e quindi potenzialmente utilizzare troppe risorse.

Quindi la mia domanda è: il consiglio nell'articolo è corretto?

Se il tuo sito riceveva così tanto traffico che il tuo ThreadPool si stava riempiendo, allora è meglio andare fuori banda, o un ThreadPool completo implicherebbe che stai comunque arrivando al limite delle tue risorse, nel qual caso tu non dovresti provare ad avviare i tuoi thread?

Chiarimento: sto solo chiedendo nell'ambito di piccole attività asincrone non critiche (ad esempio, registrazione remota), elementi di lavoro non costosi che richiederebbero un processo separato (in questi casi sono d'accordo che avrai bisogno di una soluzione più robusta).

Altre risposte qui sembrano tralasciare il punto più importante:

A meno che tu non stia cercando di parallelizzare un'operazione che richiede molta CPU per farla più velocemente su un sito a basso carico, non ha alcun senso usare un thread di lavoro.

Ciò vale sia per i thread gratuiti, creati da new Thread(...), sia per i thread di lavoro in ThreadPoolche rispondono alle QueueUserWorkItemrichieste.

Sì, è vero, puoi morire di fame ThreadPoolin un processo ASP.NET accodando troppi elementi di lavoro. Impedirà ad ASP.NET di elaborare ulteriori richieste. Le informazioni contenute nell'articolo sono accurate a tale riguardo; lo stesso pool di thread utilizzato per QueueUserWorkItemviene utilizzato anche per servire le richieste.

Ma se stai effettivamente mettendo in coda abbastanza elementi di lavoro da causare questa fame, allora dovresti morire di fame il pool di thread! Se stai eseguendo letteralmente centinaia di operazioni che richiedono un uso intensivo della CPU allo stesso tempo, a cosa sarebbe utile avere un altro thread di lavoro per servire una richiesta ASP.NET, quando la macchina è già sovraccarica? Se ti trovi in ​​questa situazione, devi riprogettare completamente!

La maggior parte delle volte vedo o sento parlare di codice multi-thread utilizzato in modo inappropriato in ASP.NET, non è per accodare il lavoro che richiede molta CPU. Serve per accodare il lavoro associato a I / O. E se si desidera eseguire operazioni di I / O, è necessario utilizzare un thread I / O (porta di completamento I / O).

In particolare, dovresti usare i callback asincroni supportati da qualunque classe di libreria stai usando. Questi metodi sono sempre etichettati molto chiaramente; iniziano con le parole Begine End. Come in Stream.BeginRead, Socket.BeginConnect, WebRequest.BeginGetResponse, e così via.

Questi metodi fanno utilizzare la ThreadPool, ma usano IOCPs, che non non interferiscono con le richieste ASP.NET. Sono un tipo speciale di thread leggero che può essere "svegliato" da un segnale di interruzione dal sistema I / O. E in un'applicazione ASP.NET, normalmente hai un thread I / O per ogni thread di lavoro, quindi ogni singola richiesta può avere un'operazione asincrona accodata. Sono letteralmente centinaia di operazioni asincrone senza alcun calo significativo delle prestazioni (supponendo che il sottosistema di I / O possa tenere il passo). È molto più di quanto avrai mai bisogno.

Tieni presente che i delegati asincroni non funzionano in questo modo: finiranno per utilizzare un thread di lavoro, proprio come ThreadPool.QueueUserWorkItem. Sono solo i metodi asincroni incorporati delle classi della libreria .NET Framework che sono in grado di farlo. Puoi farlo da solo, ma è complicato e un po 'pericoloso e probabilmente oltre lo scopo di questa discussione.

La migliore risposta a questa domanda, a mio parere, è non utilizzare ThreadPool oThread un'istanza in background in ASP.NET . Non è affatto come avviare un thread in un'applicazione Windows Form, dove lo fai per mantenere reattiva l'interfaccia utente e non ti interessa quanto sia efficiente. In ASP.NET, la tua preoccupazione è la velocità effettiva e tutto quel contesto che passa su tutti quei thread di lavoro ucciderà assolutamente la velocità effettiva, indipendentemente dal fatto che utilizzi ThreadPoolo meno.

Per favore, se ti ritrovi a scrivere codice di threading in ASP.NET, considera se potrebbe essere riscritto o meno per utilizzare metodi asincroni preesistenti e, se non è possibile, considera se hai davvero bisogno del codice per essere eseguito in un thread in background. Nella maggior parte dei casi, probabilmente aggiungerai complessità senza alcun vantaggio netto.

Secondo Thomas Marquadt del team ASP.NET di Microsoft, è sicuro utilizzare ASP.NET ThreadPool (QueueUserWorkItem).

Dall'articolo :

D) Se la mia applicazione ASP.NET utilizza thread CLR ThreadPool, non morirò di fame ASP.NET, che utilizza anche CLR ThreadPool per eseguire le richieste? ..

A) Per riassumere, non preoccuparti di far morire di fame ASP.NET di thread, e se pensi che ci sia un problema qui fammelo sapere e ci penseremo noi.

D) Devo creare i miei thread (nuovo thread)? Non sarà migliore per ASP.NET, poiché utilizza CLR ThreadPool.

A) Per favore non farlo. O per dirla in modo diverso, no !!! Se sei davvero intelligente, molto più intelligente di me, puoi creare i tuoi fili; altrimenti, non pensarci nemmeno. Ecco alcuni motivi per cui non dovresti creare frequentemente nuovi thread:

1. È molto costoso, rispetto a QueueUserWorkItem ... A proposito, se riesci a scrivere un ThreadPool migliore di CLR, ti incoraggio a candidarti per un lavoro in Microsoft, perché stiamo sicuramente cercando persone come te !.

I siti web non dovrebbero andare in giro a generare thread.

Di solito sposti questa funzionalità in un servizio Windows con cui comunichi (io uso MSMQ per parlare con loro).

-- Modificare

Ho descritto un'implementazione qui: Elaborazione in background basata su code nell'applicazione Web ASP.NET MVC

-- Modificare

Per espandere il motivo per cui questo è anche meglio dei semplici thread:

Utilizzando MSMQ, puoi comunicare con un altro server. È possibile scrivere in una coda su più macchine, quindi se si determina, per qualche motivo, che l'attività in background sta utilizzando troppo le risorse del server principale, è possibile spostarla in modo abbastanza banale.

Ti consente anche di elaborare in batch qualsiasi attività stavi cercando di fare (inviare e-mail / qualsiasi cosa).

Sono assolutamente convinto che la pratica generale per un lavoro asincrono rapido e a bassa priorità in ASP.NET sarebbe quella di utilizzare il pool di thread .NET, in particolare per scenari ad alto traffico poiché si desidera che le risorse siano limitate.

Inoltre, l'implementazione del threading è nascosta: se inizi a generare i tuoi thread, devi gestirli correttamente. Non sto dicendo che non potresti farlo, ma perché reinventare quella ruota?

Se le prestazioni diventano un problema ed è possibile stabilire che il pool di thread è il fattore limitante (e non le connessioni al database, le connessioni di rete in uscita, la memoria, i timeout di pagina ecc.), Si modifica la configurazione del pool di thread per consentire più thread di lavoro, richieste in coda più elevate , eccetera.

Se non si hanno problemi di prestazioni, la scelta di generare nuovi thread per ridurre i conflitti con la coda di richieste ASP.NET è un'ottimizzazione prematura classica.

Idealmente non sarebbe necessario utilizzare un thread separato per eseguire un'operazione di registrazione, ma è sufficiente abilitare il thread originale per completare l'operazione il più rapidamente possibile, ed è qui che entrano in gioco MSMQ e un thread / processo consumer separato. Sono d'accordo che questo è più pesante e richiede più lavoro da implementare, ma qui hai davvero bisogno della durabilità: la volatilità di una coda condivisa in memoria esaurirà rapidamente il suo benvenuto.

Dovresti usare QueueUserWorkItem ed evitare di creare nuovi thread come faresti per evitare la piaga. Per un'immagine che spiega perché non morirai di fame ASP.NET, poiché utilizza lo stesso ThreadPool, immagina un giocoliere molto abile che usa due mani per tenere in volo una mezza dozzina di birilli, spade o qualsiasi altra cosa. Per una visuale del motivo per cui creare i propri thread non è corretto, immagina cosa succede a Seattle nelle ore di punta quando le rampe di accesso all'autostrada molto utilizzate consentono ai veicoli di entrare immediatamente nel traffico invece di usare una luce e limitare il numero di ingressi a uno ogni pochi secondi . Infine, per una spiegazione dettagliata, consultare questo collegamento:

http://blogs.msdn.com/tmarq/archive/2010/04/14/performing-asynchronous-work-or-tasks-in-asp-net-applications.aspx

Grazie, Thomas

L'articolo non è corretto. ASP.NET dispone del proprio pool di thread, thread di lavoro gestiti, per servire le richieste ASP.NET. Questo pool è in genere composto da poche centinaia di thread ed è separato dal pool ThreadPool, che è un multiplo più piccolo di processori.

L'utilizzo di ThreadPool in ASP.NET non interferirà con i thread di lavoro ASP.NET. Usare ThreadPool va bene.

Sarebbe anche accettabile impostare un singolo thread che è solo per la registrazione dei messaggi e l'utilizzo del modello produttore / consumatore per passare i messaggi di log a quel thread. In tal caso, poiché il thread è di lunga durata, è necessario creare un unico nuovo thread per eseguire la registrazione.

Usare un nuovo thread per ogni messaggio è decisamente eccessivo.

Un'altra alternativa, se stai parlando solo di logging, è usare una libreria come log4net. Gestisce la registrazione in un thread separato e si prende cura di tutti i problemi di contesto che potrebbero sorgere in quello scenario.

Direi che l'articolo è sbagliato. Se gestisci un grande negozio .NET, puoi utilizzare in sicurezza il pool su più app e più siti Web (utilizzando pool di app separati), semplicemente in base a un'istruzione nella documentazione di ThreadPool :

C'è un pool di thread per processo. Il pool di thread ha una dimensione predefinita di 250 thread di lavoro per processore disponibile e 1000 thread di completamento I / O. Il numero di thread nel pool di thread può essere modificato utilizzando il metodo SetMaxThreads. Ogni thread utilizza la dimensione dello stack predefinita e viene eseguito con la priorità predefinita.

Mi è stata posta una domanda simile al lavoro la scorsa settimana e ti darò la stessa risposta. Perché utilizzi applicazioni web multi-threading per richiesta? Un server web è un sistema fantastico ottimizzato pesantemente per fornire molte richieste in modo tempestivo (cioè multi threading). Pensa a cosa succede quando richiedi quasi tutte le pagine del Web.

1. Viene richiesta per qualche pagina
2. Html viene restituito
3. L'Html dice al cliente di fare ulteriori richieste (js, css, immagini, ecc ..)
4. Ulteriori informazioni vengono fornite

Fornisci l'esempio della registrazione remota, ma questa dovrebbe essere una preoccupazione del tuo logger. Dovrebbe essere in atto un processo asincrono per ricevere i messaggi in modo tempestivo. Sam sottolinea anche che il tuo logger (log4net) dovrebbe già supportare questo.

Sam ha anche ragione in quanto l'utilizzo del pool di thread su CLR non causerà problemi con il pool di thread in IIS. La cosa di cui preoccuparsi qui, però, è che non stai generando thread da un processo, stai generando nuovi thread dai thread del pool di thread di IIS. C'è una differenza e la distinzione è importante.

Discussioni vs processo

Sia i thread che i processi sono metodi per parallelizzare un'applicazione. Tuttavia, i processi sono unità di esecuzione indipendenti che contengono le proprie informazioni di stato, utilizzano i propri spazi di indirizzi e interagiscono tra loro solo tramite meccanismi di comunicazione tra processi (generalmente gestiti dal sistema operativo). Le applicazioni sono in genere suddivise in processi durante la fase di progettazione e un processo master genera esplicitamente sottoprocessi quando ha senso separare logicamente funzionalità significative dell'applicazione. I processi, in altre parole, sono un costrutto architettonico.

Al contrario, un thread è un costrutto di codifica che non influisce sull'architettura di un'applicazione. Un singolo processo potrebbe contenere più thread; tutti i thread all'interno di un processo condividono lo stesso stato e lo stesso spazio di memoria e possono comunicare tra loro direttamente, perché condividono le stesse variabili.

fonte

Non sono d'accordo con l'articolo di riferimento (C # feeds.com). È facile creare un nuovo thread ma pericoloso. Il numero ottimale di thread attivi da eseguire su un singolo core è in realtà sorprendentemente basso - meno di 10. È troppo facile far perdere tempo alla macchina nel cambiare thread se vengono creati thread per attività minori. I thread sono una risorsa che RICHIEDE la gestione. L'astrazione WorkItem è lì per gestire questo.

C'è un compromesso tra la riduzione del numero di thread disponibili per le richieste e la creazione di troppi thread per consentire a nessuno di essi di elaborare in modo efficiente. Questa è una situazione molto dinamica, ma penso che dovrebbe essere gestita attivamente (in questo caso dal pool di thread) piuttosto che lasciare che sia il processore a stare al passo con la creazione dei thread.

Infine l'articolo fa alcune affermazioni piuttosto radicali sui pericoli dell'uso di ThreadPool, ma ha davvero bisogno di qualcosa di concreto per sostenerle.

Indipendentemente dal fatto che IIS utilizzi o meno lo stesso ThreadPool per gestire le richieste in arrivo, sembra difficile ottenere una risposta definitiva e sembra anche essere cambiato rispetto alle versioni. Quindi sembrerebbe una buona idea non utilizzare i thread ThreadPool in modo eccessivo, in modo che IIS ne abbia molti disponibili. D'altra parte, generare il proprio thread per ogni piccola attività sembra una cattiva idea. Presumibilmente, hai una sorta di blocco nella registrazione, quindi solo un thread potrebbe progredire alla volta, e il resto farebbe a turno per essere pianificato e non programmato (per non parlare del sovraccarico di generare un nuovo thread). In sostanza, ti imbatti nei problemi esatti che ThreadPool è stato progettato per evitare.

Sembra che un compromesso ragionevole sarebbe che la tua app allochi un singolo thread di registrazione a cui potresti passare i messaggi. Dovresti fare attenzione che l'invio di messaggi sia il più veloce possibile in modo da non rallentare la tua app.

È possibile utilizzare Parallel.For o Parallel.ForEach e definire il limite di possibili thread che si desidera allocare per eseguire senza problemi e prevenire la fame del pool.

Tuttavia, essendo eseguito in background, sarà necessario utilizzare lo stile TPL puro di seguito nell'applicazione Web ASP.Net.

var ts = new CancellationTokenSource();
CancellationToken ct = ts.Token;

ParallelOptions po = new ParallelOptions();
            po.CancellationToken = ts.Token;
            po.MaxDegreeOfParallelism = 6; //limit here

 Task.Factory.StartNew(()=>
                {                        
                  Parallel.ForEach(collectionList, po, (collectionItem) =>
                  {
                     //Code Here PostLog(logEvent);
                  }
                });