Estamos lidiando con un problema interesante en StackOverflow.
Tenemos un montón de pequeñas tareas "que deben hacerse pronto-ish". Un ejemplo es actualizar las listas de "Preguntas relacionadas". Lo que hemos hecho en el pasado es combinar esas tareas en las cargas de la página de algunos usuarios.
Esto nunca fue ideal, pero no fue realmente notable. Ahora que SO ha superado el signo de interrogación de 1,000,000, esos usuarios desafortunados están empezando a sentirlo.
La solución natural es llevar estas tareas a un segundo plano. Estoy considerando dos formas generales de hacer esto.
1. En IIS como un grupo de subprocesos / cola de trabajo personalizados
Básicamente, giramos algunos (no- ThreadPool , por lo que para no interferir con los subprocesos de IIS) y hacer que los servicios de algunas colecciones que estamos metiendo Funcs en .
El gran profesional aquí es la simplicidad. No tenemos que preocuparnos por calcular nada, ni debemos asegurarnos de que algún servicio externo esté funcionando y respondiendo.
También obtenemos acceso a todos nuestros códigos comunes.
La estafa es, bueno, que no deberíamos usar hilos de fondo. Las objeciones que conozco se centran en IIS hambriento (si usas ThreadPool) y los hilos mueren al azar (debido al reciclaje de AppPool).
Tenemos una infraestructura existente para hacer que la muerte del hilo aleatorio no sea un problema (es posible que se haya abandonado una tarea, básicamente, se ha abandonado), y no se limita el número de hilos (y el uso de hilos que no son de ThreadPool) difícil tampoco.
Movido a StackOverflow , ya que realmente no se abordó aquí.
2. Como servicio
Una solución de terceros o una personalizada.
Básicamente, asignamos una tarea a través de los límites del proceso a algún servicio y simplemente lo olvidamos. Es de suponer que estamos vinculando algún código o restringido a una cadena de conexión de SQL + sin formato.
El profesional es que es la "manera correcta" de hacer esto.
Las desventajas son que estamos muy restringidos en lo que podemos hacer, o tendremos que encontrar algún sistema para mantener este servicio sincronizado con nuestro código base. También necesitaremos conectar todo nuestro monitoreo y registro de errores de alguna manera, lo que obtenemos de forma gratuita con la opción "En IIS".
¿Hay otros beneficios o problemas con el enfoque de servicio?
En pocas palabras, ¿hay problemas imprevistos e insuperables que hacen que el enfoque # 1 no sea viable y, en caso afirmativo, hay algún servicio de terceros que debamos buscar para el enfoque # 2?