multi-threading di un'applicazione web

Question

So che ci sono molti casi in cui è meglio multi-thread un'applicazione, ma quando è meglio multi thread un'applicazione web .net?

Answer 1

Un'applicazione Web è quasi sicuramente già multi-threaded dall'ambiente di hosting (IIS ecc.). Se la tua pagina è vincolata alla CPU (e vuoi usare più core), probabilmente molti thread sono una cattiva idea, come quando il tuo sistema è sotto carico li stai già utilizzando.

L'ora potrebbe essere l'aiuto è quando si è vincolati all'IO; ad esempio, hai una pagina web che deve parlare con 3 servizi web esterni, parlare con un database e scrivere un file (tutto non correlato). Puoi farlo in parallelo su diversi thread (idealmente usando le operazioni asincrone incorporate, per massimizzare l'utilizzo della porta di completamento) per ridurre il tempo di elaborazione complessivo - tutto senza incidere troppo sulla CPU locale (qui il vero ritardo è sulla rete).

Naturalmente, in questi casi è possibile anche fare meglio accodando semplicemente il lavoro nell'applicazione Web e avendo un servizio di riaccredito separato ed elaborandoli, ma in tal caso non è possibile fornire una risposta immediata al chiamante (essi Dovrei controllare più tardi per verificare il completamento, ecc.).

Answer 2

Per beneficiare del multithreading, l'applicazione deve eseguire una quantità significativa di lavoro che può essere eseguita in parallelo. Se questo non è il caso, il sovraccarico del multithreading può benissimo superare i benefici.

Nella mia esperienza la maggior parte delle applicazioni web consiste in una serie di metodi di esecuzione brevi, quindi, a parte il parallelismo già offerto dall'ambiente di hosting, direi che è raro beneficiare del multithreading all'interno delle singole parti di un'applicazione web . Ci sono probabilmente esempi in cui offrirà un vantaggio, ma la mia ipotesi è che non sia molto comune.

Answer 3

IMHO si dovrebbe evitare l'uso di multithread in un'applicazione web based.

forse un'applicazione multithread potrebbe aumentare le prestazioni in un'app standard (con il giusto design), ma in un'applicazione web si consiglia di mantenere un throughput elevato anziché la velocità.

, ma se si dispone di una connessione simultanea alcuni forse è possibile utilizzare filo parallelo senza un degrado delle prestazioni globali

Answer 4

ASP.NET è già in grado di deposizione delle uova più thread per l'elaborazione di diverse richieste in parallelo, in modo da per una semplice elaborazione richiesta c'è è raramente un caso in cui è necessario generare manualmente un altro thread. Tuttavia, ci sono alcuni scenari comuni che ho incontrato che avevano giustificato la creazione di un altro thread:

• Se c'è qualche operazione che potrebbe richiedere un po 'e può essere eseguito in parallelo con il resto della elaborazione della pagina, potresti generare un thread secondario lì. Ad esempio, se c'era un servizio web che dovevi eseguire il polling come risultato della richiesta, potresti generare un altro thread in Page_Init e controllare i risultati in Page_PreRender (in attesa se necessario). Anche se è ancora una questione se questo potrebbe essere un vantaggio in termini di prestazioni o meno, generare un thread non è economico e il tempo tra un Page_Init e Page_Prerender tipico è misurato in millisecondi comunque. Mantenere un pool di thread per questo potrebbe essere un po 'più efficiente, e ASP.NET ha anche qualcosa chiamato "pagine asincrone" che potrebbe essere ancora più adatto per questa esigenza.
• Se esiste un pool di risorse che si desidera pulire periodicamente. Ad esempio, immagina di utilizzare qualche strano DBMS fornito con associazioni .NET limitate, ma non esiste un supporto per il pooling (questo era il mio caso).In tal caso, potresti voler implementare il pool di connessioni DB da solo, e ciò richiederebbe un "thread più pulito" che si attivi, diciamo, una volta al minuto e controlla se ci sono connessioni che non sono state utilizzate per molto tempo (e quindi può essere chiuso).

Un'altra cosa da tenere a mente quando si implementano i propri thread in ASP.NET - A ASP.NET piace uccidere i suoi processi se sono stati inattivi per un po '. Quindi non dovresti fare affidamento sul tuo filo rimanendo vivo per sempre. Potrebbe essere terminato in qualsiasi momento e sarà meglio essere pronti per questo.

Answer 5

Il multithreading è una tecnica per fornire un singolo processo con più tempo di elaborazione per consentirne l'esecuzione più rapida. Ha più thread quindi mangia più cicli della CPU. (Da più CPU, se ne hai.) Per un'applicazione desktop, questo ha molto senso. Ma concedere più cicli di CPU a un utente Web porterebbe via gli stessi cicli dai 99 altri utenti che stanno facendo richieste allo stesso tempo! Quindi tecnicamente, è una brutta cosa.

Tuttavia, un'applicazione Web potrebbe utilizzare altri servizi e processi che utilizzano più thread. I database, ad esempio, non creeranno un thread separato per ogni utente che si connette a loro. Limitano il numero di thread a pochi, aggiungendo connessioni a un pool di connessioni per un utilizzo più veloce. Finché ci sono connessioni disponibili o in pool, l'utente avrà accesso al database. Quando il database esaurisce le connessioni, l'utente dovrà attendere.

Quindi, in sostanza, l'utilizzo di più thread potrebbe essere utilizzato per le applicazioni Web per ridurre il numero di utenti attivi in ​​un momento specifico! Consente al sistema di condividere risorse con più utenti senza sovraccaricare la risorsa. Invece, gli utenti dovranno semplicemente mettersi in fila prima che sia il loro turno.

Questo non sarebbe multi-threading nella stessa applicazione Web, ma multi-threading in un servizio che viene consumato dall'applicazione web. In questo caso, viene utilizzato come limitazione consentendo solo una piccola quantità di thread di essere attivi.