Performance evaluation of Django Session Engine configurations

I think everyone knows what a session in Django is, isn’t it? Without them, it is quite difficult to imagine application development. They usually store the user ID and some intermediate data. They are used more often than they think about setting up the way they are stored. Of course, the default settings, as a rule, are enough to run almost any project. However, an inquiring mind needs to know which of the possible configurations is faster ...

The Django documentation describes in great detail how the various Session Engine works and how to configure them. This article will discuss how I tested various deployment configurations of a hypothetical project .

Initial data

Testing was conducted on 2 virtual machines running debian wheezy. Machines are located within the same subnet.

• model name: Intel Xeon CPU E7- 4830 @ 2.13GHz
• RAM: 8GB
• Linux Kernel Version: 3.2.0-4-amd64

The first is to save session data in databases. The second to run the application.
As part of testing, 2 databases were used:

• PostgreSQL 9.1.15
• Redis - 2.4.14-1

Application running on

• Python - 3.4.3
• Django - 1.7.7

The gunicorn application server with asynchronous workers (eventlet) is selected:

• Gunicorn - 19.3.0
• Eventlet - 0.17.3
• libevent - 1.4-2

Apache Bench was used to evaluate performance.

• Number of requests = 4000
• Parallel connections = 20
• Within one session identifier (sessionid)

Task

Test framework backends for storing session data

1. database-backed - postgresql
2. cached - redis
3. file-based - ext2 file system
4. cookie-based - for data up to 4K

Documentation on them can be found here .

Testing

I decided to test in two configurations: “read only” and “read and write”. At the same time, also create a not very complicated page using django templates to make it look like a very simple, but still real application.
')

Reading

Record

findings

From the graphs it can be seen that when storing large amounts of data in a session, the speed of loading pages of the application drops significantly. The relationship between the amount of data and download speed becomes logarithmic after 16K.

It is also difficult not to replace that saving the session in the database is significantly lagging behind the performance of other configurations. However, it was quite predictable. The behavior of the session file storage was quite unusual for me. In particular, the file access speed was higher than that of the redis database within the same subnet with a session size less than ~ 64K. Perhaps this is somehow related to the configuration of virtual machines, I do not know ...

Based on the test results, I formed the following rules for use by repositories:



Thanks for attention!