New Python web developers seem to love running benchmarks on WSGI servers. Reality is that they often have no idea what they are doing or what to look at. This talk will look at a range of factors which can influence the performance of your Python web application. This includes the impact of using threads vs processes, number of processors, memory available, the GIL and slow HTTP clients.
A benchmark of a hello world application is often what developers use to make the all important decision of what web hosting infrastructure they use. Worse is that in many cases this is the only sort of performance testing or monitoring they will ever do. When it comes to their production applications they are usually flying blind and have no idea of how it is performing and what they need to do to tune their web application stack.
This talk will discuss different limiting factors or bottlenecks within your WSGI server stack and system that can affect the performance of your Python web application. It will illustrate the impacts of these by looking at typical configurations for the more popular WSGI hosting mechanisms of Apache/mod_wsgi, gunicorn and uWSGI, seeing how they perform under various types of traffic and request loads and then tweaking the configurations to see whether they perform better or worse.
Such factors that will be discussed will include:
Use of threads vs processes.
Number of processors available.
Python global interpreter lock (GIL)
Amount of memory available.
Slow HTTP browsers/clients.
Browser keep alive connections.
Need to handle static assets.
From this an attempt will be made to provide some general guidelines of what is a good configuration/architecture to use for different types of Python web applications. The importance of continuous production monitoring will also be covered to ensure that you know when the performance of your system is dropping off due to changing traffic patterns as well as code changes you have made in your actual web application.
CherryPy was the first web framework to be made available for use with Python 3, and we tried several approaches to support both Python 2 and 3 before settling on one. Learn about the ups and the downs of each approach, and ways you can make your own porting project easier.
The CherryPy project was the first web framework to support Python 3. At the same time, we needed to continue to support and improve the Python 2 implementation. It's taken plenty of time and lots of experimentation to find out the best way. We will explore four different ways to support both Python 2 and 3, commenting on the pros and cons of each.
Python 3 change highlights
Special concerns for I/O, including WSGI
Approach 1: 2to3
Approach 2: separate branches
Approach 3: setup.py switch
Approach 4: compatibility layer
7th–15th March 2012