Analysis of the running mode and processing process of Python Django framework, pythondjango

Analysis of the running mode and processing process of Python Django framework, pythondjango

I have read some articles on Django's request processing process and Django source code structure on the Internet. I think it is very helpful to understand these content for developing Django projects. Therefore, I summarized the running method of the Django project and the basic Request processing process according to my own logic.

1. Django Running Mode

There are many ways to run Django projects. Here we will mainly introduce the common methods. One method is often used in development and debugging, and Django's own web server is used. The other is to run Django projects using protocols such as fastcgi and uWSGIt. Here we use uWSGIt as an example.

1. runserver Method

The runserver method is often used to debug Django. It runs with the built-in WSGI Server of Django and is mainly used in testing and development. The usage is as follows:

Usage: manage.py runserver [options] [optional port number, or ipaddr:port]# python manager.py runserver  # default port is 8000# python manager.py runserver 8080# python manager.py runserver 127.0.0.1:9090

Looking at the source code of manager. py, you will find that the above Command actually runs the internal runserver command through the execute_from_command_line method of Django. Now let's take a look at what the runserver has done ..

After reading the source code, we can find that the runserver command mainly does two things:

1) parse the parameters and obtain wsgi handler through django. core. servers. basehttp. get_internal_wsgi_application;

2) generate a WSGIServer object based on ip_address and port to accept user requests.

The source code of get_internal_wsgi_application is as follows: def get_internal_wsgi_application (): "" Loads and returns the WSGI application as configured by the user in ''settings. WSGI_APPLICATION ''. with the default ''startprojec'' layout, this will be the ''application' object in ''projectname/wsgi. py ''. this function, and the ''wsgi _ application' 'setting itself, are only useful for Django's internal servers (runserver, runfcgi ); external WSGI servers shoshould just be configured to point to the correct application object directly. if settings. WSGI_APPLICATION is not set (is ''none'), we just return whatever ''django. core. wsgi. get_wsgi_application ''returns. "from django. conf import settings app_path = getattr (settings, 'wsgi _ application') if app_path is None: return get_wsgi_application () return import_by_path (app_path, error_prefix = "WSGI application '% s' cocould not be loaded;" % app_path)

Through the above code, we can know that Django will first obtain handler according to WSGI_APPLICATION in settings; during project creation, Django will create a wsgi by default. and the WSGI_APPLICATION configuration in settings also points to this file by default. Take a look at this wsgi. py file. In fact, it is the same as the above logic, and finally calls get_wsgi_application to implement it.

2. uWSGI Method

The uWSGI + Nginx method is the most common method for running Django in the production environment. My blog also uses this method for running. You need to understand this method, first, you need to understand the WSGI and uWSGI protocols.

WSGI, short for Web Server Gateway Interface or Python Web Server Gateway Interface, is a simple and common Interface between the Web Server and Web application or framework defined for the Python language, based on the existing CGI standards. WSGI is actually a Gateway, and its function is to convert between protocols. (PS: here we will only give a brief introduction to WSGI. You can search for more information by yourself)

UWSGI is a Web server that implements the WSGI, uwsgi, http, and other protocols. Note that uwsgi is a communication protocol, while uWSGI is a Web server that implements the uwsgi protocol and WSGI protocol. UWSGI features ultra-fast performance, low memory usage, and multi-app management. Taking my blog as an example, the xml configuration of uWSGI is as follows:

<Uwsgi> <! -- Port --> <socket>: 7600 </socket> <stats>: 40000 </stats> <! -- System environment variable --> <env> DJANGO_SETTINGS_MODULE = geek_blog.settings </env> <! -- Specify the python WSGI module --> <module> django. core. handlers. wsgi: WSGIHandler () </module> <processes> 6 </processes> <master/> <master-as-root/> <! -- Timeout settings --> 
The above is the uWSGI xml configuration method, you can also use the ini method. Run the following command to install uWSGI:

sudo pip install uwsgiuwsgi --pidfile=/var/run/geek-blog.pid -x uwsgi.xml --uid blog --gid nogroup
The configuration methods used by uWSGI and Nginx are not described here. There are many online tutorials and you can search for them by yourself.

Ii. HTTP request processing process
Like other Web frameworks, Django basically processes HTTP in a similar way: accepting requests and returning response content. The specific process of Django is roughly as follows:
1. Load project settings
Django automatically generates default settings files and manager. py files when creating a project through the django-admin.py, and the following references are executed before WSGIServer is created:
From django. conf import settings
The above reference reads the configuration of DJANGO_SETTINGS_MODULE iN OS. environ during execution, loads the project configuration file, and generates the settings object. Therefore, you can see in the manager. py file that the settings path of the project will be added to the OS path before obtaining WSGIServer.
2. Create a WSGIServer
Whether running the Django project using runserver or uWSGI, django is called at startup. core. servers. the run () method in basehttp to create a django. core. servers. basehttp. WSGIServer class instance, and then call its serve_forever () method to start the HTTP service. The source code of the run method is as follows:

def run(addr, port, wsgi_handler, ipv6=False, threading=False):  server_address = (addr, port)  if threading:    httpd_cls = type(str('WSGIServer'), (socketserver.ThreadingMixIn, WSGIServer), {})  else:    httpd_cls = WSGIServer  httpd = httpd_cls(server_address, WSGIRequestHandler, ipv6=ipv6)  # Sets the callable application as the WSGI application that will receive requests  httpd.set_app(wsgi_handler)  httpd.serve_forever()
As shown above, the Handler of the HTTP request is specified when the WSGIServer instance is created. The above Code uses WSGIRequestHandler. When a user's HTTP request arrives at the server, WSGIServer will create a WSGIRequestHandler instance and use its handler method to process the HTTP request (in fact, the run method in wsgiref. handlers. BaseHandler is called for processing ). WSGIServer uses the set_app method to set a callable object as the application. The handler method mentioned above will call the Set application to process the request and return response.
WSGIServer inherits from wsgiref. simple_server.WSGIServer, while WSGIRequestHandler inherits from wsgiref. simple_server.WSGIRequestHandler. wsgiref is the reference implementation of WSGI provided by the Python standard library. You can refer to wsgiref for its source code.
3. process the Request
The application mentioned in step 2 is generally Django in django. core. handlers. wsgi. WSGIHandler object. WSGIHandler inherits from django. core. handlers. base. baseHandler, which is the core logic of Django to process requests. It creates a WSGIRequest instance, while WSGIRequest is from http. inherited by HttpRequest
4. Return Response
The BaseHandler mentioned above has a get_response method. This method first loads the ROOT_URLCONF of the Django project, and then finds the corresponding view method (class) according to the url rule ), the view logic generates and returns the specific response according to the request instance.
After Django returns the result, the wsgiref. handlers. BaseHandler. run method mentioned in step 2 will call finish_response to end the request and return the content to the user.

Iii. Detailed process for Django to process requests
The logic in the third and fourth steps just roughly describes the processing process. Django actually did a lot of things when processing the request. Let's take a look at it in detail below. First, we will share with you the Django flowchart on the two web pages:


Django flowchart 1


Django flowchart 2
The two flowchart above can roughly describe Django's request processing process. According to the annotation in flowchart 2, it can be divided into the following steps:
1. the user requests a page through a browser
2. When a Request arrives at the request Middlewares, middleware processes the Request or directly responds to the request.
3. URLConf uses the urls. py file and the requested URL to find the corresponding View.
4. View Middlewares is accessed. It can also process the request or directly return response
5. Call the function in View
6. The methods in the View can selectively access the underlying data through Models.
7. All Model-to-DB interactions are completed through manager.
8. If needed, Views can use a special Context
9. The Context is passed to the Template to generate a page.
A. The Template uses Filters and Tags to render the output.
B. The output is returned to the View.
C. HTTPResponse is sent to Response Middlewares
D. Any Response Middlewares can enrich response or return a completely different response.
E. Response: Return to the browser and present it to the user
The most important parts of the above process are: Middleware (Middleware, including request, view, exception, response), URLConf (url ing relationship), Template (Template system ), next we will introduce it one by one.
1. Middleware (Middleware)
Middleware is not unique to Django. It is also found in other Web frameworks. In Django, Middleware can penetrate into four stages of the processing process: request, view, response, and exception. Correspondingly, rocess_request, process_view are available in each Middleware class, process_response and process_exception methods. You can define any one of the multiple active methods, depending on which processing stage you want the Middleware to act on. Each method can directly return the response object.
Middleware is loaded when the load_middleware method of Django BaseHandler is executed. After loading, four lists are created as the instance variables of the processor:

 
 
 
  
_ Request_middleware: List of process_request Methods
 
 
  
_ View_middleware: List of process_view Methods
 
 
  
_ Response_middleware: List of process_response Methods
 
 
  
_ Exception_middleware: List of process_exception Methods

 
Django's middleware is defined in the MIDDLEWARE_CLASSES tuples in its configuration file (settings. py. In MIDDLEWARE_CLASSES, the middleware component is represented by a string: the complete Python path pointing to the middleware class name. For example, configure the GeekBlog project:

MIDDLEWARE_CLASSES = ('django. middleware. cache. updateCacheMiddleware ', 'django. middleware. common. commonMiddleware ', 'django. middleware. cache. fetchFromCacheMiddleware ', 'django. contrib. sessions. middleware. sessionMiddleware ', 'django. middleware. csrf. csrfViewMiddleware ', 'django. contrib. auth. middleware. authenticationMiddleware ', 'django. contrib. messages. middleware. messageMiddleware ', 'django. middleware. locale. localeMiddleware ', 'geek _ blog. middlewares. mobileDetectionMiddleware ', # custom Middleware)
The installation of the Django project does not require any middleware. If you want to, MIDDLEWARE_CLASSES can be empty. The order in which the middleware appears is very important: in the request and view processing phase, Django applies the middleware in the Order in MIDDLEWARE_CLASSES, while in the response and exception Handling phases, django calls them in reverse order. That is to say, Django regards MIDDLEWARE_CLASSES as the sequential packaging sub-of the outer layer of the view function: In the request stage, it passes from top to bottom, while in the response, it returns. The following two images can help you better understand:


Django Middleware process 1


Django Middleware flowchart 2
2. URLConf (URL ing)
If none of the middleware processing the request directly returns response, Django will parse the URL of the user request. URLconf is the directory of the website supported by Django. It is essentially a ing table between the URL mode and the view functions to be called for this URL mode. In this way, you can tell Django to call this code for this URL and that code for that URL. Specifically, the configuration file of the Django project contains the ROOT_URLCONF constant. This constant is added with the root directory "/" as a parameter to create django. core. urlresolvers. regexURLResolver instance, and then parse the URL of the user request through its resolve method to find the first matched view.
For more information about URLConf, see DjangoBook.
3. Template)
Most web frameworks have their own Template systems, and so does Django. However, unlike the Mako template and jinja2 template, the Django template cannot directly write Python code, but can only be implemented by defining an additional filter and template tag. Since this article mainly introduces the Django process, the template content is not much described.


PS: The above code and content are based on Django 1.6.5. Other versions may be different from each other. Please refer.

Over!