Hosting in practice

So how does this all work in practice? Well as we saw with Flask, many frameworks come with their own built-in development web servers. However, these are not recommended for use in a production environment as they're generally not designed to be used where security and scalability are important.

Currently, probably the quickest way to host a Python web application with a production quality server is with the Gunicorn server. Using our Flask application from earlier, we can get it up and running using just a few steps. First we install Gunicorn:

$ pip install gunicorn

Next we need to slightly modify our Flask app so that it's use of __builtins__ works correctly under Gunicorn. In your tinyflaskapp.py file, find the line:

objs = __builtins__.__dict__.items()

Change it to:

objs = __builtins__.items()

Now we can run Gunicorn. From within your Flask application project folder, run the following command:

$ gunicorn --bind 0.0.0.0:5000 tinyflaskapp:app

This will launch the Gunicorn web server, listening on port 5000 on all available interfaces and serving our Flask application. If we now visit it in a web browser via http://127.0.0.1:5000, we should see our documentation index page. There are instructions to daemonize Gunicorn, so that it runs in the background and starts and stops automatically with the system, available in the documentation pages at http://gunicorn-docs.readthedocs.org/en/latest/deploy.html#monitoring.

Gunicorn uses the pre-fork process model described earlier. You can set the number of processes (Gunicorn calls them workers) using the -w command line option. The 'Design' section of the documentation contains details on determining the best number of workers to use, though a good place to start is (2 x $num_cores) + 1, where $num_cores is the number of CPU cores available to Gunicorn.

Gunicorn offers two standard worker types: sync and async. The sync type provides strictly one-worker-per-client-connection behavior, the async type uses eventlet (see Chapter 8, Client and Server Applications, for details and installation instructions for this library) to provide an event-based worker, which can handle multiple connections. The sync type is only recommended if you are using Gunicorn behind a reverse proxy (see below), as using the sync type to serve directly to the Internet leaves your application vulnerable to Denial of Service attacks (see the Design section of the documentation for more details). If you are not using a reverse proxy, the async type should be used instead. The worker type is set on the command line using the -k option.

One effective way to improve performance and scale further is to employ a fast, event-driven web server, such as nginx, as a reverse proxy in front of your Gunicorn instance. A reverse proxy acts as a first line server for incoming web requests. It directly responds to any requests it can determine are erroneous, and can also be configured to serve static content in place of our Gunicorn instance. However, it is also configured to forward any requests that do require dynamic content to our Gunicorn instance so our Python web application can handle them. In this way, we get the performance benefits of nginx to deal with the bulk of our web traffic, and Gunicorn and our web application can focus on delivering just the dynamic pages.

Note

Detailed instructions on configuring this reverse proxy configuration can be found on the Gunicorn pages at http://gunicorn-docs.readthedocs.org/en/latest/deploy.html#nginx-configuration.

If you're more comfortable with Apache, then another effective hosting method is Apache with the mod_wsgi module. This takes a little more configuring, and full instructions can be found at: https://code.google.com/p/modwsgi/. mod_wsgi defaults to running applications in embedded mode, where the web application is hosted in each Apache process, and which results in a setup like the preceding pre-forking example. Alternatively it provides a daemon mode, where mod_wsgi manages a pool of processes external to Apache, similar to the earlier FastCGI example. Daemon mode is in fact recommended for stability and memory performance. See the mod_wsgi quick configuration documentation for instructions on this configuration, it can be found at: https://code.google.com/p/modwsgi/wiki/QuickConfigurationGuide.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.222.110.183