2008-09-08 9 views
8

¿Qué tipo de problemas de subprocesos múltiples hay que tener cuidado en asp.net?Multithreading en asp.net

+0

+1 Buena pregunta – Nick

+0

El blog definitivo sobre problemas (aunque anticuado) es Phil Haacks http://haacked.com/archive/2011/10/16/the-dangers-of-implementing-recurring-background-tasks- in-asp-net.aspx/Hay muchos marcos para ejecutar procesos en segundo plano como Quartz.NET y HangFire. Si puedes vivir con una restricción de 90 segundos, incluso puedes usar QueueBackgroundWorkItem. Si tiene Azure, Web Jobs o servicios en la nube. – RickAndMSFT

Respuesta

0

Caché programático es un área que se me ocurre de inmediato. Es una gran característica que debe usarse con cuidado. Dado que se comparte entre solicitudes, debe colocar bloqueos antes de actualizarlo.

Otro lugar que verificaría es cualquier código que acceda al sistema de archivos, como escribir en archivos de registro. Si una solicitud tiene un bloqueo de lectura/escritura en un archivo, otras solicitudes concurrentes generarán un error si no se manejan adecuadamente.

6

Una cosa a tener en cuenta en las cosas que caducan (creo que httpContext), si lo está utilizando para operaciones que son "fuego y olvidar" recuerde que de repente si el código de limpieza asp.net se ejecuta antes su operación está hecha, no podrá acceder a cierta información.

2

Si esto es para un servicio web, definitivamente debe considerar la agrupación de subprocesos. Demasiados hilos llevarán a su aplicación a un alto debido a que eventualmente comenzarán a competir por el tiempo de CPU.

¿Esto es para IO de archivos o redes? Si es así, también debería considerar usar asynchronous IO. Puede ser un poco más difícil programarlo, pero no tiene que preocuparse por generar demasiados hilos a la vez.

9

Es arriesgado generar hilos del código subyacente de una página ASP.NET, porque el proceso de trabajo se reciclará ocasionalmente y su hilo morirá.

Si necesita iniciar procesos de larga ejecución como resultado de las acciones de los usuarios en las páginas web, su mejor opción es dejar un mensaje en MSMQ y tener un segundo plano de servicio que supervise la cola. El servicio podría tomar todo el tiempo que quiera para llevar a cabo la tarea, y la página web se terminaría con su trabajo casi de inmediato. Puede lograr lo mismo con una llamada de asincronización a un método web, pero no confíe en obtener la respuesta cuando el método web haya terminado de funcionar. Desde el código subyacente, tiene que ser un fuego rápido y olvídate.

+1

Pareces estar defendiendo esta técnica en múltiples preguntas en StackOverflow, y creo que es el camino a seguir para un proceso de larga ejecución como, por ejemplo, el proceso de facturación. ¿Hay algún código de muestra que pueda compartir? o una palabra clave a binged? – Salamander2007

+1

Existen muchos marcos para ejecutar procesos en segundo plano que son mucho más fáciles de usar que implementar todo esto con MSMQ. Por ejemplo, • Quartz.NET y HangFire. Si puedes vivir con una restricción de 90 segundos, incluso puedes usar QueueBackgroundWorkItem. Si tiene Azure, Web Jobs o servicios en la nube. – RickAndMSFT

0

¿No hay un límite de 25 subprocesos totales en la configuración de IIS? Al menos en IIS 6, creo. Si excede ese límite, pueden suceder cosas interesantes (léase: tiempos de respuesta loooooooong).

0

Dependiendo de lo que necesite, en lo que respecta al multi-threading, ¿ha pensado en las solicitudes de desove del cliente? Es seguro generar solicitudes utilizando AJAX, y luego actuar sobre los resultados en una devolución de llamada. O use un servicio como mecanismo de fondo, que se ejecuta cada X minutos y procesa en segundo plano de esa manera.