请求在 Django 中花费的时间太长

我想知道给你这些错误消息的包，假设它的 gunicorn 你必须知道默认情况下 workers 在 30s 后超时，您可以尝试禁用超时，然后再找出合适的持续时间。 要禁用 gunicorn 的超时，您可以使用 -t 或 --timeout，然后是以秒为单位的持续时间，如果您将 0 作为持续时间超时将是无限的。 您的命令将如下所示：Gunicorn -B 127.0.0.1：8000 -t （持续时间） test：app

GET 请求的 WWW 模型...加工。。。对浏览器的响应旨在供大量客户端同时使用，不太适合需要大量资源来生成响应的请求。Samdace 的回答告诉你如何增加超时，如果你知道（比如）一分钟总是足够的，但 30 秒就不够了，并且你知道服务器永远不会被要求一次处理超过少量的此类请求。因为太多基本上会杀死整个服务器（这是一种拒绝服务攻击，特别是如果服务器可供所有人访问，例如价格比较网站）。

但是假设每个请求需要几十分钟？用户不会乐于等待最终的响应，如果他放弃并离开，响应将永远丢失。因此，您需要存储他执行某项操作的请求，并允许他稍后返回以查看他的处理是否已完成，如果已完成，则收集他的结果。

你可以编写一个命令行命令，以自定义管理命令的形式访问 Django 数据库。然后，您需要一些东西（例如，定期 cron 作业、调用第二个管理命令或带有参数的相同命令）来检查是否有任何请求未完成，并通过启动执行管理命令的进程、从一个 Model 实例获取请求并以另一个 Model 实例的形式返回结果，一次处理一个请求（或一个合适的有限数量）。Python 的 subprocess.run 在这里可能很有用。--poll

用户稍后返回并访问其结果。别忘了保留一个 ForeignKey，这样 Django 就可以从其他人的结果中分辨出他的结果。User

这是一项相当多的工作，但主要是非常简单的 CRUD 视图。最难的是执行请求的命令内部发生的事情，您大多已经编写了请求。

您的处理命令应该有一个 catch-all 异常处理程序，以便任何类型的失败都会被记录为（失败的）结果，并且请求始终被标记为已处理，因此您永远不会永远陷入循环重新处理失败。

try:

    do_the_hard_work()

except Exception as exc: # or a wide range of more specific exceptions
     mark_this_request_failed()

finally:
     make_results_available_for_user()  # success or fail