AppDomain 通信和性能
我正在托管一个 WCF 服务，其要求是调用 WCF 服务未直接引用的类型的对象，并在其上运行一些（常见）方法。该类型是通过反射和 AssemblyResolve 创建的：这是可以的。
然后我开始思考——我们预计可能会有 50 - 100 个程序集/类型到达，特别是当我们对它们进行版本控制时。由于所有这些程序集都在 mem 中引用，这可能会导致服务主机应用程序的内存和性能膨胀（仍然是理论上的而不是实践）。
因此，我们应该卸载——但唯一的方法是通过应用程序域。我们的想法是，每个程序集都会以某种方式在自己的应用程序域中运行，而 WCF 服务实际上只是将消息传递到适当的应用程序域。如果 appdomain 在 some_period_of_time 内没有使用，那么我们只需卸载 appdomain。
一些指导对于以下方面很有用：
- 这是一个疯狂的想法吗？
- 该进程应该在内存中大约 100 个程序集的情况下正常运行吗？
- 与应用程序域的通信可能会付出一些代价（通过远程处理/命名管道）：这是否取消了这个想法？
- 创建一个基本上为一种类型的 .dll 提供服务的应用程序域将涉及许多应用程序域；这是一个坏主意吗？
我没有这方面的经验。如果我不这样做，我担心的是应用程序的大小和性能。然而，根据应用程序域的想法，这听起来基本上像是大规模的过度设计。我无法更改托管此未知 .dll 的要求。
这个想法是否像听起来那么糟糕？与之相关的优点/缺点是什么？
I am hosting a WCF service where the requirements are that an object, of a type the WCF service is not directly referenced, is invoked and some (common) methods run on it. The type is created via reflection and AssemblyResolve: this is OK.
I then got to thinking -- we are expecting maybe 50 - 100 of these assemblies / types to arrive, especially when we are versioning them. This should presumably bloat (still on theory here rather than practice) the memory and performance of the service host application due all these assemblies being referenced in mem.
As a result, we should unload -- but the only way to do this is via an appdomain. The thinking is that each assembly would somehow run in its own appdomain and the WCF service is actually just passing messages to the appropriate appdomain. If the appdomain is not used for some_period_of_time, then we simply unload the appdomain.
Some guidance would be useful on:
- is this an insane idea?
- should the process should run fine with ~100 assemblies in memory?
- communication with appdomains would presumably come at some cost (via remoting / named pipes): does this disqualify the idea?
- creating an appdomain to basically service one type of .dll would involve many appdomains; is this a bad idea?
I have no experience in this area. My worries are the size and the performance of the app if I don't do something like this. However, with the app domain idea, this basically sounds like massive over-engineering. The requirement to host this unknown .dlls is not something I can change.
Is this idea as bad as it sounds, and what are the pro's / con's associated with it?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您必须尝试（创建模型很容易），但您只能使用代码。因此，如果每块 1 MB，您将使用 100MB 的可丢弃内存，我预计不会出现问题。
前提是您的实例已释放并收集。
You'll have to try (it's easy to create a mock-up) but you're only stuck with the code. So at 1 MB a piece you would be using 100MB of discardable memory, I don't expect a problem.
Provided your instances are released and collected.
如果您有可用内存并且想要更好的性能，您可以等到第一次调用并且程序集将被延迟加载（后续调用会更快），或者如果您不希望进行任何缓慢的调用，那么您可以在服务启动时立即加载程序集。当内存很便宜时，我不认为有理由在每次调用时加载/卸载程序集。如果您发现性能问题，那么我建议考虑在不使用程序集时卸载它们。
If you have the memory available and want better performance, you can either wait until the first call is made and the assemblies will be loaded lazily (subsequent calls will be faster), or if you don't want any slow calls made, then you could eager load the assemblies when the service starts. I don't see a reason to load/unload the assemblies on each call when memory is cheap. If you notice a performance problem, then I'd say think about unloading the assemblies when they're not being used.
这本质上就是 IIS 应用程序池和工作进程的作用。也许并不疯狂，但这里有很大的实施空间，可能会导致愉快或不愉快的结果。
This is essentially what IIS App Pools and Worker Processes do. Probably not insane, but there's a lot of room for implementation here that could lead to happy or unhappy results.