Llamadas remotas asíncronas

Question

Tenemos un servidor singleton remoto ejecutándose en un servicio de Windows separado (llamémoslo RemotingService).Los clientes de RemotingService son instancias de ASP.NET (muchas, muchas).

Actualmente, los clientes de comunicación remota llaman a RemotingService y se bloquean mientras se atiende la llamada de RemotingService.Sin embargo, el servicio de comunicación remota se está volviendo lo suficientemente complicado (con más llamadas RPC y algoritmos complejos) que los subprocesos de trabajo de asp.net se bloquean durante un tiempo significativamente largo (4-5 segundos).

De acuerdo a este artículo de msdn, hacer esto no escalará bien porque un subproceso de trabajo de asp.net está bloqueado para cada RPC remota.Aconseja cambiar a controladores asíncronos para liberar subprocesos de trabajo de asp.net.

El propósito de un controlador asincrónico es liberar un subproceso de piscina ASP.NET para atender solicitudes adicionales mientras el controlador está procesando la solicitud original.

Esto parece estar bien, excepto que la llamada remota todavía ocupa un subproceso del grupo de subprocesos.¿Es este el mismo grupo de subprocesos que los subprocesos de trabajo de asp.net?

¿Cómo debo hacer para convertir mi servidor singleton remoto en un sistema asíncrono para liberar mis subprocesos de trabajo de asp.net?

Probablemente me he perdido información importante. Avíseme si hay algo más que necesite saber para responder la pregunta.

Answer 1

La idea detrás del uso de ThreadPool es que a través de él puede controlar la cantidad de subprocesos sincrónicos y, si son demasiados, el grupo de subprocesos administra automáticamente la espera de subprocesos más nuevos.

El subproceso trabajado de Asp.Net (AFAIK) no proviene del grupo de subprocesos y no debería verse afectado por su llamada al servicio de comunicación remota (a menos que se trate de un procesador muy lento y su función de comunicación remota requiera mucha CPU, en lo cual En este caso, todo el contenido de su computadora se verá afectado).

Siempre puedes alojar el servicio remoto en un servidor físico diferente.En ese caso, su hilo de trabajo de asp.net será totalmente independiente de su llamada remota (si la llamada remota se llama en un hilo separado).