CPU, utilizzo della memoria, utilizzo del pool di thread - ASP NET core Identità non confermata dagli utenti di posta che eliminano la gestione - Nell'app o nell'app separata?

Question

Mi chiedo quale sia la soluzione più adatta. Ho bisogno di implementare un robot per il controllo e l'eliminazione degli utenti registrati non confermati per esempio per 7 giorni dopo l'invio della mail di conferma. (Se un utente non conferma il proprio account, voglio eliminare l'utente dal database). Ho pensato a 3 modi:

1. implementare direttamente un delegato nell'app ASP NET core ed eseguirlo come attività asincrona in un ciclo con una sospensione di 24 ore.
2. crea un'app console che verrà eseguita in loop con una sospensione di 24 ore
3. creare un'app console che verrà avviata regolarmente da un software di terze parti (ad esempio Cron o TaskScheduler)

Quale di questi modi avrà il minor impatto sull'utilizzo della CPU e della memoria?
Anche il pool di thread ha una quantità limitata da prendere, più robot, meno thread per le persone che cercano di accedere al mio sito ASP net, ho ragione?
E la mia ultima domanda> è una buona idea Thread.Sleep per così tanto tempo? Qualcosa mi dice che in realtà non lo è. D'altra parte è un ASP che funzionerà per mesi forse anni.

Ad ogni modo, adoro l'idea di avere tutto in un'unica app (può essere configurata all'interno di un file e tutto si avvia in una volta). D'altra parte qualcosa mi dice che non è una grande idea.

Answer 1

Quando l'attività è effettivamente in esecuzione, mi aspetto che l'utilizzo della memoria e del processo sia dominato da tutto ciò che è richiesto per l'attività e dovrebbe essere confrontabile per ciascun metodo. Quindi dovrebbe essere più interessante vedere l'utilizzo delle risorse quando non è in esecuzione.

1. In corso, utilizzando un timer (o un await Task.Delay(..)loop)

Ciò richiederebbe solo memoria per il timer o la macchina a stati asincrona e memoria aggiuntiva per il codice. Questo dovrebbe essere abbastanza piccolo, forse pochi kilobyte. Nessun tempo del processore e nessun thread verrebbe utilizzato durante l'inattività. Ciò presuppone che tu non mantenga alcuna struttura di dati di grandi dimensioni.

1. In un processo di console persistente separato

Ciò utilizzerebbe alcuni MB di memoria per il runtime .Net e memoria aggiuntiva per codice e dati. In pratica mi aspetterei che la memoria venga paginata su disco se il computer esaurisce la memoria. Nessun tempo del processore verrebbe utilizzato durante l'inattività.

1. In un processo di console pianificato separato

Ciò consumerebbe solo memoria per l'oggetto scheduler e questo dovrebbe essere minimo. Ovviamente nessun tempo o thread del processore verrebbe utilizzato durante l'inattività.

Riepilogo

la pianificazione di un processo separato utilizzerebbe meno risorse. Ma tutti i metodi dovrebbero utilizzare una quantità di risorse abbastanza insignificante mentre sono inattivi. Quindi direi che la scelta dovrebbe essere fatta su altri criteri, come ciò che è più facile da mantenere e/o implementare.

Il pool di thread allocherà più thread se necessario. I thread in generale dovrebbero essere usati solo quando stanno effettivamente facendo qualcosa (cioè use await taskinvece di task.Wait()), e avrai molti più thread pool di thread di quanti ne avresti thread hardware. Sarei preoccupato per questo solo se osservassi un numero di thread molto più elevato del solito.

Eviterei Thread.Sleepse possibile. Un timer o await Task.Delaydi solito sarebbe più appropriato.