multi subprocesamiento de una aplicación web

Question

Sé que hay muchos casos en los que es mejor utilizar varias aplicaciones pero ¿cuándo es mejor utilizar una aplicación web.?

Answer 1

Es casi seguro que una aplicación web ya tiene varios hilos en el entorno de alojamiento (IIS, etc.). Si su página está unida a la CPU (y desea utilizar varios núcleos), entonces posiblemente múltiples hilos sean una mala idea, ya que cuando su sistema está bajo carga ya los está usando.

El tiempo en que podría ayuda es cuando usted está obligado a IO; por ejemplo, tiene una página web que necesita hablar con 3 servicios web externos, hablar con una base de datos y escribir un archivo (no relacionado). Puede hacer eso en paralelo en diferentes subprocesos (idealmente usando las operaciones asincrónicas incorporadas, para maximizar el uso del puerto de terminación) para reducir el tiempo total de procesamiento, todo sin afectar excesivamente a la CPU local (aquí la demora real está en la red).

Por supuesto, en tales casos, también puede hacerlo mejor simplemente haciendo cola en el trabajo en la aplicación web, y teniendo un servicio separado dequeue y procesarlos, pero luego no puede proporcionar una respuesta inmediata a la persona que llama (Necesitaría volver más tarde para verificar la finalización, etc.).

Answer 2

Para beneficiarse del multihilo, su aplicación tiene que hacer una gran cantidad de trabajo que se puede ejecutar en paralelo. Si este no es el caso, la sobrecarga de multihilo puede superar los beneficios.

Según mi experiencia, la mayoría de las aplicaciones web consisten en varios métodos de ejecución cortos, por lo que aparte del paralelismo que ofrece el entorno de alojamiento, diría que es raro beneficiarse de subprocesos múltiples en las partes individuales de una aplicación web . Probablemente haya ejemplos en los que ofrecerá un beneficio, pero supongo que no es muy común.

Answer 3

En mi humilde opinión, debe evitar el uso de multithread en una aplicación basada en web.

tal vez una aplicación multiproceso podría aumentar el rendimiento en una aplicación estándar (con el diseño correcto), pero en una aplicación web es posible que desee mantener un alto rendimiento en lugar de velocidad.

pero si usted tiene una conexión simultánea pocos tal vez se puede usar hilo paralelo sin una degradación del rendimiento global de

Answer 4

ASP.NET ya es capaz de desove varios hilos para procesar varias solicitudes en paralelo, por lo que para el procesamiento simple petición no rara vez es un caso en el que necesitaría engendrar manualmente otro hilo. Sin embargo, hay algunas situaciones poco comunes que he encontrado que hayan justificado la creación de otro hilo:

• Si hay alguna operación que podría tomar un tiempo y se puede ejecutar en paralelo con el resto del procesamiento de páginas, podrías generar un hilo secundario allí. Por ejemplo, si hubo un servicio web que tuvo que sondear como resultado de la solicitud, puede generar otro hilo en Page_Init y verificar los resultados en Page_PreRender (esperando si es necesario). Aunque todavía es una pregunta si esto sería un beneficio de rendimiento o no, engendrar un hilo no es barato y el tiempo entre un típico Page_Init y Page_Prerender se mide en milisegundos de todos modos. Mantener un grupo de subprocesos para esto puede ser un poco más eficiente, y ASP.NET también tiene algo llamado "páginas asíncronas" que podrían ser aún más adecuadas para esta necesidad.
• Si hay un grupo de recursos que desea limpiar periódicamente. Por ejemplo, imagina que estás utilizando un DBMS extraño que viene con enlaces .NET limitados, pero no hay soporte de agrupación (este era mi caso).En ese caso, es posible que desee implementar el grupo de conexiones DB, y esto requeriría un "hilo limpio" que se activaría, por ejemplo, una vez por minuto y verificaría si hay conexiones que no se han utilizado durante mucho tiempo (y por lo tanto puede ser cerrado).

Otra cosa a tener en cuenta al implementar sus propios hilos en ASP.NET: a ASP.NET le gusta matar a sus procesos si han estado inactivos por un tiempo. Por lo tanto, no debes confiar en que tu hilo permanezca vivo para siempre. Puede terminar en cualquier momento y será mejor que estés listo para ello.

Answer 5

El subprocesamiento múltiple es una técnica para proporcionar un solo proceso con más tiempo de procesamiento para permitir que se ejecute más rápido. Tiene más hilos por lo que come más ciclos de CPU. (De múltiples CPU, si tiene alguna). Para una aplicación de escritorio, esto tiene mucho sentido. ¡Pero otorgar más ciclos de CPU a un usuario web eliminaría los mismos ciclos de los otros 99 usuarios que hacen solicitudes al mismo tiempo! Entonces, técnicamente, es algo malo.

Sin embargo, una aplicación web puede usar otros servicios y procesos que usan varios hilos. Las bases de datos, por ejemplo, no crearán un hilo separado para cada usuario que se conecte a ellas. Limitan el número de subprocesos a unos pocos, agregando conexiones a un grupo de conexiones para un uso más rápido. Siempre que haya conexiones disponibles o agrupadas, el usuario tendrá acceso a la base de datos. Cuando la base de datos se quede sin conexiones, el usuario tendrá que esperar.

¡Básicamente, el uso de múltiples hilos podría usarse para aplicaciones web para reducir el número de usuarios activos en un momento específico! Permite que el sistema comparta recursos con múltiples usuarios sin sobrecargar el recurso. En cambio, los usuarios simplemente tendrán que hacer cola antes de que sea su turno.

Esto no sería multi-threading en la aplicación web en sí, sino multi-threading en un servicio que es consumido por la aplicación web. En este caso, se usa como una limitación al permitir que solo una pequeña cantidad de subprocesos esté activa.