¿Tiene sentido multiproceso en asp.net?

Question

En el desarrollo de winforms, puede crear un BackgroundWorker para evitar bloquear la IU en un proceso prolongado. En ASP.NET, un POST/GET básicamente se congela hasta su finalización. No veo cómo agregar un Thread sería beneficioso para este proceso. Tal vez si el Thread se acelerara (por ejemplo, en un servidor multi-core) podría ayudar a acelerar las cosas.

En el sentido general, podría usar AJAX para hacer llamadas largas sin causar una "congelación" de la página web. En este sentido, AJAX puede considerarse un sustituto del enhebrado.

¿Eso es todo? ¿Enlazar es bastante inútil en ASP.NET?

Answer 1

multihilo puede hacer peticiones más rápido si:

1. El trabajo de cada solicitud Web se puede dividir en múltiples tareas que se pueden ejecutar en paralelo
2. Cada una de estas tareas es muy intensivo de la CPU (CPU bound), o tener varias tareas vinculadas de E/S en diferentes rutas de E/S (ver comentarios)
3. Puede implementarlas usando fork/join parallelism.

En ese caso, puede utilizar multihebra en ASP.NET. Un error común que cometen las personas es generar hilos y luego no esperar a que se completen, por ejemplo, "voy a responder al usuario al registrar su compra en la base de datos en un hilo de fondo. Esto siempre es una mala idea, porque IIS puede y va a reciclar el grupo de aplicaciones en el que se está ejecutando su sitio web, y esos hilos de fondo pueden cancelarse silenciosamente.

Answer 2

El subprocesamiento puede ser útil en la programación del lado del servidor si necesita devolver una respuesta y no desea atar la cadena del servidor, en particular para procesos de larga ejecución que causarían que la solicitud expirara.

Answer 3

Un subproceso se puede usar para acciones que duran más tiempo que la duración de la solicitud de página, por lo que sí, tiene sentido.

Un ejemplo sería un hilo que hace girar un proceso para codificar video. Como esto puede llevar algo de tiempo, el cliente puede actualizarse más tarde con el progreso de la codificación a través de AJAX o Comet, o cualquier otro número de mecanismos.

Answer 4

Depende de la carga de trabajo y el caso de uso. Los sistemas de Solicitud/Respuesta se sirven mejor si se ejecutan de manera asincrónica en el lado del cliente.

Si la carga de trabajo en el servidor se está enhebrando, el trabajo puede realizarse en paralelo, pero cada hilo debe unirse al final para devolver una sola respuesta.

La conclusión es que si los datos que está recibiendo puede ser cargado más rápido en paralelo, hacerlo, de lo contrario el uso asíncrono (Ajax) llama desde el cliente para evitar que la interfaz de usuario de bloqueo

Answer 5

que no lo haría llega a decir que el uso de hilos es inútil en ASP.NET, pero definitivamente es un modelo diferente. Para las solicitudes de recursos (solicitudes de página) en general, el subproceso es manejado por el sistema. Es decir, la Solicitud A del Usuario 1 puede tomar más tiempo que la Solicitud B del Usuario 2 y la segunda no es incomodada por la primera. Al aplicar ese concepto a las solicitudes AJAX como sugiere, todo el modelo se convierte en subprocesos múltiples de forma predeterminada y se adapta a lo que el hardware pueda manejar.

generar un subproceso puede ser útil si, por alguna razón, una petición debe generar un proceso de larga duración y tiene que responder al usuario antes de que finalice el proceso. Por lo general, los procesos que no son activos se deben volver a factorizar fuera de la aplicación web y colocar en su propio servicio de fondo. Pero no es del todo inaudito que una solicitud de página genere un hilo que se espera que haga algo en el fondo durante unos minutos para que el navegador no espere todo el tiempo (y probablemente se agote).

Answer 6

Aquí hay un ejemplo concreto de cómo todavía puede usar múltiples hilos con el modelo de programación ASP.NET. El ejemplo asume que puede desglosar las tareas necesarias para cargar una página en elementos de trabajo independientes. Luego procesa los elementos de trabajo en paralelo y espera a que se completen. Estoy usando la Biblioteca de tareas paralelas para abstraer la creación explícita de subprocesos , pero el resultado es el mismo. La programación de ASP.NET ciertamente puede acomodarse y beneficiarse de un diseño multiproceso.

private void Page_Load(object sender, EventArgs e) 
{ 
    ICollection<WorkItem> workitems = GetWorkItems(); 

    Parallel.ForEach(workitems, 
    (item) => 
    { 
     ProcessWorkItem(item); 
    }); 

    // Now that we have all of our work items completed we can continue loading the page. 
}