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

Question

在我公司，我們使用 twisted 和 flask 在工業計算機上運行 rest api 服務。 此 API 部分用於 IPC 和來自外部資源的有限通信。 我們最近發現了通過多部分帖子發送文件時出現扭曲掛起的問題。 大約 600MB 的文件將扭曲掛起大約 40-50 秒，在此期間不處理任何請求。

我應該說我不是 web 開發人員，我正在學習 go。 我已經分析了這個問題並將其隔離到多部分消息的組合中，flask 也掛在這個問題上，但不會阻止消息。 對於相同/類似的問題，有幾個錯誤報告： https://twistedmatrix.com/trac/ticket/5511 。 問題是這些是 8 年前的，我不關心流媒體，或者至少我認為我不關心。

只是運氣不好？ 我們可以為這項工作做些什么來扭曲，我想也許是配置問題。 或者也許是扭曲的替代方案，奇怪的是，flask 附帶的 WSGI 沒有這個問題，但它不適合生產使用，所以它不是一個選項。

Answer 1

除了實施解決問題的方法外，您可能確實不走運。 您注意到 Twisted 這個問題的原因是您的 Twisted Web 服務器幾乎肯定是完全單線程的（這是默認設置，否則需要一些不小的努力）。 當單個 Twisted reactor 線程開始解析巨大的上傳時，在完成對巨大上傳的解析之前，無法提供任何其他服務。 正如您所發現的，解析器非常慢。

您不會在基於 WSGI 的服務器上觀察到這個問題（至少在相同的條件下），因為這些服務器正在運行多個線程或進程。 當一個客戶端上傳一個大文件時，其中一個線程或進程可能會被阻塞一段時間，但其他客戶端可以繼續為其他請求提供服務。 如果每個線程或進程有一個客戶端，並且這些客戶端都上傳了一個大文件，那么您仍然會阻止所有線程/進程，並且在這些線程/進程完成該工作之前不會為其他客戶端提供服務。

正如我在頂部所說，這並非不可能解決。 它可以在 Twisted 中修復，以便表單解析在完全完成之前不會阻塞反應器線程。 可能還有其他解決方案。 例如，您可能能夠運行多個 Twisted Web 進程（可能共享一個偵聽套接字以使其對客戶端透明），以便它的行為至少與您觀察到的 WSGI 服務器一樣好。