Discussion on Server Deployment of Python Project

Directory about Web server and application server
Python Project Deployment Architecture
About cgi, wsgi, uwsgi, http protocols
About cgi, fastcgi, php-fpm, FastCGI (additional)
About uWSGI, Nginx Server
uWSGI
Installation and deployment
Related documents
Configuration sample
Common commands
Service monitoring
Summarize

About Web Server and Application Server

Basic concepts:

The main function of Web server is to store, process and transfer web pages, and communicate between client and server based on HTTP protocol. The application server mainly deals with dynamic requests, calls corresponding objects to complete the processing of requests, and returns the response results.

The difference between the two:

Web server is mainly HTTP as the core, WEB UI as the wizard of the application, processing a number of static requests. Although the application server also supports the HTTP protocol, the application server can provide business logic for applications through many protocols.

Python Project Deployment Architecture

When we usually build an Python Web project, such as the Django framework project, the common server-side architecture at this time:

The Nginx server acts as a proxy server, which processes static resource requests (js, css, pictures) and dynamic requests (addition, deletion, modification and search) forwarding and returning processing results. The uWSGI server is responsible for receiving the Nginx server, forwarding the information to the Django application after processing, receiving the information returned by the Django application, and forwarding it to the nginx The Django application receives the request from the uWSGI server, calls the corresponding business logic, processes the data to render the corresponding page and returns it to the uWSGI server.

About cgi, wsgi, uwsgi, http protocols

Next, aiming at the deployment architecture of Django project mentioned above, let's talk about the role of these protocols in this process:

http protocol: The communication between client program and Nginx server is based on http protocol, while Nginx server, as a proxy server, will return static resources or forward dynamic requests according to HTTP requests. cgi protocol: cgi protocol is an interface standard between external application programs and Web server. In short, it stipulates how to communicate between a program and Web server programs. wsgi protocol: Based on the existing CGI standard design, an Python web framework written applications and Web server communication specification. uwsgi: Protocol unique to uWSGI servers for data communication between uWSGI servers and other Web servers

About cgi, fastcgi, php-fpm, FastCGI (additional)

CGI is a protocol for data exchange between Web Server and Web Application. FastCGI: Same as CGI, it is a communication protocol, but it is more efficient than CGI. Similarly, the SCGI protocol is similar to FastCGI. PHP-CGI: PHP (Web Application) is the interface program of CGI protocol provided by Web Server. PHP-FPM: PHP (Web Application) to Web Server provides FastCGI protocol interface procedures, but also provides relatively intelligent 1 some task management.

About uWSGI, Nginx Server

Simply put, uWSGI is also an Web server. Although it implements http, uwsgi and wsgi protocols at the same time, it is more used as an application server to communicate with applications.
Then there is a question here, why can uWSGI directly handle http requests and need Nginx servers? There are several reasons for this treatment:

First of all, Nginx server belongs to the role of proxy server in this process. Whenever an http request comes in, it needs to pass through Nginx server. The advantage of Nginx server lies in the asynchronous non-blocking network model, which can handle a large number of requests under the condition of single thread, aiming at handling static resource requests; For dynamic requests, it can be optimized through caching function and CDN, which can greatly reduce the load of the system and reduce the response time of the client. Secondly, Nginx server can load balance, enable multiple back-end servers, and allocate HTTP requests through Nginx, which can greatly optimize the efficiency of architecture and improve the processing performance. Finally, Nginx has a number of modules that support functions such as white list and black list, and cooperate with keepalive to achieve a highly available architecture.

In a word, Nginx servers have advantages over uWSGI in handling http requests, so Nginx+uWSGI is often used in daily deployment environments.

uWSGI

Installation and deployment

uWSGI is installed in two ways, one is installed through pip and one is installed through source code. Here is a brief introduction to the pip installation, source installation interest can be privately understand their own.

pip install uwsgi

Related documents

The following files are mainly involved in the startup process of uWSGI server, among which uwsgi. sock will also involve the deployment problems related to Nginx, and we will continue to talk about it when Nginx is configured.

(venv) [root@mbb-48 uwsgi]# tree .
.
|-- uwsgi.ini       # uwsgi Configuration file 
|-- uwsgi.log       # uwsgi Log file 
|-- uwsgi.pid       # uwsgi Running process pid
|-- uwsgi.sock      # uwsgi socket
`-- uwsgi.status    # uwsgi Status file 

Configuration sample

The following configuration is used in my 1 project, in which the configuration parameters are more common.

[uwsgi]
chdir=/data/Novel/novel_test
module=novel_test.wsgi:application
home=/data/Novel/venv
static-map=/static=/data/Novel/novel_test/static
threads=8
http=0.0.0.0:23606
master=true
vacuum=true
thunder-lock=true
uid=root
gid=root
harakiri=30
post-buffering=4096
socket=%(chdir)/uwsgi/uwsgi.sock
stats=%(chdir)/uwsgi/uwsgi.status
pidfile=%(chdir)/uwsgi/uwsgi.pid
daemonize=%(chdir)/uwsgi/uwsgi.log

Configuration resolution

chdir: Defining a catalog for a project module: The WSGI module to be used is also used in different Python web frameworks in different ways. home: Specifies the Python execution environment. This parameter is for different Python runtime environments, such as virtualenv creating a separate Python environment. static-map: Mapping static directories threads: Number of threads http: Specify startup address and port master: Enable the main process vacuum: When exiting, clean up the generated intermediate files (sock, pid, stats) thunder-lock: Serializing Received Content uid: Specify the startup user gid: Specify Startup Group harakiri: Setting Server Response Time post-buffering: Enable buffering socket: socket file storage path stats: stats file storage path pidfile: pid file storage path daemonize: Log file output file path

Additional configuration

processes: Number of processes buffer-size: Setting buffer size listen: Set Listening Queue Size (Default 100) max-requests: Maximum maximum per worker process request procname-prefix-spaced: Prefix name of worker process wsgi-file: Specifies that the WSGI file is loaded

Common commands

The above describes the relevant commonly used configuration parameters, when the uWSGI parameters, you need to start the specified configuration file, as well as the actions related to pause and restart.

uwsgi --ini uwsgi.ini   #  Start uWSGI
uwsgi --stop uwsgi.pid  #  Suspend uWSGI
uwsgi --reload uwsgi.pid    #  Restart uWSGI

Service monitoring

The 1Stats server mechanism of uWSGI, which can export uWSGI status as an JSON object to an socket, only need to configure uWSGI configuration file 1 as before, add stats option, followed by a valid socket address interface.

When you are configured, you can connect to the specified socket address through the client, and you will get an JSON object containing the internal statistics of uWSGI.

uwsgi --connect-and-read uwsgi.status

After executing this command, the result of reading is an json string, which includes detailed information such as the state of each thread, the load of the whole application, the version, and the listening queue.

uwsgitop View Real-Time Status
uwsgitop is an open source tool for monitoring the status of uWSGI servers in real time, and it is easy to install:

pip install uwsgitop

Specific uwsgitop is like an top command, which listens to the application program and uses socket address to call, view the running status of the process and run details:

uwsgitop uwsgi/uwsgi.status
uwsgi-2.0.19.1 - Sun Sep 20 15:58:48 2020 - req: 6 - RPS: 0 - lq: 0 - tx: 67.6K
node: mbb-48 - cwd: /data/Novel/novel_test - uid: 0 - gid: 0 - masterpid: 15109
 WID    %       PID     REQ     RPS     EXC     SIG     STATUS  AVG     RSS     VSZ     TX      ReSpwn  HC      RunT    LastSpwn
 1	100.0   15144   6	0	0	0	idle    15ms    0	0	67.6K   1	0	125.449 15:48:08
  :2    16.7    -	1	0	-	-	idle    -	-	-	-	-
  :3    16.7    -	1	0	-	-	idle    -	-	-	-	-
  :0    33.3    -	2	0	-	-	idle    -	-	-	-	-
  :1    33.3    -	2	0	-	-	idle    -	-	-	-	-

For students who are interested, please refer to github address:

https://github.com/xrmx/uwsgitop

Summarize

The related use of uWSGI server is summarized here, because it is often encountered in normal work, but because it has not been applied to some high concurrency scenarios, there is not much experience in uwsgi tuning, and we will continue to summarize the performance tuning problems after encountering such problems in the future. At the same time, the configuration of Nginx will be left to the next article, which will not be continued. . . . .

The above is to talk about Python project server deployment details, more about python server deployment information please pay attention to other related articles on this site!