☰

(nginx -> uwsgi -> wsgi 应用程序) 架构中的 IPC 开销？

tag-icon • tag-icon nginx python web wsgi uwsgi
(nginx -> uwsgi -> wsgi 应用程序) 架构中的 IPC 开销？

最近我正在建立一些 Python 网站，似乎这种架构nginx -> uwsgi -> wsgi application是当今 Python 世界中显而易见的选择。（实际上，我正在将由 Apache + mod_wsgi 支持的 MoinMoin 网站迁移到运行 nginx 的较新 VM，因此我花了一些时间研究由 nginx 支持的部署可能性。）

我读了很多关于为什么需求成为这样的间接层，我完全清楚所涉及的各个技术 - nginx、uwsgi 和 wsgi - 都是现代的，具有非常高的性能，并且截至目前都已成熟。但由于在这样的架构中涉及 2 个 IPC 层（nginx -> uwsgi和uwsgi -> wsgi application），我一直在思考

  • IPC 如何影响整体性能？
  • 其影响是否大到足以产生实际意义？

我谷歌了一下，没有找到直接的答案。那么 IPC 开销是否足够小，还是只是我没有找到正确的关键字？

（顺便说一句，我读到 Erlang 社区已经开发了几个 HTTP 服务器，它们接收用户的 HTTP 请求直接地应用程序代码，并且还有非常高的性能。我在 Google 上搜索过，但找不到比较这两种方法的基准）

答案1

uwsgi->wsgi 部分没有 ipc。唯一的连接/ipc 是从 nginx 到 uWSGI，并且它几乎没有影响（记住，即使守护进程模式下的 apache+mod+wsgi 也使用 ipc）

关于你问题中的 Erlang 部分，你也可以将 Python 的高性能 http 解析器嵌入到你的代码中（甚至可以使用 uWSGI），但经验表明，这对于安全性、多功能性和可扩展性来说不是一种好方法（但显然你可以自由地这样做）。拥有前端代理似乎是最合理的选择（独立于应用服务器或语言）

相关内容