AppDomain Communication and Performance

Question

I host the WCF service where the requirements are that the object, the type that the WCF service does not refer to, is called, and some (common) methods are run on it. Thus, the type is created through reflection and AssemblyResolve: this is normal.

but then I thought - we expect that perhaps 50-100 of these assemblies / types will be reached, especially when we version them. this should apparently swell (still in theory here, not in practice) the memory and performance of the service host application, since all of these assemblies are referenced in mem.

therefore, we must offload: but the only way to do this is through appdomain. the thinking is that each assembly would somehow run its own appdomain in it, and the WCF service would actually just pass messages to the corresponding appdomain. If appdomain is not used for some_period_of_time, we simply unload appdomain.

I will probably be noted for this, but some recommendations will be helpful:

• Is this a crazy idea?
• should the process work fine with ~ 100 assemblies in memory?
• linking to appdomains supposedly brings some value (via remote / named pipes): does this disqualify the idea?
• creating an appdomain to serve one type of .dll will include many applications, is it slowing down?

I have no experience in this area. My concern is the size and performance of the application, if I am not doing anything like this. however, with the idea of ​​a domain application, it basically sounds like massive over-engineering. The requirement to host this unknown .dll is not something that I can change.

I think my general question is:

Is this idea idiotic, how does it sound, and what is / pro / con related to it?

Answer 1

should the process work fine with ~ 100 assemblies in memory?

You will have to try (easy to create a layout), but you are just stuck in the code. Thus, at 1 MB you will use 100 MB of discarded memory, I do not expect a problem.

Provided that your copies will be released and collected.

Answer 2

If you have available memory and require better performance, you can either wait until the first call is completed and the assemblies load lazily (subsequent calls will be faster), or if you do not want slow calls to be made, then you can want to load assemblies when the service starts. I see no reason to load / unload assemblies on every call, when the memory is cheap. If you notice a performance problem, I would say think about unloading assemblies when they are not in use.

Answer 3

This is essentially what IIS application pools and workflows do. Probably not crazy, but there are many opportunities for implementation that can lead to happy or unhappy results.