Python Web Frameworks Excessive Complexity

Cyclomatic (or conditional) complexity is a metric used to indicate the complexity of a source code. In this post we will take a look at web frameworks source code and estimate excessive complexity, something that is beyond recommended level of 10 (threshold that points to the fact the source code is too complex and refactoring is suggested). Here is a list of web frameworks examined:

1. bottle
2. cherrypy
3. circuits
4. django
5. falcon
6. flask
7. pyramid
8. pysi
9. tornado
10. turbogears
11. web.py
12. web2py
13. webapp2
14. wheezy.web

The source code is hosted on bitbucket, let clone it into some directory and setup virtual environment (this will download source code per framework listed above).

hg clone https://bitbucket.org/akorn/helloworld
cd helloworld/04-pep8 && make env up

The make file has a target for mccabe metric, so issue make mccabe.

Python Web Caching Benchmark

Content caching is the most effective type of cache. This way your web handler is not executed to determine a valid response to user, instead one returned from cache. Since the operation is that simple, it should be the maximum possible speed your `real world` application capable to provide. There are several use cases when content caching is applicable:

• Site: the site content is changed rarely. The best case scenario is nginx+wsgi caching facilities, see more here.
• Handler: the site content caching policy vary, there are only few handlers were content caching is applicable.
• Managed (semi-real time): the site is dynamic, it is not permissible to cache a given output unless there is a way to invalidate content since some data changed, e.g. item price, new message arrived, etc. Read more here or give it a try.

How python web frameworks respond to this challenge? Only few (per documentation on official web site):

1. django 1.4.2
2. flask 0.9
3. wheezy.web 0.1.307

Web content caching benchmark is provided for two types of caching: memory and distributed. The cached content size is 8890 bytes (with applied gzip transform the content size down to 1086 bytes).

Python Templates Benchmark

Python template engines offer high reusability of markup code and the following features are used by content developers most of the time:

• Includes: useful to incorporate some snippets of content that in most cases are common to the site, e.g. footer, scripts, styles, etc.
• Extends: useful to define a master layout for the majority of the site content with placeholders, e.g. sidebar, horizontal menu, content, etc. The content developers extend the master layout by substituting available placeholders.
• Widgets: usually small snippets of highly reusable markup, e.g. list item, button, etc. The content developers use widgets to increase readability and enforce consistency of design.

We will examine all mentioned features above. Test is executed in isolated environment using CPython 2.7. Latest available versions (April 2, 2015):

1. django 1.8
2. jinja2 2.7.3
3. mako 1.0.1
4. tenjin 1.1.1
5. tornado 4.1
6. wheezy.template 0.1.159

Includes & Extends: in this test case an initial version of HTML content is refactored to use include and extend features of respective template engine.

Widgets: the test case is around how widget is built and used.

02-single - a widget is built in a way that loop is inside; 03-loop - a widget represent an item that is rendered in a loop.

Python Web Frameworks PEP8 Consistency

The code is read much more often than it is written. The PEP8 guidelines are intended to improve the readability of code. Readability counts, no doubt, but readability consistency is important, it is equally important to know when to be inconsistent. The report below makes excuse for the following:

E501 line too long (> 79 characters)
E231 missing whitespace after ',:'
W291 trailing whitespace
W293 blank line contains whitespace

In this post we will take a look at web frameworks source code readability. The ratio between a web framework total python source lines to PEP8 errors found represents PEP8 error rate in respectful framework:

1. bottle
2. cherrypy
3. circuits
4. django
5. falcon
6. flask
7. pyramid
8. pysi
9. tornado
10. turbogears
11. web.py
12. web2py
13. webapp2
14. wheezy.web

The source code is hosted on bitbucket, let clone it into some directory and setup virtual environment (this will download source code per framework listed above).

hg clone https://bitbucket.org/akorn/helloworld
cd helloworld/04-pep8 && make env up

The make file has a target for each metric, so in order to gather pep8 count issue make pep8, or make count to count total lines.

Python Web Reverse URLs Benchmark

How fast python web frameworks reverse urls? While routing is a mapping of incoming request to a handler, url reverse function is designed to build urls for those handlers. A web page may have a number of urls from few dozen to hundreds... all related to your web site (e.g. links between related pages, tag cloud, most viewed posts, etc). A typical web application usually has deal with the following reverse url use cases:

• Static: the URL path is fixed and never changes, e.g. https://bitbucket.org/explore.
• Merge: the URL path is constructed dynamically, some information is taken from URL. A `user page` shows repositories. In this case a list of user repositories will be constructed as merge of information that came from URL (user name) and repository name.
• Route: the URL path is constructed dynamically, all information can be taken from URL. A `repository page` displays a number of features: downloads, source, etc. Those links include current route information (user name and repository name).

We will examine all reverse url use cases mentioned above with... a trivial 'Hello World!' application that builds 20 urls for each case. The benchmark is executed in isolated environment using CPython 2.7. Latest available versions (November 17, 2013):

1. django 1.6
2. flask 0.10.1
3. pylons 1.0.1
4. pyramid 1.5a2
5. tornado 3.1.1
6. wheezy.web 0.1.373

Let setup few prerequisites to be able run this in a clean debian testing installation.

apt-get install make python-dev python-virtualenv \
    mercurial unzip

The source code is hosted on bitbucket, let clone it into some directory and setup virtual environment (this will download all necessary package dependencies per framework listed above).

hg clone https://bitbucket.org/akorn/helloworld
cd helloworld/03-urls && make env

Once environment is ready we can run benchmarks:

env/bin/python benchmarks.py

Python Web Routing Benchmark

How fast python web framework process routing (some calls this URL dispatch)? A typical web application usually has the following routes:

• Static: the URL path is fixed and never changes, e.g. https://bitbucket.org/explore.
• Dynamic: the URL path is constructed dynamically and can include semantic information, e.g. https://bitbucket.org/jsmith/dotfiles/downloads, in this case jsmith is user, dotfiles a name of source repository, downloads - feature.
• SEO: localization and internationalization is sort of must have for modern web applications, can combine two above.
• Missing: that always happen, url changed and resource is not available anymore. What is impact of handing a non-existing path?

We will examine all mentioned routes above with... a trivial 'Hello World!' application. Routing is written for various Python web frameworks, each entry in route table points to a simple `Hello World` handler. Test is executed in isolated environment using CPython 2.7. Latest available versions (November 17, 2013):

1. bottle 0.11.6
2. django 1.6
3. falcon 0.1.7
4. flask 0.10.1
5. pylons 1.0.1
6. pyramid 1.5a2
7. tornado 3.1.1
8. web2py 2.2.1
9. wheezy.web 0.1.373

Let setup few prerequisites to be able run this in clean debian testing installation.

apt-get install make python-dev python-virtualenv \
    mercurial unzip

The source code is hosted on bitbucket, let clone it into some directory and setup virtual environment (this will download all necessary package dependencies per framework listed above).

hg clone https://bitbucket.org/akorn/helloworld
cd helloworld/02-routing && make env

Once environment is ready we can run benchmarks:

env/bin/python benchmarks.py

Python Fastest Web Framework

What is the fastest web framework for Python? In this post we will examine a trivial 'Hello World!'. See also:

1. Performance Benchmarks
   • Routing
   • Reverse URLs
   • Caching
2. Code Quality
   • PEP8 Consistency
   • Excessive Complexity
3. Template Engines
   • Big Table
   • Includes, extends and widgets

The application (see source) is written for various Python web frameworks and deployed to uWSGI application container (version 1.9.6 on CPython 2.7.4/3.3.1) and gunicorn (version 0.15.0 on PyPy 1.9). Latest available versions as of this writing (March 15, 2013):

1. bobo 1.0.0
2. bottle 0.11.6
3. cherrypy 3.2.4
4. circuits 2.1.0
5. django 1.5.1
6. flask 0.9
7. pyramid 1.4
8. tornado 3.0.1
9. turbogears 2.2.0
10. web.py 0.37
11. web2py 2.1.1
12. wheezy.web 0.1.365

Let setup few prerequisites to be able run this in clean debian testing installation.

apt-get install make python-dev python-virtualenv \
    mercurial unzip

# Up TCP connection limits
sysctl net.core.somaxconn=2048
sysctl net.ipv4.tcp_max_syn_backlog=2048

The source code is hosted on bitbucket, let clone it into some directory and setup virtual environment (this will download all necessary package dependencies per framework listed above).

hg clone https://bitbucket.org/akorn/helloworld
cd helloworld/01-welcome && make env

The make file has a target for each framework and runs particular example in uWSGI, e.g. in order to run django application just issue make django.

Python Fastest Template Engine

What is the fastest template system for Python? See also:

• Comprehensive benchmarks for various template include, extends and widget directives are here.

The benchmark is based on wheezy.template big table test for rendering a 10x1000 HTML table in unicode. Latest available versions (April 2, 2015):

1. bottle 0.12.8
2. chameleon 2.22
3. cheetah 2.4.4
4. django 1.8
5. jinja2 2.7.3
6. mako 1.0.1
7. durusworks qpy 1.2
8. spitfire 0.7.15
9. tenjin 1.1.1
10. tornado 4.1
11. web2py 2.0.9
12. wheezy.template 0.1.159

Let setup virtualenv environment:

virtualenv env
env/bin/easy_install -O2 bottle chameleon cheetah django \
  jinja2 mako tenjin webext tornado wheezy.html \
  wheezy.template

Download bigtable.py test:

wget https://bitbucket.org/akorn/wheezy.template/raw/tip/demos/bigtable/bigtable.py

And run it:

env/bin/python bigtable.py

How to Install django on Debian using nginx uwsgi

Here we are going install a basic django application using uwsgi application server and nginx as load balancer. Requirements:

• django code location: /usr/local/lib
• django project: hello

Let install few packages we need:

apt-get -y install nginx uwsgi \
    uwsgi-plugin-python python-django

Create a simple django application:

cd /usr/local/lib
django-admin startproject hello

uWSGI

Create uWSGI configuration (file /etc/uwsgi/apps-available/hello.yaml):

uwsgi:
    uid: www-data
    gid: www-data
    socket: /tmp/uwsgi-hello.sock
    plugins: http, python
    module: django.core.handlers.wsgi:WSGIHandler()
    pythonpath: /usr/local/lib
    chdir: /usr/local/lib/hello
    env: DJANGO_SETTINGS_MODULE=hello.settings 

Enable this configuration and restart uwsgi server:

ln -s /etc/uwsgi/apps-available/hello.yaml \
    /etc/uwsgi/apps-enabled/hello.yaml
/etc/init.d/uwsgi restart

nginx

Create nginx site configuration (file /etc/nginx/sites-available/hello):

upstream backend {
    server unix:///tmp/uwsgi-hello.sock;
}

server {
    location / { 
        uwsgi_pass  backend;
        include     uwsgi_params;
    }   

    location /static/admin/ {
        alias /usr/lib/pymodules/python2.6/django/contrib/admin/media/;
        access_log off;
        expires 7d;
    }

    location  /static/ {
        alias  /usr/local/lib/hello/static/;
        access_log off;
        expires 7d;
    }
}

Remove default site, enable this configuration and restart nginx server:

rm /etc/nginx/sites-enabled/default
ln -s /etc/nginx/sites-available/hello \
    /etc/nginx/sites-enabled/hello
/etc/init.d/nginx restart

nginx - uwsgi_cache

Web sites that serve almost static content (updated let say every 15 mins) can benefit by utilizing content caching:

   ...
uwsgi_cache_path   /var/cache/hello levels=1:2
                   keys_zone=NAME:15m
                   inactive=5m;
server {
   location / {
       uwsgi_pass  backend;
       include     uwsgi_params;
       uwsgi_cache   NAME;
       uwsgi_cache_valid   200 302 15m;
       uwsgi_cache_key $request_uri;
       expires 15m;
   }
   ...
}

If you experience performance issue with content rendering, overhead of framework internal time, have a willing to fine control content caching consider take a look at the following post and this one.

How to Serve Django Static Files by Apache

Serving static files out from python is not good idea since there is more effective way to do that. Why not let apache do this? Suppose you followed one of two previous posts that let you configure apache to server django application using mod_python or mod_wsgi. The idea is simple, we define an alias for the media directory of the django application and set it handler to none. Here is a partial example of apache site configuration file:

    ...

    Alias "/static/admin/" "/usr/lib/pymodules/python2.7/django/contrib/admin/media/"
    <Location "/static/admin/">
        SetHandler None
    </Location>

    Alias "/static/" "/usr/local/lib/hello/static/"
    <Location "/static/">
        SetHandler None
    </Location>

And finally let turn on static content expiration.

    ...

    <IfModule mod_expires.c>
        <FilesMatch "\.(jpg|gif|png|css|js)$">
            ExpiresActive on
            ExpiresDefault "access plus 7 days"
        </FilesMatch>
    </IfModule>

Enable expires module and restart apache2.

a2enmod expires
/etc/init.d/apache2 restart

How to Install Django on Debian using Apache mod_wsgi

Here we are going install a basic django application using apache2 mod_wsgi module. Requirements:

• server dns: web01.dev.local
• django code location: /usr/local/lib
• django project: hello

Let install few packages we need:

apt-get -y install apache2 libapache2-mod-wsgi \
    python-django 

Once you ensure apache is up and running. Let create a simple django application:

cd /usr/local/lib
django-admin startproject hello

Create a /usr/local/lib/django-hello.wsgi file:

import sys
import os
import os.path

sys.path.append(os.path.dirname(__file__))
os.environ['DJANGO_SETTINGS_MODULE'] = 'hello.settings'

from django.core.handlers.wsgi import WSGIHandler
application = WSGIHandler()

Add apache site configuration that will serve the django wsgi site. Add the following to /etc/apache2/sites-available/django-hello:

<VirtualHost *:80>
        ServerName web01.dev.local
        DocumentRoot /var/www/

        ErrorLog ${APACHE_LOG_DIR}/error.log
        # Possible values include: debug, info, notice, 
        # warn, error, crit, alert, emerg.
        LogLevel warn
        CustomLog ${APACHE_LOG_DIR}/access.log combined
    
        WSGIScriptAlias / /usr/local/lib/django-hello.wsgi
        WSGIProcessGroup hello-site
        WSGIDaemonProcess hello-site processes=2 threads=16 maximum-requests=1000 display-name=apache-hello-wsgi
</VirtualHost>

Now we are going disable default apache site and enable django-hello site:

a2dissite default
a2ensite django-hello
/etc/init.d/apache2 restart

Once you navigate to http://web01.dev.local/ you should be able to see the default django welcome screen.

If you experience performance issue with content rendering, overhead of framework internal time, have a willing to fine control content caching consider take a look at the following post.

How to Install Django on Debian using Apache mod_python

Here we are going install a basic django application using apache2 mod_python module. Requirements:

1. server dns: web01.dev.local
2. django code location: /usr/local/lib
3. django project: hello

Let install few packages we need:

apt-get -y install apache2 libapache2-mod-python \
    python-django 

Once you ensure apache is up and running. Let create a simple django application:

cd /usr/local/lib
django-admin startproject hello

Add apache site configuration that will serve the django site. Add the following to /etc/apache2/sites-available/django-hello:

<VirtualHost *:80>
        ServerName web01.dev.local
        DocumentRoot /var/www/

        ErrorLog ${APACHE_LOG_DIR}/error.log
        # Possible values include: debug, info, notice, 
        # warn, error, crit, alert, emerg.
        LogLevel warn
        CustomLog ${APACHE_LOG_DIR}/access.log combined
    
        SetHandler python-program
        PythonHandler django.core.handlers.modpython
        SetEnv DJANGO_SETTINGS_MODULE hello.settings
        PythonDebug On
        PythonPath "['/usr/local/lib'] + sys.path"
</VirtualHost>

Now we are going disable default apache site and enable django-hello site:

a2dissite default
a2ensite django-hello
/etc/init.d/apache2 restart

Once you navigate to http://web01.dev.local/ you should be able to see the default django welcome screen.

Troubleshooting

If you unable navigate to the apache this could be related to ipv6 support (that is turned on by default). You can verify that issuing the following command:

netstat -tunlp | grep :80

If the apache process is not listening on ipv4 address (e.g. 0.0.0.0:80) just follow the following post to disable ipv6 in apache.