Думаю, все знают, что такое сессии в Django, не так ли? Без них довольно сложно представить разработку приложений. В них обычно хранят ID пользователя и какие-нибудь промежуточные данные. Ими пользуются чаще, чем задумываются о настройке способа их хранения. Конечно, настроек «по умолчанию», как правило, бывает достаточно для того, чтобы запустить практически любой проект. Однако пытливый ум требует узнать, какая из возможных конфигураций работает быстрее…

В документации Django очень подробно описывается, как работают различные Session Engine и как их настроить. В этой статье пойдёт речь о том, как я тестировал различные конфигурации развёртывания гипотетического проекта.

Исходные данные

Тестирование проводилось на 2-х виртуальных машинах под управлением debian wheezy. Машины расположены в рамках одной подсети.

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

Первая — для сохранения данных сессии в базах данных. Вторая для запуска приложения.
В рамках тестирования использовалось 2 БД:

• PostgreSQL – 9.1.15
• Redis — 2.4.14-1

Приложение запущено на

• Python — 3.4.3
• Django — 1.7.7

Выбран сервер приложений gunicorn с асинхронными рабочими (eventlet):

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

Для оценки производительности использовался Apache Bench.

• Число запросов = 4000
• Паралельных соединений = 20
• В рамках одного идентификатора сессии (sessionid)

Задача

Протестировать входящие в фреймворк бэкенды для хранения данных сессий

1. database-backed — postgresql
2. cached — redis
3. file-based — файловая система ext2
4. cookie-based — для данных до 4K

Документацию по ним можно найти тут.

Тестирование

Я решил провести тестирование в двух конфигурациях: «только чтение» и «чтение и запись». При этом также сформировать не очень сложную страничку с использованием django-темплейтов, чтобы это походило на хоть и очень простое, но всё же реальное приложение.

Чтение

Запись

Выводы

Из графиков видно, что при хранении большого количества данных в сессии существенно падает скорость загрузки страниц приложения. Зависимость между количеством данных и скоростью загрузки приобретает логарифмический характер после 16К.

Также сложно не заменить, что сохранение сессии в базе данных существенно отстаёт по производительности от остальных конфигураций. Впрочем, это было довольно предсказуемо. Довольно необычным для меня было поведение файлового хранилища сессий. В частности, скорость доступа к файлу оказалась выше, чем у БД redis в рамках одной подсети при объёме сессии меньше ~ 64K. Возможно, это как-то связано с конфигурацией виртуальных машин, не знаю…

По результатам тестов сформировал следующие правила в использовании хранилищами:



Спасибо за внимание!