AppDomain 通信和性能

Question

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

但后来我想到 - 我们预计可能会有 50 到 100 个这些程序集/类型到达，尤其是在我们对它们进行版本控制时。由于所有这些程序集都在 mem 中被引用，这可能会导致服务主机应用程序的内存和性能膨胀（这里仍然是理论而不是实践）。

那么我们应该卸载：但唯一的方法是通过应用程序域。想法是，每个程序集都会以某种方式在它自己的 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 应用程序池和工作进程所做的。可能并不疯狂，但这里有很大的实施空间可能会导致快乐或不快乐的结果。