使用 Gunicorn 或 uWSGI 提供服务时,Django WSGI 应用程序对象的生命周期是多少?

What is the lifetime of a Django WSGI application object when served using Gunicorn or uWSGI?

我将 Django 与 Gunicorn 一起使用。由于我不太了解 Gunicorn 的内部结构,所以我想知道 WSGI 应用程序对象的生命周期是多少。它是永远存在的,还是为每个请求创建的,或者与 worker 的寿命一样长?

类似地,在 uWSGI 中,似乎根据 this 为一个请求调用可调用的应用程序。那么,这是否意味着应用程序对象存在一段时间(并且 uWSGI 为每个请求调用相同的对象)?

这可能很愚蠢,但我正在尝试在应用程序级别缓存一些东西(比如在某些全局或文件级变量中)以避免缓存(Redis/Memcached)或数据库调用。我想知道应用程序对象是否至少存在一段时间,那么在不发出缓存请求的情况下定期缓存数据可能是一件好事(毕竟它是一个 N/W 请求)。

请帮助我理解这一点。

您似乎遗漏了一些重要的区别 -- WSGI 是 PEP-333(3) 规定的协议名称,而 gunicorn/uwsgi 是上述协议的实现。

what is the lifetime of an WSGI application object. Is it forever, or created for every request, or lives as long as the worker lives?

Django 有 wsgi.py 公开名为 application 的 WSGI 应用程序 object 的文件,所有 USGI 服务器都使用该文件(您需要传递此可调用文件的位置)。基本标准是应用程序 object 需要采用两个参数:

  • WSGI 环境
  • 可调用以启动响应

应用程序通过从环境中生成请求和其他必要的元数据来包装下面层的所有内容,并且在发送响应时调用提供状态代码和 headers 的可调用对象。然后响应 body 作为可迭代的。

因此,如您所见,WSGI 服务器可以在启动时获取应用程序 object,并且可以在服务器进程的整个生命周期中每次请求获得响应时调用它。我主要使用 uwsgi,所以我可以告诉 uwsgi(可能还有其他人)正是这样做的。

为了给您更多相关信息,uwsgi 提出了主进程启动工作进程并在每个进程内生成工作线程的概念。 gunicorn(和其他人)如果不完全相同,大概也有类似的概念。