Multiple sets of scenarios to improve the concurrency processing capabilities of the Python web framework

Common Python deployment methods are:

FCGI: Generate a listener process for each project with a spawn-fcgi or framework, and then interact with the HTTP service

WSGI: Use the HTTP Service's MOD_WSGI module to run each project (the interface between a simple, general-purpose Web server for a Web application or framework).

Uwsgi is a php-cgi like listening to the same port, a unified management and load Balancing tool, UWSGI, neither WSGI protocol nor fcgi agreement, but created a uwsgi agreement, it is said that the agreement is about 10 times times as fast as the fcgi agreement.

In fact, WSGI is divided into the server and the framework (that is, application) two parts (and of course, middleware). Strictly speaking, WSGI is just a protocol that regulates the interfaces between the server and the framework.

WSGI server exposes the functionality of the servers to the WSGI interface. For example, Mod_wsgi is a server that provides Apache functionality in the form of a WSGI interface.

The WSGI framework is what we often refer to as the Django framework. It should be noted, however, that there are few simple WSGI frameworks, and the WSGI framework often comes with WSGI server. For example, Django, cherrypy with WSGI server primarily for testing purposes, the release of the use of the production environment WSGI server. And some WSGI under the framework such as pylons, BFG, etc., do not realize their own WSGI server. Use Paste as WSGI server.

Paste is a popular WSGI server with a lot of middleware. And Flup is also a library that provides middleware.

To get rid of WSGI server and application, the middleware is naturally clear. In addition to the session, cache and other applications, the previous period of time to see a BFG middleware dedicated to the Web site to change the skin (skin). There are many uses that middleware can think of.

Here's how a framework like Django runs on Apache in a fastcgi way. This is accomplished using flup.fcgi or fastcgi.py (Eurasia also designed a fastcgi.py implementation), which translates fastcgi protocol into a WSGI interface (turning fastcgi into a WSGI serve R) for frame access. The whole architecture is this: Django-> fcgi2wsgiserver-> mod_fcgi-> Apache.

Although I'm not a fan of WSGI, it's undeniable that WSGI is important to the Python web. Interested in the design of their own web framework, and do not want to do the socket layer and HTTP message resolution, students can begin to design their own framework from WSGI. There is a common understanding in Python circles that it is convenient to have a web frame that is as natural as drinking saliva. Maybe every Python player will go through a frame

The main features of Uwsgi are as follows:

Super fast performance.

Low memory footprint (measured at about half of the mod_wsgi of Apache2).

Multiple app management.

Detailed logging capabilities (which can be used to analyze app performance and bottlenecks).

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

Official Documents of UWSGI:

Http://projects.unbit.it/uwsgi/wiki/Doc

Nginx.conf

Location/{
  include uwsgi_params
  uwsgi_pass 127.0.0.1:9090
}

Start app

Uwsgi-s: 9090-w MyApp