如果我们有真正繁重的进程系统,其中进程生成是为了某种负载分布 - 那很清楚。
如果我们谈论的是 web-server :为每个连接生成一个新进程是一个好主意,因为这样可以分发。但还有什么?模型、视图和控制器的单一进程?听起来很奇怪,因为它们都以“线性”方式运行,所以不能很好地并行,我们只会在交换时获得开销。而且,那些“模型、视图和控制器”很轻,所以它们可以留在一个进程中,不是吗?
那么,除了“新连接”情况之外,在哪里产生一个新进程是好的。
谢谢你的建议。
如果我们有真正繁重的进程系统,其中进程生成是为了某种负载分布 - 那很清楚。
如果我们谈论的是 web-server :为每个连接生成一个新进程是一个好主意,因为这样可以分发。但还有什么?模型、视图和控制器的单一进程?听起来很奇怪,因为它们都以“线性”方式运行,所以不能很好地并行,我们只会在交换时获得开销。而且,那些“模型、视图和控制器”很轻,所以它们可以留在一个进程中,不是吗?
那么,除了“新连接”情况之外,在哪里产生一个新进程是好的。
谢谢你的建议。
通常,它位于您需要管理共享资源的任何地方。它可能是一个套接字,或者一个数据库连接,但它也可能是一些共享的内存数据,或者某种状态机。
您可能还希望对值列表进行并行处理(请参阅 pmap)。
对于您的“交换”点,您应该知道 Erlang 进程不使用 op-sys 工具进行调度,并且调度几乎是免费的。
在 Web 应用程序服务器的特定情况下,我理解您的问题。如果您正在编写一个共享状态很少的传统 Web 应用程序。您的 Web 框架可能已经处理了缓存和会话状态等(这些设施将产生进程)。
我们都被这种无状态的 Web 应用程序模型高度灌输。自从我们还是幼崽以来,我们都被告知有状态系统很难开发并且它们无法扩展。我想你会发现有些人对此提出了挑战。随着浏览器对 WebSockets 支持的改进,以及像 Erlang 和 Clojure 这样的服务器端语言提供具有安全状态管理的可扩展平台,将会有那些能够制作更具交互性的 Web 应用程序的人。作为一个极端的例子,你能把 WoW 想象成一个 Web 应用程序吗?
为每个连接生成一个新进程的一个原因是它使连接的编程变得更加简单。由于一个进程只处理一个连接,例如阻止对数据库的访问,长轮询或流式传输变得更加容易。该进程阻塞不会影响任何其他连接。
在 Erlang 中,一般的“规则”是您使用进程来建模并发活动并管理共享资源。流程是构建系统的基本方式。