扭曲的 python 挂在大型多部分消息上

Question

在我的公司，我们正在使用twisted 和flask 在工业计算机上运行rest api 服务。此 API 部分用于 IPC 和来自外部来源的有限通信。我们最近发现了通过多部分帖子发送文件时出现扭曲挂起的问题。大约 600MB 的文件会扭曲挂起大约 40-50 秒，在此期间不处理任何请求。

我应该说我不是网络开发人员，我正在边做边学。我已经分析了这个问题并将其隔离到多部分消息的组装中，flask 也挂在这个问题上，但不会阻止消息。对于相同/类似的问题，有几个错误报告：https://twistedmatrix.com/trac/ticket/5511。问题是这些都是 8 年前的，我不关心流媒体，或者至少我认为我不关心。

只是运气不好？我们可以为这项工作做些什么来扭曲，我想也许是配置问题。或者也许是扭曲的替代方案，奇怪的是，flask 附带的 WSGI 没有这个问题，但它不用于生产，所以它不是一个选项。

Answer 1

除了解决问题之外，您可能确实不走运。您注意到 Twisted 的这个问题的原因是您的 Twisted Web 服务器几乎肯定是完全单线程的（这是默认设置，否则需要一些不小的努力）。当单个 Twisted reactor 线程开始解析巨大的上传时，在完成对巨大上传的解析之前，无法提供任何其他服务。正如您所发现的，解析器非常慢。

您不会在基于 WSGI 的服务器上观察到这个问题（至少在相同条件下不会），因为这些服务器正在运行多个线程或进程。当一个客户端上传一个大文件时，其中一个线程或进程可能会被阻塞一段时间，但其他客户端可以继续为其他请求提供服务。如果每个线程或进程有一个客户端，并且这些客户端都上传了一个大文件，那么您仍然会阻塞所有线程/进程，并且在这些线程/进程完成工作之前不会为其他客户端提供服务。

正如我在顶部所说，这并非不可能解决。它可以在 Twisted 中修复，以便表单解析在完全完成之前不会阻塞反应器线程。可能还有其他解决方案。例如，您可能能够运行多个 Twisted Web 进程（可能共享一个侦听套接字以使其对客户端透明），这样它的行为至少与您观察到的 WSGI 服务器一样。