Summary of Python Web deployment methods

Don’t let the server run naked

Anyone who has studied PHP knows that the formal environment deployment of PHP is very simple. Just change a few files and it will be OK. Using FastCgi method is also a matter of minutes. In comparison, the deployment of Python in web applications is much more complicated, mainly due to the large number of tools and insufficient support from mainstream servers. Before understanding the production environment deployment method of Python, let’s clarify some concepts! Very important!

CGI：

CGI is Common Gateway Interface Interface) is an interface standard between external applications (CGI programs) and Web servers. It is a procedure for transferring information between CGI programs and Web servers. The CGI specification allows Web servers to execute external programs and send their output to Web browsers. CGI turns the Web's simple set of static hypermedia documents into a complete new interactive media. In layman's terms, CGI is like a bridge that connects the web page and the execution program in the WEB server. It passes the instructions received by HTML to the server's execution program, and then returns the results of the server's execution program to the HTML page. CGI The cross-platform performance is excellent and can be implemented on almost any operating system.

When the CGI method encounters a connection request (user request), it must first create a cgi sub-process, activate a CGI process, then process the request, and end the sub-process after processing. This is the fork-and-execute pattern. Therefore, a server using CGI will have as many CGI sub-processes as there are connection requests. Repeated loading of sub-processes is the main reason for low CGI performance. When the number of user requests is very large, a large amount of system resources such as memory, CPU time, etc. will be occupied, resulting in low performance.

CGI script workflow:

1. The browser requests a URL pointing to a CGI application through an HTML form or hyperlink.

2. The server executes the server to send and receive requests. The specified CGI application.

3. CGI applications perform required operations, usually based on input from the viewer.

4. CGI applications format the results into a document (usually an HTML web page) that web servers and browsers can understand.

5. The web server returns the results to the browser.

Python has a cgi module that can support native cgi programs

FastCGI:

FastCGI is a scalable, high-speed An interface for communication between HTTP servers and dynamic scripting languages. Most popular HTTP Servers all support FastCGI, including Apache, Nginx and lighttpd. At the same time, FastCGI is also supported by many scripting languages, including Python. FastCGI is developed and improved from CGI. The main disadvantage of the traditional CGI interface method is poor performance, because every time the HTTP server encounters a dynamic program, the script parser needs to be restarted to perform parsing, and then the results are returned to the HTTP server. This is almost unavailable when dealing with high concurrent access. FastCGI is like a long-live CGI. It can be executed all the time. As long as it is activated, it will not take time to fork every time (this is the most criticized fork-and-execute of CGI). model). CGI is the so-called short-lived application, and FastCGI is the so-called long-lived application. Thanks to FastCGI The program does not need to continuously generate new processes, which can greatly reduce the pressure on the server and produce higher application efficiency. Its speed efficiency is at least 5 times higher than CGI technology. It also supports distributed computing, namely FastCGI programs can execute on hosts other than the web server and accept requests from other web servers.

FastCGI is a language-independent, scalable architecture CGI open extension. Its main behavior is to keep the CGI interpreter process in memory and thus obtain higher performance. As we all know, repeated loading of the CGI interpreter is the main reason for low CGI performance. If the CGI interpreter remains in memory and accepts FastCGI process manager scheduling, it can provide good performance, scalability, Fail-Over features, etc. The FastCGI interface adopts a C/S structure, which can separate the HTTP server and the script parsing server, and start one or more script parsing daemons on the script parsing server. Every time the HTTP server encounters a dynamic program, it can be delivered directly to the FastCGI process for execution, and then the result is returned to the browser. This method allows the HTTP server to exclusively 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:

1. Load the FastCGI process manager (PHP-CGI or PHP-FPM or spawn-cgi) when the Web Server starts up

2. FastCGI process manager initializes itself, starts multiple CGI interpreter processes (visible multiple php-cgi) and waits for connections from the Web Server.

3. When a client request reaches the Web Server, the FastCGI process manager selects and connects to a CGI interpreter. Web The server sends CGI environment variables and standard input to the FastCGI subprocess php-cgi.

4. After the FastCGI sub-process completes processing, it returns standard output and error information to the Web from the same connection. Server. When the FastCGI child process closes the connection, the request is processed. The FastCGI child process then waits for and processes requests from the FastCGI process manager (running on the Web Server) next connection. In CGI mode, php-cgi exits here.

Features of FastCGI:

1. Breaks the traditional page processing technology. With traditional page processing technology, the program must communicate with the Web server or Application The servers are on the same server. This history has been broken by FastCGI technology N years ago. FastCGI technology applications can be installed on any server in the server farm, and through TCP/IP The protocol communicates with the web server, which is suitable for both the development of large distributed web groups and efficient database control.

2. Explicit request mode. CGI technology does not have a clear role in FastCGI In the program, the program is assigned a clear role (responder role, authenticator role, filter role).

WSGI：

Python Web Server Gateway Interface (abbreviated as WSGI) is a simple and common interface between a web server and a web application or framework defined for the Python language. Since WSGI was developed, similar interfaces have appeared in many other languages. WSGI serves as a low-level interface between a Web server and a Web application or application framework to improve the common ground for portable Web application development. WSGI is designed based on the existing CGI standard.

WSGI is divided into two parts: one is the "server" or "gateway", and the other is the "application" or "application framework". When processing a WSGI request, the server provides the application with an environment context and a callback function (Callback Function). When the application completes processing the request, the result is sent back to the server through the previous callback function. So-called WSGI Middleware implements both sides of the API and therefore mediates between the WSGI service and the WSGI application: from the perspective of the WSGI server, the middleware plays the role of the application, and from the perspective of the application, the middleware plays the role of the application. server. The "middleware" component can perform the following functions:

1. After rewriting the environment variables, the request message is routed to different application objects based on the target URL.

2. Allows multiple applications or application frameworks to run simultaneously in one process.

3. Load balancing and remoting by forwarding request and response messages across the network.

4. Perform content post-processing, such as applying XSLT style sheets.

In the past, how to choose a suitable web application framework has become a problem that troubles Python beginners. This is because, generally speaking, the choice of web application framework will limit the available web servers. choice and vice versa. Python applications back then were typically designed for one of CGI, FastCGI, mod_python, or even a custom API interface for a specific web server. There is no official implementation of WSGI, Because WSGI is more like a protocol. As long as these protocols are followed, WSGI applications can run on any server. vice versa. WSGI is the CGI wrapper of Python, compared to Fastcgi, which is the CGI wrapper of PHP.

WSGI divides web components into three categories: web server, web middleware, and web application. The basic processing mode of wsgi is: WSGI Server -> (WSGI Middleware)* -> WSGI Application.

uwsgi:

The uwsgi protocol is a uWSGI server's own protocol, which is used to define the type of transmitted information (type of information), each uwsgi The first 4 bytes of the packet are transmission information type descriptions, which are two different things compared to WSGI. It is said that its efficiency is 10 times that of fcgi. For specific protocol content, please refer to: the uwsgi protocol (http://uwsgi-docs.readthedocs.org/en/latest/Protocol.html)

The above four can be understood as protocols! protocol! protocol! By implementing such a protocol, you can implement web services associated with web servers and web applications!

uWSGI：

The uWSGI project aims to develop a complete solution for deploying distributed cluster network applications. uWSGI is mainly oriented to the web and its standard services, and has been successfully used in many different languages. Due to uWSGI's extensible architecture, it can be infinitely extended to support more platforms and languages. Currently, you can write plugins in C, C++, and Objective-C. The "WSGI" in the project name is a nod to the Python project of the same name. Web Standards thanks WSGI for developing the first plug-in for the project. uWSGI is a Web server that implements the WSGI protocol, uwsgi, http and other protocols. uWSGI neither uses the wsgi protocol nor the FastCGI protocol, but creates its own uwsgi protocol as mentioned above.

The main features of uWSGI are as follows:

1. Super fast performance.

2. Low memory usage (measured to be about half of mod_wsgi of apache2).

3. Multiple app management.

4. Detailed logging function (can be used to analyze app performance and bottlenecks).

5. Highly customizable (memory size limit, service restart after a certain number of times, etc.).

Gunicorn:

A tool similar to uWSGi, transplanted from the rails deployment tool (Unicorn). But the protocol it uses is the WSGI mentioned earlier, which is the official standard defined in python2.5 (PEP 333 ), the root is red, and the deployment is relatively simple. For detailed usage tutorials, please click here (http://gunicorn.org/). Gunicorn uses prefork mode, Gunicorn The server is compatible with various web frameworks, requires very simple execution, lightweight resource consumption, and is quite fast. It is characterized by tight integration with Django and particularly convenient deployment. There are also many shortcomings and it is not supported. HTTP 1.1, the concurrent access performance is not high, and there is a certain performance gap with uWSGI, Gevent, etc.

1. Gunicorn design

Gunicorn is a master process that spawns web servers of several worker processes. master The process controls the creation and death of the worker process. The worker process only needs to accept the request and process it. This separation makes reloading code very convenient and makes it easy to add or remove worker processes. The author of the work process has given a lot of room for expansion. It can support different IO methods, such as Gevent, Sync synchronous process, Asyc asynchronous process, Eventlet, etc. master follows The worker process is completely separated, making Gunicorn essentially a service that controls the process.

2. Gunicorn source code structure

Starting from Application.run(), first initialize the configuration, read from the file, read from the terminal, etc. to complete configure. then start Arbiter, Arbiter is essentially the core of the master process. It first reads and sets from the configuration class, then initializes the signal processing function and establishes the socket. Then it begins spawn worker process, spawn according to the configured number of worker processes. Then it enters the polling state, receives the signal, processes the signal and continues. The way to wake up the process here is to create a PIPE writes to the pipe through the signal processing function, and then the master wakes up from select.select().

After spawning, the working process starts to initialize, then processes the signal in the same way, and starts polling, processing HTTP requests, calling the WSGI application side, and getting the resopnse return. Then continue.

The advantage of the Sync synchronization process is that each request is isolated, and the failure of each request will not affect other requests, but this leads to a performance bottleneck.

Tornado：

Tornado is a python The development framework is also an asynchronous non-blocking http server. Its own data output implementation does not comply with some of the common protocols mentioned above. Because it is a web server, dynamic requests are directly output to users through the internal mechanism. The requested dynamic content. If you use it as a separate server and want to use it to deploy with other frameworks such as Flask, you need to use the WSGI protocol. Tornado has this protocol built in, tornado.wsgi.WSGIContainer.

wsgiref：

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

All of the above can be understood as implementation! accomplish! accomplish! Tools that implement the protocol!

Note: mod_wsgi (apache module) is actually a module that implements the wsgi protocol. It is almost not abandoned now, so I won’t say more. If you are interested, check it out yourself. .

So if you use the Django framework to develop an application and want to deploy it to a production environment, you definitely cannot use the one that comes with Django. You can use the uWSGI server that uses the uwsgi protocol, or you can use the WSGI protocol. gunicorn or Tornado, you can also use FastCGI, CGI mode Nginx, lighttpd, apache server. The same goes for other frameworks! Once you understand these concepts, you can be aware of them when deploying them, and you can "know what they are and why they are what they are" when matching various tools.

There are two frameworks, Django and Tornado, in our group's projects, and two deployment methods are also used in the production environment. uWSGI and Gunicorn:

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

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's GIL, Python's concurrency adopts multi-process mode, so our deployment method is one core and two processes.

The above is the summary of Python Web deployment methods. For more related content, please pay attention to the PHP Chinese website (m.sbmmt.com)!