Devolución de llamada WCF, proxy y seguridad de hilos

Question

Dado un servicio dúplex WCF (NetTcpBinding) que está configurado para crear una nueva instancia de servicio para cada cliente nuevo (consulte pattern publish-subscribe), puede obtener una instancia específica de devolución de llamada para cada instancia de servicio. Dado que se crean instancias diferentes, los métodos que pertenecen a diferentes devoluciones de llamada se pueden invocar desde diferentes subprocesos al mismo tiempo.

• ¿Qué ocurre si varios subprocesos intentan invocar el mismo método en la misma devolución de llamada?
• ¿Qué sucede si intentan invocar diferentes métodos pero para la misma devolución de llamada?
• ¿Deberíamos gestionar el acceso concurrente a estos métodos desde múltiples hilos? ¿En ambos casos?

Considere ahora el lado del cliente que se comunica con el servicio: para asegurarse de que el cliente puede usar el servicio, debe crear un nuevo proxy y para invocar los métodos definidos en el servicio, debe invocar los métodos correspondientes del proxy.

• ¿Qué ocurre si varios subprocesos intentan invocar el mismo método en la misma instancia de proxy?
• ¿Qué sucede si intentan invocar diferentes métodos pero para la misma instancia de proxy?
• ¿Deberíamos gestionar el acceso concurrente a estos métodos desde múltiples hilos? ¿En ambos casos?

Answer 1

Las respuestas a la mayoría de esas preguntas dependen de cómo administre la concurrencia de su servicio. No hay una respuesta definitiva, ya que depende de lo que establezca para su ConcurrencyMode y InstanceContextMode. La administración de simultaneidad de WCF le permitirá afinar el comportamiento y rendimiento de subprocesamiento de su servicio. Una larga y ardua (pero muy detallada) lectura en concurrency management is available on MSDN.

El InstanceContextMode le permite definir cómo debe crearse una instancia de su servicio. Para un servicio que realiza muchos trabajos pesados ​​y que maneja muchas llamadas, la idea general es usar instancias PerCall, ya que con esta configuración las solicitudes de clientes entrantes se procesarán en una instancia separada del servicio cada vez.

ConcurrencyMode, el jugador principal, le permitirá definir cuántos subprocesos pueden acceder a una instancia de servicio en un momento determinado. En ConcurrencyMode=Single, solo un hilo puede acceder a la instancia de servicio a la vez. Esto también depende de si ha habilitado el SynchronizationConext, si es SynchronizationConext=true, entonces las llamadas del cliente se pondrán en cola si su servicio está en el proceso de responder otra solicitud. Por lo tanto, las llamadas de servicio entrantes se pondrán en cola hasta que las llamadas anteriores se traten primero. Con la configuración ConcurrencyMode=Multiple, se permite el acceso a cualquier número de subprocesos a una instancia de servicio, lo que significa que su servicio puede responder tantas llamadas como sea posible dado cuántos subprocesos (directamente relacionados con la potencia de la CPU) están disponibles en el grupo de subprocesos. El truco con el modo de concurrencia múltiple es que su servicio no es tan confiable en el orden en el que recibe y responde a las llamadas, ya que el estado no se administrará ya que el SynchronizationContext se configurará como falso de manera predeterminada. Un resumen bonito y breve en concurrency modes and thread safety is available on MSDN.

Esta opción puede afectar el rendimiento de su servicio cuando se utiliza junto con el modo InstanceContext, ver this pretty nice article which explores various concurrency modes and instance context settings and their effects on performance (aunque parece que los resultados son sólo en un ambiente de auto organizada, probablemente no muy representativa de los tiempos que se obtiene cuando se aloja en IIS).

La forma de administrar la concurrencia de su servicio afectará enormemente su rendimiento. Idealmente, debe poner a disposición tantos hilos como sea posible (intente aumentar los hilos mínimos de ThreadPool) a su servicio, y evitar que las llamadas a servicios entrantes se pongan en cola siempre que su servicio tenga recursos computacionales a su disposición. Pero el uso excesivo de multihilo sacrificará la gestión del estado y el orden en que responda las solicitudes del cliente.