Introduction to WSGI Servers: Part One
This article is a translation of Kevin Goldberg’s “An Introduction to Python WSGI Servers: Part 1” article blog.appdynamics.com/engineering/an-introduction-to-python-wsgi-servers-part-1 with minor additions from the translator
WSGI servers appeared because web servers at that time could not interact with applications written in Python. WSGI ( pronounced “whiz-gee” with a solid “g” ) was developed by Philip J. Eby (along with Ian Bicking and others) in the early 2000s. The Apache module, known as mod_python , developed by Gregory Trubetskim in the late 1990s, at that time processed most of the Python applications. However, mod_python was not an official specification. It was simply created so that developers can run Python code on the server. Unfortunately, this approach was unsafe and developers began to look for a new solution.
')
WSGI (Web Server Gateway Interface) is a descendant of CGI (Common Gateway Interface). When the web began to evolve, CGI expanded due to the support of a huge number of languages and the lack of other solutions. However, such a decision was slow and limited. WSGI was designed as an interface for routing requests from web servers (Apache, Nginx, etc.) to web applications.
In the simplest case, WSGI consists of two main entities:
The web server executes the code and sends the information related to the http request and the callback function to the web application. Then the request on the application side is processed and a response is sent to the web server.
Periodically, there is one or more intermediate layers between the web server and the web application. Such layers allow, for example, balancing between several web applications or preprocessing (preprocessing) the content that is sent.
Here are some examples of frameworks that support WSGI:
You might ask, “Okay, but why WSGI?” . There are several reasons for this:
WSGI servers are available in various variations. Some are focused on a fullstack solution, while others are well suited for specific frameworks. For example, Gunicorn works with Django right out of the box. Here is a closer look at the six WSGI servers on the market today: Bjoern , uWSGI , mod_wsgi , Meinheld , CherryPy and Gunicorn .
Bjoern is an asynchronous WSGI server written in C. Written from scratch to be small and fast, it was developed using http_parser from Ryan Dahl (creator of Node.js) and the Libev event cycle from Mark Lehmann.
With a download size of only 18 KB, it consists of less than 800 lines of code. It takes up less than 1 MB of RAM and does not use cortutina or streams. Bjoern is fully compatible with WSGI and is considered one of the most high-performance WSGI servers.
Bjoern supports persistent connections and can bind to Unix sockets or TCP addresses. Bjoern is considered faster than Gunicorn and less bloated than uWSGI and Meinheld . One of the drawbacks of this server is the lack of normal documentation with clear examples.
uWSGI was developed by Unbit (Italy) with the goal of becoming a fullstack solution capable of creating hosting services. It is named after the WSGI standard and was created as a plugin for one of the company's projects.
A wide and constantly developing project, uWSGI allows you to do much more than web applications for hosting. Many find uWSGI a powerful tool, while others find it somewhat bloated. Starting with version 2.0, uWSGI also supports launching web applications in Lua, Perl, Ruby and others.
mod_wsgi is an Apache HTTP server module developed by Graham Dumplton (previously, one of the mod_python developers) that provides the WSGI interface for web applications. Compatible with versions of Python2 and Python3. Created as an alternative to other web application integration solutions such as CGI , FastCGI and mod_python . It can be installed as an Apache module or via the mod_wsgi express . The second way simplifies installation for Python developers who are not so familiar with Apache. Other benefits:
• You do not need root-rights with a full installation.
• A local environment is created, which reduces the risk of negative impact on existing settings.
The development of mod_wsgi as a project may seem slow due to the fact that the module is developed by one developer. Another disadvantage is that the documentation is currently poorly organized and may be outdated.
Currently, the focus is on simplifying Apache implementation using mod_wsgi in Docker environments.
Created by Yutaka Matsubara, Meinheld is a WSGI- compliant server that uses the power of picoev and greenlet to perform asynchronous I / O operations. It can be used with a standalone HTTP server or via Gunicorn .
Meinheld has a dependency on a third-party component called greenlet.
The source code repository is located on GitHub . Meinheld supports web sockets and includes several monkeypatches over other modules for enhanced functionality.
CherryPy - better known as a minimalistic Python-based framework for writing web applications, CherryPy also comes with a WSGI thread-pooled web server and support for the HTTP / 1.1 protocol. The CherryPy development team describes its web server as a production-ready, high-speed, thread-pooled HTTP server. He has:
• Quick, easy setup;
• Scalable;
• Small and easy to use solution for your Python applications;
• SSL support.
CherryPy distinguishes itself from the more well-known WSGI servers due to its ease of use and convenience for developers. You can write a small web application within a few minutes by running it in several processes and creating only one file called server.py. By combining CherryPy with Nginx as a proxy server, you will get a reliable way to serve your web applications. CherryPy was created by Remy Delon. He wanted to create a structure that would be as close as possible to the main principles of development in the Python language .
Gunicorn is a WSGI server created for use on UNIX systems. The name is an abbreviated and combined version of the words "Green Unicorn". On the project site itself there is a green unicorn. Gunicorn was moved from the Unicorn project from Ruby. It is relatively fast, resource-intensive, easy to run and works with a wide range of web frameworks.
The development team recommends using Gunicorn in conjunction with Nginx, where Nginx is used as a proxy server.
In this article, six of the most popular WSGI servers at the moment were dismantled: Bjoern , uWSGI , mod_wsgi , Meinheld , CherryPy and Gunicorn . Which server you use depends on the conditions and requirements for your application. The next part will analyze the performance of these six WSGI servers.
A Brief History of WSGI Python Servers
WSGI servers appeared because web servers at that time could not interact with applications written in Python. WSGI ( pronounced “whiz-gee” with a solid “g” ) was developed by Philip J. Eby (along with Ian Bicking and others) in the early 2000s. The Apache module, known as mod_python , developed by Gregory Trubetskim in the late 1990s, at that time processed most of the Python applications. However, mod_python was not an official specification. It was simply created so that developers can run Python code on the server. Unfortunately, this approach was unsafe and developers began to look for a new solution.
')
WSGI (Web Server Gateway Interface) is a descendant of CGI (Common Gateway Interface). When the web began to evolve, CGI expanded due to the support of a huge number of languages and the lack of other solutions. However, such a decision was slow and limited. WSGI was designed as an interface for routing requests from web servers (Apache, Nginx, etc.) to web applications.
Server and web application
In the simplest case, WSGI consists of two main entities:
- Web server ( Nginx, Apache , etc.);
- A web application written in Python.
Principle of operation:
The web server executes the code and sends the information related to the http request and the callback function to the web application. Then the request on the application side is processed and a response is sent to the web server.
Periodically, there is one or more intermediate layers between the web server and the web application. Such layers allow, for example, balancing between several web applications or preprocessing (preprocessing) the content that is sent.
Here are some examples of frameworks that support WSGI:
Why WSGI?
You might ask, “Okay, but why WSGI?” . There are several reasons for this:
- WSGI servers were designed to handle multiple requests at the same time. And the frameworks are not intended for processing thousands of requests and do not provide a solution for how to best route them (requests) from a web server.
- WSGI accelerates the development of web applications written in Python. If you are developing a web application using a framework (Django or something else), you do not need to worry about how your particular infrastructure uses the WSGI standard.
- WSGI gives you the flexibility to change the components of a web stack without changing the application that works with WSGI .
WSGI servers are available in various variations. Some are focused on a fullstack solution, while others are well suited for specific frameworks. For example, Gunicorn works with Django right out of the box. Here is a closer look at the six WSGI servers on the market today: Bjoern , uWSGI , mod_wsgi , Meinheld , CherryPy and Gunicorn .
Bjoern
Bjoern is an asynchronous WSGI server written in C. Written from scratch to be small and fast, it was developed using http_parser from Ryan Dahl (creator of Node.js) and the Libev event cycle from Mark Lehmann.
With a download size of only 18 KB, it consists of less than 800 lines of code. It takes up less than 1 MB of RAM and does not use cortutina or streams. Bjoern is fully compatible with WSGI and is considered one of the most high-performance WSGI servers.
Bjoern supports persistent connections and can bind to Unix sockets or TCP addresses. Bjoern is considered faster than Gunicorn and less bloated than uWSGI and Meinheld . One of the drawbacks of this server is the lack of normal documentation with clear examples.
uWSGI
uWSGI was developed by Unbit (Italy) with the goal of becoming a fullstack solution capable of creating hosting services. It is named after the WSGI standard and was created as a plugin for one of the company's projects.
A wide and constantly developing project, uWSGI allows you to do much more than web applications for hosting. Many find uWSGI a powerful tool, while others find it somewhat bloated. Starting with version 2.0, uWSGI also supports launching web applications in Lua, Perl, Ruby and others.
mod_wsgi
mod_wsgi is an Apache HTTP server module developed by Graham Dumplton (previously, one of the mod_python developers) that provides the WSGI interface for web applications. Compatible with versions of Python2 and Python3. Created as an alternative to other web application integration solutions such as CGI , FastCGI and mod_python . It can be installed as an Apache module or via the mod_wsgi express . The second way simplifies installation for Python developers who are not so familiar with Apache. Other benefits:
• You do not need root-rights with a full installation.
• A local environment is created, which reduces the risk of negative impact on existing settings.
The development of mod_wsgi as a project may seem slow due to the fact that the module is developed by one developer. Another disadvantage is that the documentation is currently poorly organized and may be outdated.
Currently, the focus is on simplifying Apache implementation using mod_wsgi in Docker environments.
Meinheld
Created by Yutaka Matsubara, Meinheld is a WSGI- compliant server that uses the power of picoev and greenlet to perform asynchronous I / O operations. It can be used with a standalone HTTP server or via Gunicorn .
Meinheld has a dependency on a third-party component called greenlet.
The source code repository is located on GitHub . Meinheld supports web sockets and includes several monkeypatches over other modules for enhanced functionality.
Cherrypy
CherryPy - better known as a minimalistic Python-based framework for writing web applications, CherryPy also comes with a WSGI thread-pooled web server and support for the HTTP / 1.1 protocol. The CherryPy development team describes its web server as a production-ready, high-speed, thread-pooled HTTP server. He has:
• Quick, easy setup;
• Scalable;
• Small and easy to use solution for your Python applications;
• SSL support.
CherryPy distinguishes itself from the more well-known WSGI servers due to its ease of use and convenience for developers. You can write a small web application within a few minutes by running it in several processes and creating only one file called server.py. By combining CherryPy with Nginx as a proxy server, you will get a reliable way to serve your web applications. CherryPy was created by Remy Delon. He wanted to create a structure that would be as close as possible to the main principles of development in the Python language .
Gunicorn
Gunicorn is a WSGI server created for use on UNIX systems. The name is an abbreviated and combined version of the words "Green Unicorn". On the project site itself there is a green unicorn. Gunicorn was moved from the Unicorn project from Ruby. It is relatively fast, resource-intensive, easy to run and works with a wide range of web frameworks.
The development team recommends using Gunicorn in conjunction with Nginx, where Nginx is used as a proxy server.
Conclusion
In this article, six of the most popular WSGI servers at the moment were dismantled: Bjoern , uWSGI , mod_wsgi , Meinheld , CherryPy and Gunicorn . Which server you use depends on the conditions and requirements for your application. The next part will analyze the performance of these six WSGI servers.
Source: https://habr.com/ru/post/426957/
All Articles