Processo in background con esecuzione prolungata in ASP.NET - Application_Start o processo separato?

Question

Sto sviluppando un'applicazione .NET 4 che richiede l'esecuzione di un thread di lavoro di backend. Questo thread è costituito in gran parte del seguente codice:

while (true) { 
    //Check stuff in database 
    //Do stuff 
    //write to database/filesystem 
    Thread.sleep(60000) 
} 

L'ASP.NET applicazione è solo un frontend per il database.

La mia domanda è intorno a dove sarebbe il posto migliore per mettere questo ciclo di lavoro. Sembra che le mie due scelte immediate siano (1) per estrarlo dal metodo Application_Start e lasciarlo funzionare, o (2) raggrupparlo in un processo separato (servizio Windows?)

(1) ovviamente è necessario un po 'di logica nel codice ASP.NET per verificare che sia ancora in esecuzione, poiché IIS potrebbe ucciderlo. È anche abbastanza chiaro che l'intera logica dell'applicazione si trova in un unico pacchetto facilmente distribuibile. (2) è molto più segregato, ma si sente molto più confuso.

Qual è l'approccio migliore?

Answer 1

Vorrei fortemente optare per il servizio di Windows, se possibile. Threading in background in ASP.NET comes with a lot of baggage.

1. La durata del processo in background è in balia di IIS. Se IIS decide il proprio tempo per riciclare il pool di app, il processo in background verrà riavviato. Se IIS decide di interrompere il pool di app a causa di inattività, il processo in background non verrà eseguito.
2. Se IIS è configurato per essere eseguito come un giardino Web (più processi per AppPool), il thread in background potrebbe essere eseguito più di una volta.
3. In seguito, se si decide di bilanciare il carico del sito Web (più server che eseguono il sito), potrebbe essere necessario modificare l'applicazione per garantire che il threading in background avvenga solo su un server).

E molto altro.

Answer 2

Considerare qualcosa di semplice come Hangfire e quindi pensare a the design points in this related answer.