[Original] Python Web deployment method summary, pythonweb

[Original] Python Web deployment method summary, pythonweb

Do not make the server streaking

I have learned from PHP, and the official php environment deployment is very simple. Just change a few files to OK. FastCgi is also a matter of minutes. In comparison, Python is deployed on web applications in a complicated manner, mainly because of a wide variety of tools and insufficient support for mainstream servers. Before learning about the deployment methods of Python production environments, we should clarify some concepts! Very important!

CGI:

CGI is the Common Gateway Interface. It is an Interface standard between an external application (CGI program) and a Web server. It is a procedure for transmitting information between a CGI program and a Web server. CGI specifications allow the Web server to execute external programs and send their output to the Web browser. CGI converts a simple set of static hypermedia documents on the Web into a complete new interactive media. Generally speaking, CGI is like a bridge. It connects the WEB page and the execution program on the WEB server, and passes the instructions received by HTML to the execution program on the server, then return the result of the server execution program to the HTML page. CGI provides excellent cross-platform performance and can be implemented on almost any operating system.

In CGI Mode, a connection request (user request) must first create a cgi sub-process, activate a CGI process, process the request, and end the sub-process after processing. This is the fork-and-execute mode. As a result, the number of connection requests to servers in the cgi Mode is limited to the number of cgi sub-processes. repeated loading of sub-processes is the main cause of low cgi performance. When the number of user requests is very large, a large amount of system resources such as memory and CPU time will be squeezed out, resulting in low efficiency.

CGI script workflow:

Python has a cgi module that supports native cgi programs.

FastCGI:

　　FastCGI is a scalable and fast interface for communication between HTTP server and dynamic scripting language. Most popular HTTP servers support FastCGI, including Apache, Nginx, and lighttpd. FastCGI is also supported by many script languages, including Python. FastCGI is improved from CGI development. The main disadvantage of the traditional CGI interface method is poor performance, because every time the HTTP server encounters a dynamic program, it needs to restart the script parser to execute the parsing, and then the result is returned to the HTTP server. This is almost unavailable when processing highly concurrent access. FastCGI is like a long-live CGI. It can be executed all the time, it will not take time to fork every time (this is the most criticized fork-and-execute mode for CGI ). CGI is a short-lived application, and FastCGI is a long-lived application. Because the FastCGI program does not need to constantly generate new processes, it can greatly reduce the pressure on the server and generate high application efficiency. Its speed efficiency is at least five times faster than CGI technology. It also supports distributed operations, that is, FastCGI programs can run on hosts other than website servers and receive requests from other website servers.

FastCGI is a CGI open extension in a language-independent and scalable architecture. Its main behavior is to maintain the CGI interpreter process in the memory and thus achieve high performance. As we all know, repeated loading of the CGI interpreter is the main cause of low CGI performance. If the CGI interpreter is kept in the memory and is scheduled by the FastCGI Process Manager, it can provide good performance, scalability, Fail-Over features, and so on. The FastCGI interface adopts the C/S structure, which can separate the HTTP server and the script parsing server, and start one or more script parsing Daemon Processes on the script parsing server. When the HTTP server encounters a dynamic program, it can be directly delivered to the FastCGI process for execution, and then the result is returned to the browser. This method allows the HTTP server to process static requests or return the results of the dynamic script server to the client, which greatly improves the performance of the entire application system.

FastCGI workflow:

FastCGI features:

WSGI:

　　The Python Web Server Gateway Interface (WSGI) is a simple and common Interface between a Web Server and a Web application or framework defined in the Python language. Since WSGI was developed, similar interfaces have also appeared in many other languages. WSGI is a low-level interface between a Web server and a Web application or application framework, to improve the commonality of Web application development that can be transplanted. WSGI is designed based on the existing CGI standards.

WSGI is divided into two parts: "server" or "Gateway", and "application" or "application framework ". When processing a WSGI request, the server will provide the application with the environment context and a Callback Function ). After the application completes processing the request, it uses the previous callback function to return the result to the server. The so-called WSGI middleware implements both APIs at the same time, so it can mediate between the WSGI service and the WSGI application: From the Perspective of the WSGI server, middleware acts as an application, from the application perspective, middleware acts as a server. The middleware component can perform the following functions:

In the past, how to select a suitable Web application framework became a problem for beginners of Python. This is because, in general, the selection of Web application frameworks limits the selection of available Web servers, and vice versa. At that time, Python applications were generally designed for one of CGI, FastCGI, and mod_python, or even for custom API interfaces of specific Web servers. WSGI has no official implementation because WSGI is more like a protocol. As long as these protocols are followed, WSGI applications can run on any Server, and vice versa. WSGI is the CGI package of Python, and is the CGI package of PHP compared to Fastcgi.

WSGI classifies web components into three types: web servers, web Middleware, web applications, and wsgi basic processing modes: WSGI Server-> (WSGI Middleware) *-> WSGI Application.

　　

Uwsgi:

The uwsgi protocol is a proprietary protocol of the uWSGI server. It defines the type of information transmitted. The first 4 bytes of each uwsgi packet are the description of the transmission information type, it is two different from WSGI. It is said that the efficiency is 10 times that of fcgi. For specific protocol content, refer to: the uwsgi protocol

The above four can be understood as the protocol! Protocol! Protocol! With this protocol, you can implement the Web service associated with the Web server and the web application!

UWSGI:

　　The uWSGI project is designed to develop a complete set of solutions for network applications deployed in Distributed clusters. UWSGI is mainly oriented to the web and its standard services and has been successfully applied to a variety of different languages. Because of the Scalable Architecture of uWSGI, it can be scaled unlimited to support more platforms and languages. Currently, you can use C, C ++, and Objective-C to write plug-ins. The "WSGI" in the project name is to express gratitude to the Python Web standard with the same name, because WSGI developed the first plug-in for the project. UWSGI is a Web server that implements the WSGI, uwsgi, http, and other protocols. UWSGI, neither the wsgi Protocol nor the FastCGI protocol, but created the uwsgi protocol described above.

UWSGI has the following features:

Gunicorn:

　　A tool similar to uWSGi is transplanted from the rails Deployment Tool (Unicorn. However, the Protocol used is the WSGI mentioned above. This is the official standard (PEP 333) defined in python2.5, And the deployment is simple. Click here for a detailed tutorial. Gunicorn adopts the prefork mode. The Gunicorn server is compatible with various Web frameworks and requires simple execution, lightweight resource consumption, and fast execution. It features tight integration with Django and convenient deployment. There are also many disadvantages. HTTP 1.1 is not supported, and the concurrent access performance is not high. There is a performance gap with uWSGI and Gevent.

1. Gunicorn Design

Gunicorn is a master process, with spawn serving as a web server for several worker processes. The master process controls the generation and elimination of work processes. The work process only needs to accept and process requests. This separation method makes reload code very convenient and easy to add or reduce worker processes. The working process author gives a lot of room for expansion. It supports different IO methods, such as Gevent, Sync synchronization process, Asyc asynchronous process, and Eventlet. The master and worker processes are completely separated, making Gunicorn essentially a service that controls processes.

2. Gunicorn source code structure

Starting from Application. run (), initialize the configuration, read the file, read the terminal, and so on. Then, Arbiter is started. Arbiter is the core of the master process. It reads and sets it from the configuration class, initializes the signal processing function, and establishes a socket. Then, start the spawn working process and perform the spawn based on the number of configured working processes. Then it enters the polling status, receives the signal, processes the signal, and continues. Here, the method to wake up the process is to create a PIPE, write to pipe through the signal processing function, and then the master wakes up from select. select.

The worker process starts initialization after spawn, then processes the signal, and starts polling to process the HTTP request, calls the WSGI application end, and returns the resopnse. Then proceed.

The benefit of the Sync synchronization process is that each request is separated, and each request failure will not affect other requests, but this leads to performance bottlenecks.

Tornado:

　　Even a python development framework, Tornado is also an asynchronous and non-blocking http server. Its data output implementation does not comply with some of the common protocols mentioned above, because it is a web server, therefore, dynamic requests are directly output into the dynamic content requested by the user through internal mechanisms. If you use it as a separate server and want to use it for deployment with other frameworks such as Flask, you need to use the WSGI protocol. Tornado has the built-in protocol tornado. wsgi. WSGIContainer.

Wsgiref:

　　The WSGI server that comes with Python implements the wsgi protocol. Wsgi server can be understood as a web server that complies with wsgi specifications. It receives request, encapsulates a series of environment variables, calls the registered wsgi app according to wsgi specifications, and finally returns response to the client. Django's built-in server is it.

The above can be understood as implementation! Implementation! Implementation! A tool for implementing the protocol!

Note: mod_wsgi (apache module) is actually a module that implements the wsgi protocol. It is almost no longer used, so I will not talk about it anymore. check it if you are interested.

Therefore, if you want to deploy your applications to the production environment after using the Django framework, you cannot use the uwsgi server that uses the uWSGI protocol, you can also use gunicorn or Tornado that implements WSGI, or Nginx, lighttpd, and apache servers in FastCGI and CGI modes. This is also true for other frameworks! After understanding these concepts, you can be aware of them when deploying them, and the combination of various tools will also "know and know why.

The projects in our group have two frameworks: Django and Tornado, and the production environment also uses two deployment methods. UWSGI and Gunicorn:

The Django project is deployed in Nginx + uWSGI mode, and the Tornado project is deployed in Nginx + Gunicorn mode:

Nginx is used for load balancing and static content forwarding. The Tornado project uses supervisord to manage Gunicorn and Gunicorn to manage Tornado. As we all know, due to the existence of Python GIL, the concurrency of Python adopts the multi-process mode, so we deploy a core two processes.