Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Warmup django application during uwsgi chain-raload

I'm using uwsgi + django and trying to make the fastest reloading. I've configured chain reloading (http://uwsgi-docs.readthedocs.io/en/latest/articles/TheArtOfGracefulReloading.html#chain-reloading-lazy-apps), but still there are couple seconds of latency while serving first request after worker reload.

Is there any way to warm up the django application with uwsgi configuration to reduce waiting time?

like image 936
Alexander Rogovsky Avatar asked Jan 29 '17 21:01

Alexander Rogovsky


People also ask

How does uWSGI work with Django?

uWSGI operates on a client-server model. Your web server (e.g., nginx, Apache) communicates with a django-uwsgi “worker” process to serve dynamic content. uWSGI supports multiple ways to configure the process. See uWSGI’s configuration documentation.

What is the best way to manage uWSGI reloads?

Take a traditional (and highly suggested) architecture: a proxy/load balancer (like nginx) forwards requests to one or more uWSGI daemons listening on various addresses. If you manage your reloads as “stop the instance, start the instance”, the time slice between two phases will result in a brutal disservice for your customers.

How to make a WSGI request in Django?

A good trick (read: works with Django) is to call the entry-point function (like the WSGI callable) in the app itself: You may need to pass CGI vars to the environ to make a true request: it depends on the WSGI app. Please, turn on your brain and try to adapt shown configs to your needs, or invent new ones.

How do I avoid uWSGI from running on startup?

The main trick for avoiding it is: not closing the file descriptors mapped to the uWSGI daemon addresses and abusing the Unix fork () behaviour (read: file descriptors are inherited by default) to exec () the uwsgi binary again.


1 Answers

In the cited article, there is an special recommendation for Django and so apps: http://uwsgi-docs.readthedocs.io/en/latest/articles/TheArtOfGracefulReloading.html#dealing-with-ultra-lazy-apps-like-django

On some of my projects, there are a /warmup/ URL that loads everything that can be loaded upfront. The uWSGI does give client requests to the worker only after the whole wsgi.py of the project ran, so we do a fake call the /warmup/ url BEFORE the uWSGI tried to serve any real client requests:

# /django-project-root/wsgi.py
import sys
from django.core.wsgi import get_wsgi_application

application = get_wsgi_application()
(...)

# Django warm-up ahead of time instead of lazy
# From: http://uwsgi-docs.readthedocs.org/en/latest/articles/TheArtOfGracefulReloading.html#dealing-with-ultra-lazy-apps-like-django
#  And: https://github.com/stefantalpalaru/uwsgi_reload/blob/master/examples/wsgi.py#L19
application({
    'REQUEST_METHOD': 'GET',
    'SERVER_NAME': '127.0.0.1',
    'SERVER_PORT': 80,
    'PATH_INFO': '/warmup/',
    'wsgi.input': sys.stdin,
}, lambda x, y: None)

Please mind that if your uwsgi.ini configures lazy-apps=true then the process load will trigger only on client requests, so it will warmup only in case of an harakiri. Otherwise it will warmup fine.

like image 154
alanjds Avatar answered Sep 22 '22 23:09

alanjds