4

我正在对 nginx->gunicorn->Django 应用程序执行 HTTP POST 请求。响应正文很快返回，但请求还没有完全完成大约 60 秒。

“完全完成”是指我尝试过的各种客户端（Chrome、wget、我正在构建的 Android 应用程序）表明请求仍在进行中，好像在等待更多数据。从 Wireshark 监听我看到所有数据都很快到达，然后在 60 秒后 ACK FIN 终于来了。

本地开发服务器 ( ./manage.py runserver) 上的相同 POST 请求执行速度很快。此外，它绕过 nginx 直接针对 gunicorn 快速执行。在 Apache/mod_wsgi 设置中也可以快速运行。

GET 请求没有问题。甚至其他 POST 请求也可以。我知道的一个区别是这个特定的请求返回 201 而不是 200。

我认为它与Content-Length标头、关闭与保持连接连接有关，但还不知道事情应该如何正常工作。

  • 后端服务器（gunicorn）当前正在关闭连接，这是有道理的。
  • 后端服务器应该包括Content-Length header，还是Transfer-encoding: chunked？或者 nginx 是否应该能够在没有这些的情况下应对，并根据需要添加它们？
  • 我认为保持连接是好的，不应该在 nginx 中禁用。

更新：设置keepalive_timeout为 0nginx.conf解决了我的问题。但是，当然，keep-alive 已经消失了。我仍然不确定是什么问题。可能堆栈中的某些东西（我的 Django 应用程序或 gunicorn）没有正确实现分块传输，并使客户感到困惑。

4

1 回答 1

0

听起来您的上游服务器（gunicorn）以某种方式在特定的 api 调用上保持连接打开 - 我不知道为什么（取决于您的代码，我认为），但proxy_read_timeoutnginx 中的默认选项是 60 秒，所以听起来由于某种原因，没有收到此回复。

我使用了一个非常相似的设置，我一般没有注意到 POST 或任何其他请求的任何问题。

请注意，这return HttpResponse(status=201)曾给我带来过问题——似乎 Django 更喜欢明确空的主体：return HttpResponse("", status=201)工作。我通常在我期望的地方设置一些东西——这可能是需要注意的事情。

于 2012-05-10T08:57:45.127 回答