AppDomain通信和性能

Question

我正在托管一个WCF服务，其中的要求是调用一个WCF服务未被直接引用的类型的对象，并在其上运行一些（常见的）方法。所以类型是通过反射和AssemblyResolve创建的：这没关系。

然后我开始思考 - 我们预计可能会有50到100个这样的程序集/类型到达，特别是当我们对它们进行版本控制时。由于所有这些程序集都在mem中引用，因此这应该是服务主机应用程序的内存和性能，这应该是膨胀（仍然在理论上而不是实践）。

所以我们应该卸载：但唯一的方法是通过appdomain。我们的想法是，每个程序集都会以某种方式运行在它自己的appdomain中，而WCF服务实际上只是将消息传递给相应的appdomain。如果appdomain不用于some_period_of_time，那么我们只需卸载appdomain。

我可能会因此而被标记下来，但有些指导对我们有用：

1. 这是一个疯狂的想法吗？
2. 该进程应该在内存中运行~100个程序集吗？
3. 与appdomains的通信可能需要付出一定的代价（通过远程处理/命名管道）：这会使这个想法失去资格吗？
4. 创建一个appdomain基本上服务一种类型的.dll会涉及很多appdomains，这是迟钝的吗？

我没有这方面的经验。如果我不做这样的事情，我担心的是应用程序的大小和性能。然而，根据应用领域的想法，这基本上听起来像是大规模的过度工程。承载这个未知的.dll的要求不是我可以改变的。

我想我的整体问题是：

这个想法听起来像是愚蠢的，与它有什么关系？

Answer 1

  

如果进程在内存中有~100个程序集正常运行吗？

你必须尝试（创建一个模型很容易），但你只是坚持使用代码。所以在1 MB的情况下你会使用100MB的可丢弃内存，我不指望有问题。

提供实例发布和收集。

Answer 2

如果你有可用的内存并希望获得更好的性能，你可以等到第一次调用并且会延迟加载程序集（后续调用会更快），或者如果你不想进行任何慢速调用，然后你可以在服务启动时急切加载程序集。当内存很便宜时，我没有理由在每次调用时加载/卸载程序集。如果您发现性能问题，那么我会考虑在不使用时卸载组件。

Answer 3

这基本上是IIS应用程序池和工作进程的作用。可能不是疯了，但这里有很多实施的空间，可能导致快乐或不快乐的结果。