CPU, uso de memoria, uso de grupo de subprocesos: ASP NET core Identidad no confirmada. Los usuarios de correo eliminan el manejo: ¿en la aplicación o en una aplicación separada?

Aug 19 2020

Me pregunto cuál es la solución más adecuada. Necesito implementar un robot para verificar y eliminar usuarios registrados no confirmados, por ejemplo, 7 días después de que se envió el correo de confirmación. (Si un usuario no confirma su cuenta, quiero eliminar al usuario de la base de datos). Pensé en 3 formas:

  1. implemente un delegado en la aplicación principal de ASP NET directamente y ejecútelo como una tarea asíncrona en un bucle con una suspensión de 24 horas.
  2. cree una aplicación de consola que se ejecutará en bucle con una suspensión de 24 horas
  3. crear una aplicación de consola que un software de terceros iniciará regularmente (por ejemplo, Cron o TaskScheduler)

¿Cuál de estas formas tendrá el menor impacto en el uso de CPU y memoria?
Además, el grupo de subprocesos tiene una cantidad limitada para tomar, cuantos más robots, menos subprocesos para las personas que intentan acceder a mi sitio de red ASP, ¿estoy en lo cierto?
Y mi última pregunta > ¿es una buena idea Thread.Sleep durante tanto tiempo? Algo me dice que realmente no lo es. Por otro lado, es un ASP que estará funcionando durante meses, tal vez años.

De todos modos, me encanta la visión de tener todo en una sola aplicación (se puede configurar dentro de un archivo y todo comienza a la vez). Por otro lado, algo me dice que no es una gran idea.

Respuestas

2 JonasH Aug 21 2020 at 18:48

Cuando la tarea se está ejecutando, esperaría que el uso de la memoria y el proceso esté dominado por lo que se requiera para la tarea, y debería ser comparable para cada método. Por lo tanto, debería ser más interesante ver el uso de recursos cuando no se está ejecutando.

  1. En proceso, usando un temporizador (o un await Task.Delay(..)bucle)

Esto solo requeriría memoria para el temporizador o la máquina de estado asíncrona, y algo de memoria adicional para el código. Esto debería ser bastante pequeño, quizás unos pocos kilobytes. No se utilizaría tiempo de procesador ni subprocesos mientras estuviera inactivo. Esto supone que no se aferra a ninguna estructura de datos de gran tamaño.

  1. En un proceso de consola persistente independiente

Esto usaría unos pocos MB de memoria para el tiempo de ejecución de .Net y algo de memoria adicional para el código y los datos. En la práctica, esperaría que la memoria se paginara en el disco si la computadora se queda sin memoria. No se usaría tiempo de procesador mientras está inactivo.

  1. En un proceso de consola programado separado

Esto solo consumiría memoria para el objeto del programador y debería ser mínimo. Obviamente, no se usaría tiempo de procesador ni subprocesos mientras está inactivo.

Resumen

programar un proceso separado usaría la menor cantidad de recursos. Pero todos los métodos deberían usar una cantidad de recursos bastante insignificante mientras están inactivos. Por lo tanto, diría que la elección debe hacerse según otros criterios, como lo que es más fácil de mantener y/o implementar.

El grupo de subprocesos asignará más subprocesos si es necesario. En general, los subprocesos solo deben usarse cuando realmente están haciendo algo (es decir, usar await tasken lugar de task.Wait()), y tendrá muchos más subprocesos de grupo de subprocesos de los que tendría subprocesos de hardware. Solo me preocuparía por esto si observara un número mucho mayor de subprocesos de lo habitual.

Yo evitaría Thread.Sleepsi es posible. Un temporizador o await Task.Delaypor lo general sería más apropiado.