2012-10-06 5 views

Respuesta

12

Esto es por diseño. Los dos procesos de trabajo no comparten estado y los clientes se distribuirán entre ellos de forma rotativa, lo que significa que el 50% se conectará al proceso A y el 50% al proceso B. Como el bus de mensajes SignalR subyacente está en memoria Por defecto, el proceso A no ve los mensajes del proceso B.

Lo que está configurando se llama un "jardín web" (que no debe confundirse con "granja web") y se usa comúnmente para hacer que las aplicaciones defectuosas sean más receptivas (ver this SO question). Como SignalR está construido desde cero con la escalabilidad en mente, esta configuración no le dará ningún beneficio.

Mi recomendación es mantener el límite de procesos de trabajo en 1.

Sin embargo, existe una manera de hacer que funcione con jardines web: que había necesidad de utilizar un bus de mensajes externo como Redis o Windows Azure Service Bus (se pueden encontrar detalles en el docs) para compartir mensajes entre los procesos, lo que por supuesto introduce una latencia de red adicional.

+0

Esto responde exactamente mi pregunta. Tengo problemas de pérdida de memoria y tengo que reciclar los grupos de aplicaciones periódicamente. Juego con el jardín web para ver si me ayuda. Gracias. – Naptime

+0

Actualice esta respuesta con el enlace directo a la documentación, que se encuentra en: http://www.asp.net/signalr/overview/performance/scaleout-in-signalr. Además, tengo una objeción: no me gusta la recomendación de mantener el límite del proceso de trabajo en 1. Sin duda, hay beneficios en usar más de 1. La documentación mostrará al usuario cómo hacer que funcione con más de 1 proceso de trabajo sin limitando sus opciones. – Icarus

+0

@lcarus gracias, agregué el enlace directo. Sin embargo, dejaré mi recomendación de un proceso de trabajo. Si bien un jardín web tiene algunas ventajas en ciertos casos de uso, la gran mayoría de los usuarios no debería necesitarlo. –

Cuestiones relacionadas