solovyov.net

Кеширование ContentType в память

2 min read · django, dbqueries

Сегодня обсуждали немного generic relation’ы из Джанги, и пришли к выводу, что неплохо было бы сами ContentType‘ы закешировать прямо в память - мы постоянно используем один и тот же набор из нескольких типов (модельки, которые можно тегать и ставить рейтинги), и кеш даёт гарантию того, что для них будет всего 1 запрос в базу за всё время жизни апачевского ребёнка.

Я даже написал в django-users, на что мне Малькольм указал на уже существующий кеш, который, однако, работает, только если у меня уже есть модель. А мне-то наоборот, надо её получить!

Вылилось в первом приближении всё это в 10 минут вечером (почему-то при обдумывании этого на работе мне в голову лезли всякие непристойности с кучей кода) и замену метода get у менеджера модели ContentType. Кеш вышел рабочим, но тупым - отдельным от существующего джанговского, хранящим результаты выборки в словаре с ключом только по названию модели.

Подкрепление ослабленного организма позволило понять, что ведь можно же и использовать джанговский внутренний кеш, хотя и придётся пробегать его в цикле ;) - мы обычно не используем название приложения при доставании типа.

Короче, много времени это не заняло. Встречайте, а вдруг кому-то пригодится? :)

Подумывал это оформить патчем в джангу, но как-то это всё выглядит не слишком чистым пока. Как минимум надо убрать get_without_app

Вообще наверное лучшим решением будет подгрузка всех типов сразу на старте, построение словаря с уникальными названиями моделей (те, на которые и база данных бы не ругалась при выборке без имени приложения), но я пока не придумал, как бы это сделать. :)

If you like what you read — subscribe to my Twitter, I always post links to new posts there. Or, in case you're an old school person longing for an ancient technology, put a link to my RSS feed in your feed reader (it's actually Atom feed, but who cares).

Other recent posts

Server-Sent Events (SSE), but with POST
ngrok for the wicked, or expose your ports comfortably
PostgreSQL collation
History Snapshotting in TwinSpark
Code streaming: hundred ounces of nuances