Comunicación y rendimiento de AppDomain

Question

estoy alojando un servicio WCF, donde los requisitos son que un objeto, de un tipo al que el servicio WCF no se hace referencia directamente, se invoca y algunos métodos (comunes) se ejecutan en él. Entonces el tipo se crea a través de reflection y AssemblyResolve: esto está bien.

pero luego pensé que estamos esperando que lleguen entre 50 y 100 de estos ensamblados/tipos, especialmente cuando los estamos versionando. esto debería presumiblemente hinchar (todavía en la teoría aquí en lugar de practicar) la memoria y el rendimiento de la aplicación de host de servicio debido a que todos estos ensamblados están referenciados en mem.

entonces deberíamos descargar: pero la única forma de hacerlo es a través de un dominio de aplicación. lo que se piensa es que cada ensamblaje se ejecutará de alguna manera en su propio dominio de aplicación y el servicio WCF en realidad solo está pasando mensajes al dominio de aplicación apropiado. Si el appdomain no se usa para some_period_of_time, simplemente descargamos el appdomain.

i probablemente obtendrá rebajado para esto, pero algunas orientaciones serían útiles en:

1. Es esta una idea loca?
2. ¿debería el proceso funcionar bien con ~ 100 ensamblajes en la memoria?
3. comunicación con appdomains probablemente tendría algún costo (a través de remoting/named pipes): ¿esto descalifica la idea?
4. creando un dominio de aplicación para servir básicamente a un tipo de .dll implicaría muchos appdomains, ¿está esto retrasado?

no tengo experiencia en esta área. Mis preocupaciones son el tamaño y el rendimiento de la aplicación si no hago algo como esto. sin embargo, con la idea de dominio de la aplicación, esto básicamente suena como una sobre-ingeniería masiva. el requisito de alojar este desconocido .dlls no es algo que pueda cambiar.

Creo que mi pregunta general es:

es esta idea tan estúpida como parece, y cuáles son los pros de/con asociada a ella?

Answer 1

¿debería funcionar bien el proceso con ~ 100 ensamblajes en la memoria?

Tendrás que probar (es fácil crear una maqueta) pero solo estás atascado con el código. Entonces, con 1 MB por pieza, estarías usando 100 MB de memoria descartable, no espero un problema.

Siempre que se publiquen y recojan sus instancias.

Answer 2

Si tiene la memoria disponible y desea un mejor rendimiento, puede esperar hasta que se realice la primera llamada y los ensamblajes se cargarán perezosamente (las llamadas posteriores serán más rápidas), o si no desea ninguna llamada lenta hecho, entonces podría desear cargar las asambleas cuando comience el servicio. No veo una razón para cargar/descargar los ensamblajes en cada llamada cuando la memoria es barata. Si notas un problema de rendimiento, diría que debes pensar en descargar los ensamblajes cuando no los estén usando.

Answer 3

Esto es esencialmente lo que hacen las agrupaciones de aplicaciones de IIS y los procesos de trabajo. Probablemente no es una locura, pero hay mucho espacio para la implementación aquí que podría conducir a resultados felices o infelices.