每个实例的 AppDomain 或进程?
Posted
技术标签:
【中文标题】每个实例的 AppDomain 或进程?【英文标题】:AppDomain or process per instance? 【发布时间】:2011-02-16 15:47:48 【问题描述】:我想知道是否应该为每个实例使用一个进程,或者是否应该使用AppDomain
s 在单个进程中运行多个实例。
我有一个服务器应用程序,其设计类似于 telnet。用户始终通过 TCP 连接,服务器保持客户端会话的完整状态,并呈现在工作站上。
该软件需要支持至少 500 个并发连接,可能更多。一个典型的安装将需要 3 到 7 个应用程序实例连续运行,尽管除了一个实例之外的所有实例都只有几个连接(它们用于测试、参考环境等)。在内部,出于开发目的,最多有 40 个环境,每个环境最多有 20 个并发连接。我的目标主机环境将是 64 位 Windows。
我知道 IIS 使用的模型只有一个进程和多个 AppDomain
s,但我也看到了每个实例拥有一个进程的优势。
我应该使用哪个以及为什么?
编辑:
不同的实例涉及同一应用程序的不同版本,它们不能在单个AppDomain
中一起运行。此外,不同的实例不必相互通信,只需与一个主服务进行管理即可。
【问题讨论】:
有趣——为什么必须同时运行多个版本的应用程序? 是不是我在问题中说的,有参考环境有数据库的副本,更新的版本和需要客户测试的更新等等。 【参考方案1】:总结一下:
-
您有一个类似 telnet 的服务器应用程序。
您将在同一台机器上运行此应用程序的多个版本。
不同的实例不需要相互通信;仅用于共同服务。
大概每个实例都通过不同的端口进行通信
由于这些要求,我永远不会考虑构建与 IIS 相同的功能。相反,我会将它们作为完全独立的应用程序运行。
顺便说一句,您说 IIS 只有 1 个具有多个应用程序域的进程是不正确的。 IIS 可以为单个站点启动多个进程。这称为Web Garden。此外,IIS 为其拥有的每个应用程序池启动至少一个进程。您可以将这些视为在 IIS 服务器上执行的单独 w3wp.exe 进程。
通过通用进程运行所有内容的唯一好处是,如果主机提供了对所有内容都通用的有价值的东西。例如日志接口或故障处理。这将是非常复杂的编写、设置和维护,几乎没有什么好处。
最后,用户数量无关紧要,因为这将由应用程序的资源使用情况决定。这可能意味着网络、内存甚至磁盘,具体取决于您的应用程序执行的功能。
【讨论】:
谢谢。我想我的问题不是很清楚,但是您完全正确。我现在想不出任何主机进程可以提供我无法用不同的进程实现的好处。您能否详细说明为什么单个进程会成为问题?需要一些反对我的同事的论据。 @Pieter:问题主要在于开发和维护使主机进程启动并与子进程进行稳健通信所需的接口。这需要时间。如果没有好处,那就是浪费时间。将这些应用程序简单地编写为 windows 服务并让 windows 控制是否需要重新启动服务等会更具成本效益。 @Pieter:为了澄清一点,主机进程将不得不插入子进程以查看它们是否仍在运行。一旦你有了这个,有人会尝试通过它集中所有的日志记录,然后会添加其他的东西。在您知道之前,必须对界面进行版本控制,并且您正处于主机进程可以支持哪些软件版本的矩阵泥潭中。在您开始之前,请考虑一下它可以去哪里。 @Chris Lively - 好点。但这听起来几乎像是在提倡单一进程、多 AppDomains 模型。您对阅读有关从单个管理流程管理多个流程的材料有什么建议吗? @Pieter:不,我不是在提倡,我实际上是在试图引导您使用独立的流程。 IIS 所做的第一件事是接受传入的 TCP 连接并根据接收到的数据包的内容将其正确路由到另一个进程。对于您的情况,这不是必需的。您的应用程序完全处理它自己的通信。此外,您有不同版本的应用程序,可能会有不同的通信结构。【参考方案2】:好吧,您不能为每个用户会话设置进程,因为您计划其中有 500 个。 500 个应用程序域也是如此。 IIS 在主机进程(应用程序池)下使用每个 Application 的 appdomain,而不是用户会话。
我可以建议您使用类似的设计吗? 其应用程序域中的每个实例(您说最多 40 个实例?) 每个用户都由线程处理,没有创建新的应用程序域/进程。(不会像指出的那样) 为了支持大量用户,也许可以使用负载均衡器直接连接到机器集群
【讨论】:
这 500 个用户会话是 TCP 会话,都在一个 AppDomain 或进程中。 我看不出有什么问题,如果 ~500 是最大值。管理通信 + 错误、更多应用程序域或进程的复杂性对于这种规模来说是没有意义的。如果您需要更多功能,在更多情况下,应用程序的另一个实例将满足您的需求。【参考方案3】:构建您的服务器非常容易,以便您稍后再决定,并且更有可能进行一些混合;一些具有多个应用程序域的共享主机和一些单一主机?
复杂的一点不是创建多个应用程序域并多次运行同一个应用程序。复杂的一点是您可以创建单个应用程序域并托管单个应用程序。一旦您能够做到这一点,就可以轻松地扩展到具有相同或不同应用的多个应用域。
我有一个示例服务器 (here),它作为我的 server framework 的一部分提供,它可以以两种方式运行,它在一个端口上托管单个应用程序域,并在第二个端口上启动每个用户的应用程序域(我并不是说您需要一个每个用户的应用程序域,只是它与每台服务器的单个应用程序域的规模相反)。
还有一个新示例可以完成 IIS 所做的整个“卷影复制、自动重启”操作,这有点复杂,但我已经写过 here 和 here。再次,一旦您有了基本的托管,它就不会太复杂。
就我个人而言,我倾向于将所有这些构建到一个服务中,然后 simply run multiple copies 如果您想要多个服务器,然后您可以按照您认为合适的方式和完整系统的配置文件建议您应该混合和匹配。
我想,总而言之,我会说您应该针对多应用程序域的情况进行设计,因为您始终可以通过使用单个应用程序域配置服务器来简单地运行单个应用程序域和多个进程......
【讨论】:
感谢您的反馈。你描述的,我已经实现了。现在我需要选择走哪条路:)。 在这种情况下配置文件并查看。我会设置一个服务器来启动,如果您遇到多个应用程序域的性能问题,请将一些服务器移到第二个实例和/或第二个盒子。以上是关于每个实例的 AppDomain 或进程?的主要内容,如果未能解决你的问题,请参考以下文章