uwsgi

                                      why not use mod_wsgi

wsgi can be regarded as a programming standard, not a socket protocol, it is a communication protocol different from fastcgi

There are two common ways to deploy Python web programs:

1. One is to use the server server that comes with the framework to call the wsgi interface to call our web app application. Because of our limited framework development capabilities, it is impossible to develop a set of very stable, load functions and other capabilities. All strong server servers can only be developed except for a simple test server server.

In production environment: This determines that we must deploy and use an external high performance server as the server for our python web app application.

2. Use the mod_wsgi module of various http servers to run and link various python web app applications. However, the mod_wsgi module has simple functions, cannot be monitored, the load capacity is not strong, the performance is not strong, and it occupies a lot of memory, and it is also very troublesome to configure. It can be understood that the personnel of this project team only developed such a module part-time, so The performance is not high, and it is not as strong as the functional module developed by professional developers of this interface module. This functional module is uWSGI .

uWSGI uses neither the wsgi nor the fcgi protocol, but has created a uwsgi protocol stack similar to php -cgi in PHP, which can monitor the same port uniformly, perform unified load balancing and management, improve performance and save money Deploying kung fu, and it is said that the protocol stack is about 10 times faster than the fcgi protocol. For a comparison, see the figure below.

 

Why do we use uWSGI (this is also a frequently asked question)

Because : because:

The goal of our uWSGI is: to be a complete web application deployment middleware that integrates various functions, it must have various levels, and its functions must include:

1. Process management
2. Automatic management of app tasks for a long-running web application ( various solutions are required for the stability of long-running web app tasks)

 

         3. uWSGI RPC Stack : uWSGI wants to include a complete remote call protocol stack.

         4.Clustering cluster function: can use the cluster function

1. LoadBalancing : Load Balancing: You can directly manage and call several apps .
2. Monitoring : Monitoring function: It has the monitoring function of each web app application.
3. Resource Limiting : Resource limiting function, such as load balancing calling several apps , you can limit their resources, such as network speed, limit the number of call requests per app unit time, which can improve the collection of several web apps . overall performance.

 

And some other annoying day-to-day tasks like you're delegating to external scripts and other tasks that require calling the system to see, like the previous monitoring functions.

 

So: if you are looking for a simple-to-use server for WSGI , PSGI or Rack protocol , uWSGI may not be suitable for you, then don't choose uWSGI . However, if you're building a robust, fast, easy-to-deploy deployment that works with a load-balanced deployment to achieve various performance optimizations, you may find yourself needing uWSGI .

 

uWSGI is best defined: the Swiss Army Knife of web applications.

 

What kind of agreement is this:

 

uwsgi is a new protocol derived from SCGI :

 

Can they be used in a cluster environment

 

Being able to use the cluster function is a main feature of the uWSGI protocol stack, we can deploy multiple instances on different servers, and use the load balancing device to your server / proxy / router, you can distribute your load. Like the uWSGI RPC remote call system, the stack system allows you to quickly call functions on remote nodes, and the uWSGI protocol stack system allows you to select a master node on multiple nodes for convenient configuration management.

 

Timeout setting

 

The timeout setting function is a key function to ensure the high availability of cluster nodes.

 

Uwsgi help:

 

uWSGI is a huge project with hundreds of functional options. You should be prepared that not everything will turn up in the first shot. Ask for help, ask for help, ask for help. If you're feeling down, don't waste time complaining about ranting - instead of simply joining the list and asking for help. It's open source, and if you're just complaining, you're not doing anything.

 

Please write your operating system, CPU architecture, web server, uWSGI version, uWSGI command line configuration options or command line configuration content.

 

Specifying your configuration file options is very helpful for us to find problems, either reinstalling or reconfiguring yourself.

 

Official website:

 

uWSGI has high performance, don't doubt his performance.

 

Does our application run faster with uWSGI ?

 

This is unlikely, the biggest bottleneck in the performance of a web application is the application itself. If you want a faster environment, optimize your code or use techniques like caching or clustering. When we say that uWSGI is fast, it means that it refers to a small information header in the information processing and scheduling structure when processing information.

 

What are the most critical parameters that affect performance and stability when uWSGI is configured?

 

The default configuration of uWSGI is already very good, if you want the performance to be more crazy, you can tune it down.

 

1. Increase or decrease delay time
2. Increase the thread function, if you don't need it, it's best not to open multi-threading.
3. If you're only running one app , it's best not to start multiple interpreters.
4. Be sure to start the main process in the production environment, see the chapter on Process Management Use.
5. Increasing the number of works processes does not necessarily increase performance, it depends on your machine performance, IO binding, CPU performance, etc.

 

Why not simply use the HTTP protocol

 

A simple answer is: HTTP parsing is slow, very slow. The web server has already parsed the http protocol, and there is already a high-performance http server. We don't need to parse and develop it again. The uWSGI protocol is very simple to parse a machine, and HTTP is very easy to parse a person. When humans are used as servers, we will drop the uWSGI protocol in support of the HTTP protocol. All that said, you can use uWSGI with native HTTP support, as well as FastCGI and ZeroMQ .

 

Why does uWSGI support multiple configuration methods:

 

uWSGI tries to give engineers as many options as possible to use a wide variety of environments, and since many infrastructure environments are already set up, having multiple configuration methods is just one way we can achieve this.

 

uwsgi supports a variety of servers, and he can also simply parse HTTP requests as an http server

 

 

 

1 First of all, nginx is an external service interface, and external browsers access nginx through url .

 

2nginx receives the http request sent by the browser, parses the package, and analyzes the url . If it is a static file request, it directly accesses the static file directory configured by the user for nginx , and directly returns the static file requested by the user.

 

  If it is not a static file, but a dynamic request, then nginx forwards the request to uwsgi. After uwsgi receives the request, it processes the packet into a format acceptable to wsgi, and sends it to wsgi , which calls the application according to the request. A certain file, a certain function of a certain file, and finally the return value will be handed over to wsgi again after processing, wsgi will package the return value into a format that uwsgi can receive, uwsgi receives the request sent by wsgi , and forwards it to nginx, nginx eventually returns the return value to the browser.

 

3 to know that the first level of nginx is not necessary, uwsgi can complete the entire process of interacting with the browser, but some situations must be considered

 

  1 Security issue, the program cannot be accessed directly by the browser, but only through nginx, nginx only opens a certain interface, uwsgi itself is an intranet interface, so that the operation and maintenance personnel can add security restrictions on nginx to protect the program effect.

 

  2 Load balancing problem, one uwsgi may not be enough, even if multiple jobs are opened , after all, the cpu and memory of a machine are limited, with nginx acting as a proxy, one nginx can proxy multiple uwsgi to complete uwsgi load balancing.

 

  3 The problem of static files, it is a waste to use django or uwsgi to process static files, and their processing of files is not as good as that of nginx , so the processing of the entire static file is directly completed by nginx , static File access does not go through uwsgi and everything behind it at all.