Which is the more popular way to deploy a Python-based WebApp to a WebServer?

Question

I only known WSGI,FCGI(FastCGI) and uWSGI. If you known other,please tell me. How the application status of the three way above-mentioned，which is more popular? Thanks.

Answer 1

You are confusing things.

WSGI is an API specification. It is itself not a way of deploying anything. A specific WSGI deployment mechanism would be an implementation of the WSGI specification bridging a Python web application adhering to the WSGI specification to a specific web hosting mechanism. This might be where the web application ends up being embedded within the same web server process, or where it communicates with a separate web server over a socket protocol.

FASTCGI is one instance of such a socket protocol used to communicate between a web application process and a web server. In the case of Python web applications, flup is one example of an implementation of a WSGI adapter bridging between FASTCGI and a Python web application. Another example of a socket protocol is SCGI.

uWSGI is an implementation which is actually an umbrella for hosting web applications in various languages. It can handle HTTP direct, but normally uses its own socket protocol called uwsgi (lower case) to communicate with a web server. One of the languages it supports via its plugin system is Python and so at that point it serves as an implementation of a WSGI adapter for its uwsgi protocol or HTTP when handling it direct.

As to what you probably intended to be the question, in the Python world the most popular WSGI deployment mechanisms are:

• Apache/mod_wsgi
• uWSGI
• gunicorn

Apache/mod_wsgi is the oldest and well regarded as being rock solid. Many people don't take the time to learn how to configure Apache properly for Python web applications and so don't get the most out of it, thus leading to a lot of wrong impressions about Apache. Be very suspicious of people who say Apache is slow and bloated. This simply shows they never setup Apache properly. One of the best ways to truly make Apache/mod_wsgi shine is to use it behind nginx. When using Apache/mod_wsgi, it is always best to use its daemon mode unless you truly know what you are doing.

The gunicorn server is a pure Python server and so is attractive for that reason. It is limited to single threaded synchronous worker though and doesn't support traditional multithreading. You therefore have to use multi process configurations which although that has benefits in CPU intensive tasks, for I/O bound tasks as one usually has for web applications means that it can use a lot more memory than a well configured Apache setup using multithreading and multiprocessing. One can also use a couple of couroutine based workers with gunicorn, but you have to be very careful using those and ensure that all your application code and modules you use are greenlet aware and will work with coroutines or you can have problems with single points blocking the whole process from doing anything.

Although using nginx in front of Apache/mod_wsgi is a really great combination, most people settle on uWSGI behind nginx. A problem with uWSGI can be that it has too many different ways of setting it up and its defaults aren't the best and you need to make sure certain options are used to make it more robust. The uWSGI code based still sees very rapid development and that has been an issue in the past with reliability. So make sure you aren't using an ancient version that comes with your Linux distribution, make sure you are using a recent version.

As to which is best, when setup properly, the performance differences between each shouldn't be that much. The bottlenecks are generally never going to be with the deployment mechanism unless you screwed up their configuration. The real bottlenecks will be in your web application, database and backend services.

So as a general rule, you are better to select one based on what your system administrators or yourself understand and think you can configure and manage the easiest. Try and ignore people who religiously try and steer you to their favourite as what may work for them isn't always going to work for you. For a serious site you need to properly evaluate what is going to be best and then dedicate a proper amount of effort to setting it up properly and not simply throwing it up and hoping for the best.

Now I haven't mentioned Tornado so far. Using WSGI on top of Tornado is not that good of a choice except for specific uses cases due to problems that can arise with running blocking WSGI on top of ASYNC Tornado. If you want to go with ASYNC APIs though instead of WSGI, then both Tornado and Twisted are reasonable choices. Writing to ASYNC APIs can be a lot more complicated though and you have to be careful in some cases with Tornado in particular if doing a lot of uploading of data due to how Tornado buffers request content for requests before it is handled.

One final point. In complicated systems it is entirely possible that you need to use multiple technologies. Do not assume you should use one technology for everything. Using WSGI web frameworks makes web application programming easier but the blocking nature of WSGI is not necessarily suitable for certain highly concurrent long polling type applications. You really need therefore to look at what different parts of a web application require and break it up and use appropriate technologies for each part and not just have one huge monolithic application in one technology that tries to do everything.

Answer 2

I would rather use Django + mod_wsgi. But another way is to use SSI. Just <!--#exec cmd="python script.py" -->