Django 3.x - 哪个 ASGI 服务器(Uvicorn vs. Daphne)

Question

我有一个用 Django 3 编写的基于 API 的简单 Web 应用程序。在 Django 文档中有一个 page关于 ASGI服务器，并提到了两个选项:Daphne和 Uvicorn .不幸的是，他们没有提供任何关于特定选择的好处的描述，所以在选择其中一个时我很困惑。
围绕这两者编写 Django 应用程序有何不同(如果有)，是否有任何性能或稳定性问题需要注意？
基本上，使用 Uvicorn 代替 Daphne 有很大区别吗？如果这很重要，我的服务器正在 Ubuntu 上运行。

Answer 1

简单的答案:
既然你以前用过gunicorn并且熟悉它，那就去 unicorn ，特别是因为它应该用作 gunicorn worker in production .
如果你没有这方面的经验，那么我建议达芙妮 .
两者都将在一个简单的项目上完成工作，而且性能似乎相当。

说明:
ASGI 是一项相当新的技术，与该语言中的大多数其他设计更改元素相比，python 的 async/await 也是如此。
uvicorn、daphne 和 hypercorn 也在积极开发中，因此不能对这些库进行任何“公平”的基准测试。因此，在选择您想要的东西时，例如，当他们说时，您通常必须相信他们的话；他们的目标是快速、易于使用、轻量级或其他任何东西。
尽管如此，我仍然可以与 Uvicorn 和 Daphne 分享我的经验:
达芙妮 绝对是体积较大的项目，它有很多依赖项，并不是在每个项目中都完全使用。他们肯定已经尽力涵盖了许多功能，而且由于他们也是 Django 团队的一部分，您应该期待与 Django 有更好的长期兼容性。但是，Daphne 入门可能会令人生畏。
unicorn 是轻量级的，你甚至可以阅读整个库的代码，并了解齿轮是如何转动的。由于我主要使用 Uvicorn，我知道它有一些缺失的功能和错误，而 expected to work out of the box , 如果你想从你的 ASGI 服务器自定义行为，篡改 Uvicorn 比替代方案更容易。我最喜欢 Uvicorn 的部分是它甚至不是流程管理器，而是设计为作为 gunicorn 的生产 worker 工作。
旁注:连接到 Uvicorn 实际上并不是有意的或容易的。
这样做通常不是很好的做法，但考虑到在寻找替代方案 18 小时后(我个人想捕获并处理 SIGTERM 以实现正常关闭，但正常方法不起作用，因为一切都在异步循环中)，我找不到更好的方法。所以我会无耻地放一段代码，让你获得难以捉摸的“服务器”实例。从那里，小心地线程。 (没有双关语意)

import inspect #Might not be future proof! Use with care
from uvicorn import Server as UvicornServer
server = next( server for frameinf in inspect.stack() if 'server' in frameinf[0].f_locals and isinstance(server:=frameinf[0].f_locals['server'], UvicornServer) )

另一个旁注:
如果你真的选择使用 Uvicorn，并且你正在使用带有 channel 的 django，你可能想先删除“daphne”，因为它是一个 rather unused dependency的 channel 。