¿Alguna ganancia rápida para hacer que .NET remote más rápido en una sola máquina?

Question

He sufrido una gran decepción y recibí una aplicación que, en determinadas situaciones, es al menos 100 veces más lenta, y tengo que comunicarla a nuestros clientes muy pronto (en cuestión de semanas).

A través de un perfil muy simple, he descubierto que el cuello de botella es el uso de .NET Remoting para transferir datos entre un servicio de Windows y el front-end gráfico, ambos ejecutados en la misma máquina.

Microsoft guidelines dicen "Minimizar ida y vuelta y evitar las interfaces hablador": escribir

MyComponent.SaveCustomer("bob", "smith"); 

en lugar de

MyComponent.Firstname = "bob"; 
MyComponent.LastName = "smith"; 
MyComponent.SaveCustomer(); 

Creo que esta es la raíz del problema en nuestra aplicación. Lamentablemente, las llamadas a MyComponent. * (El generador de perfiles muestra que el 99,999% del tiempo se gasta en dichas declaraciones) se reparten libremente a lo largo del código fuente y no veo ninguna esperanza de rediseñar la interfaz de acuerdo con las directrices anteriores.

Editar: De hecho, la mayoría de las veces el front-end lee las propiedades de MyComponent en lugar de escribir en ellas. Pero sospecho que MyComponent puede cambiar en cualquier momento en el back-end.

Miré para ver si puedo leer todas las propiedades de MyComponent de una vez y luego ponerlas en caché localmente (ignorando el problema del cambio en cualquier momento anterior), pero eso implicaría alterar cientos de líneas de código.

Mi pregunta es: ¿Son algunas cosas 'de ganancia rápida' que puedo tratar de mejorar el rendimiento?

Necesito al menos una aceleración de 100 veces. Soy un programador C/C++/Delphi y estoy bastante, muy poco familiarizado con C# /. NET/Remoting que no sea lo que he leído en los últimos días. Estoy buscando cosas que se puedan completar en unos días: una reestructuración importante del código no es una opción.

Solo para empezar, ya he confirmado que está usando BinaryFormatter.

(Lo siento, esto es probablemente una pregunta terribles en la línea de '¿Cómo puedo factiblemente solución X si yo descarto todas las opciones viables' ... pero estoy desesperado!)

Editar 2 en respuesta al comentario de Richard a continuación: Creo que mi pregunta se reduce a:

1. ¿hay alguna configuración que puede cambiar para reducir el costo de un .NET Remoting de ida y vuelta cuando ambos extremos de la conexión están en el misma máquina?
2. ¿Hay alguna configuración que pueda cambiar para reducir el número de viajes de ida y vuelta, de modo que cada invocación de una propiedad de objeto remoto no dé lugar a un viaje de ida y vuelta por separado? Y podría esto romper algo?

Answer 1

En .Net Remoting tiene 3 formas de comunicarse por HTTP, TCP e IPC. Si commnuicatin está en la misma PC que utilizo para usar canales IPC, acelerará tus llamadas.

Answer 2

Puede intentar comprimir el tráfico. Si no aumenta 100 veces, aún obtendrá algún beneficio de rendimiento

Answer 3

¿Podría hacer MyComponent una clase que almacenará en caché los valores y solo los presentará cuando se llame a SaveCustomer()?

Answer 4

Si necesita los últimos datos (siempre vea el valor real), y el costo de obtener los datos cada vez domina el tiempo de ejecución, entonces necesita ser radical.

¿Qué le parece cambiar el sondeo para empujar. En lugar de llamar al lado remoto cada vez que necesita un valor, haga que el control remoto presione todos los cambios y guarde en caché los últimos valores localmente.

Las búsquedas locales (después de la obtención inicial) están siempre actualizadas con toda la sobrecarga remota que se realiza en segundo plano (en otra secuencia). Solo tenga cuidado con la seguridad del hilo para tipos no atómicos.

Answer 5

En resumen, no, no hay ganancias rápidas aquí. Personalmente quisiera no hacer MyComponent (como un DTO) un MarshalByRefObject (que es probablemente el problema), ya que los viajes redondos van a paralizarlo. Lo mantendría como una clase normal, y solo movería algunos métodos clave para bombearlos (es decir, tener una clase MarshalByRefmanager/repository/etc).

Eso debería reducir ida y vuelta; si todavía tiene problemas, entonces probablemente sea ancho de banda relacionado; esto es más fácil de arreglar; por ejemplo, cambiando el serializador. protobuf-net le permite hacer esto fácilmente implementando ISerializable y reenviando los dos métodos (uno desde la interfaz, más el ctor) al ProtoBuf.Serializer - luego hace todo el trabajo por usted, y trabaja con comunicación remota. Puedo proporcionar ejemplos de esto si lo desea.

En realidad, protobuf-net puede ayudar con el uso de la CPU también, ya que es un serializador mucho más eficiente de la CPU.