频道应用程序无故停止工作 unitil ASGI 服务器重新启动

Posted 2023-02-16

【中文标题】频道应用程序无故停止工作 unitil ASGI 服务器重新启动

【英文标题】：Channels app stops working without any reason unitil ASGI server restart

【发布时间】：2018-12-23 19:06:48

【问题描述】：

在某个时间点应用程序服务器停止工作。 WS 客户端正在尝试连接，但他们不能。日志文件中有回溯，该客户端在连接被接受之前已断开连接。服务器停止甚至提供纯 HTTP 请求（日志文件中没有任何回溯）。

我有一个频道应用程序一方面可以使用 o7sock.js(https://github.com/Z-Wave-Me/O7)，另一方面可以使用 REST Framework(DRF)。一段时间内一切正常。我在日志文件和来自 ws-clients 的报告中看到了 ping/pong。我还可以针对 API 进行 REST 调用。

有时客户端会立即断开连接。看起来有 ping/pong 消息，并且下一个 ping 请求以回溯结束，因为客户端已断开连接。在那之后，只有来自 ws-clients 的连接请求，在连接被接受之前断开连接。 HTTP/REST 接口目前不可用。

此时唯一的处理方法是重启ASGI服务器程序。 我试过 daphne 和 uvicorn - 都有这个问题。

我的应用有一个 WebsocketConsumer（同步）来处理 WS 客户端。我还有一些其他 SyncConsumer，它们在工作进程中工作。

主要问题是失败的时间不规律，所以我无法找出问题的主要原因。看起来工作进程也没有受到影响，因为我只需要重新启动 ASGI 服务器即可使应用程序正常工作。

我想拥有带有长寿客户端的 WS 服务器。服务器应使用 django 模型并为外部服务（移动应用程序）提供 REST API。现在我的服务器已经工作了一段时间，但随时可能无缘无故地失败。

忘了提一下，我几乎使用了最新版本的库和框架，可通过 pip 获得。

【参考方案1】：

看来是我自己搞定的。对于那些可以在这个问题上运行的人： 这都是关于默认设置的。无论是 WS 还是 HTTP，使用 Sync 消费者都会为每个 CPU 留下 5 个线程来处理并发请求。正如文档https://channels.readthedocs.io/en/latest/topics/databases.html 中所述，您可以使用环境变量 ASGI_THREADS 来提高此限制。但一般来说，对于长期存在的 WS 客户端，最好使用异步消费者。现在我没有时间进行重构，所以解决方案是在共享 FD 上运行多个（每个 CPU 一个）daphne 服务器，ASGI_THREADS=100。这为同步任务提供了 400 个线程和 4 个 daphne 进程。无论如何，我将在明年年初将我的 WS 消费者重写为异步。 使用上述设置，我在一天多的时间里都没有在日志中看到任何问题或警告。