ThreadPools vs Own Threads para procesos de larga ejecución

Question

Tenemos algunos procesos comerciales de larga ejecución que se inician a través de Servicios WCF que se ejecutan en IIS (modo integrado) en WS 2008 R2. Estos procesos comerciales suelen implicar mucha interacción con nuestro servidor SQL Server. Hemos creado una implementación de cola de tareas personalizada mediante la cual las solicitudes se ponen en cola a través de una llamada de servicio inicial y luego se ejecutan según la prioridad. Esta ejecución puede tardar en completarse (20-30 minutos en extremo). Los clientes pueden consultar el servidor para el progreso de sus propias tareas en segundo plano.

En nuestra implementación actual, las tareas se activan en un subproceso independiente para ejecutar y no desde el ThreadPool. Esto se realizó debido a reading recommendations de no ejecutar tareas de ejecución prolongada utilizando ThreadPool para evitar que las peticiones de ASP.NET se agotaran. Controlamos la cantidad de subprocesos generados al colocar un límite superior en la cantidad de tareas en segundo plano que se pueden ejecutar al mismo tiempo. De esta forma tratamos de controlar la carga en la CPU y evitar demasiada conmutación de contexto de hilo. Mientras todo esto sucede, por supuesto, todavía necesitamos atender las solicitudes "en línea" normales para la aplicación también.

Después de leer this post por Thomas Marquardt Me preocupa el hecho de que no estamos utilizando el ThreadPool ya que no obtendremos el beneficio de la heurística de ajuste incorporada en él. Ya solucionamos el problema de cierre que menciona Thomas conectándose al evento ApplicationEnd y cancelando las tareas de ejecución prolongada. Entonces mi pregunta es, ¿deberíamos cambiar al uso de ThreadPool? ¿Qué hay de estos hilos atados por largos períodos de tiempo? Si entiendo a Thomas correctamente, él está diciendo que esto no importa ya que el ThreadPool se sintonizará para crear más solicitudes para atender las operaciones normales en línea. También he leído this StackOverflow question que cubre los mismos motivos, pero todavía no estoy seguro del camino a seguir.

Answer 1

Esto no es exactamente lo que has preguntado, pero ¿por qué no ejecutar tus tareas largas en un proceso separado (por ejemplo, servicio de Windows)? De todos modos estás construyendo una cola de prioridad y los clientes van a consultar para obtener resultados. tiempo despues. Me habría ido con este enfoque en el que los servicios WCF que miran hacia el frente ponen en cola las solicitudes y responden a las consultas de actualización de estado, mientras que el servicio en segundo plano mantendría las solicitudes de servicio. Esto incluso permitiría que el proceso de trabajo se recicla, etc. sin preocuparse por la terminación de las tareas de ejecución actuales. El único problema que veo es la sobrecarga de la comunicación fuera del proceso, pero luego debería ser insignificante en comparación con el tiempo empleado por la tarea (ya que están funcionando por mucho tiempo).

Answer 2

Mi sugerencia es evitar el ThreadPool ya que estoy teniendo exactamente los problemas de falta de hilo sugeridos en los enlaces que ha proporcionado.

Nuestro producto permite al usuario despedir una llamada a un servicio web que lleva a cabo una serie de presupuestos. Este puede ser un proceso de larga duración de hasta 40 minutos, el proceso de presupuesto es intensivo en la CPU, por lo tanto, usamos el grupo de subprocesos en nuestro servidor de núcleo cuádruple para obtener el máximo uso de la CPU.

Sin embargo, como parece que ASP.NET utiliza el grupo de subprocesos para atender solicitudes, tenemos un problema por el cual las nuevas tareas enviadas por los usuarios nunca comienzan hasta que se completa el primer trabajo debido a la falta de subprocesos disponibles en el piscina. Para evitar esto he estado usando una clase que encontré en la web hace un tiempo llamada ThreadPoolThrottle. Esto ha mitigado un poco los problemas, pero a medida que crece el uso del sistema, nos encontramos con los mismos problemas.

Ahora estoy considerando la sugerencia de VinayC de ejecutar las cotizaciones fuera de proceso para evitar la falta de hilo en mi aplicación asp.net.