Suor Sep 25 2011 at 15:46

Cacheops

3 min

8.6K

Django*

+47

Comments 32

jov Sep 25 2011 at 17:11

Исходники пакета не смотрел, но выглядит всё очень изящно! Теперь сделать подобную прослойку к varnish'у и вообще красота будет.

itforge Sep 25 2011 at 17:41

Используется ли это решение на живом сайте с большим трафиком?

Suor Sep 25 2011 at 17:46

Да, используется на RUAUTO.RU уже более года.

Masterkey Sep 25 2011 at 19:16

Ммм, те этот портал на чистом django написан?

Suor Sep 25 2011 at 19:28

нет, часть на перле

Masterkey Sep 25 2011 at 17:43

А можно, не интимно, рассказать какой прирост дает это на реальном проекте?

Suor Sep 25 2011 at 17:57

Какой прирост сложно сказать, проект в котором этот кеш используется, до его применения был реализован на совсем другой платформе. Но прирост есть.

И дело не только в экономии времени, такая автоматическая система позволяет кешировать, грубо говоря, все запросы к БД, что здорово её разгружает. А сервера приложений масштабировать в случае надобности куда проще.

Masterkey Sep 25 2011 at 19:14

Я так понимаю это полноценный намек на горизонтальное масштабирование для django без выдирания ORM и тп штучек?

funca Sep 25 2011 at 21:04

насколько сложно измерить производительность с включенным и выключенным кешем?

Suor Sep 25 2011 at 21:11

Невозможно, если архитектура изначально проектировалась на использование кеша. А это так в данном случае.

Само использование кеширования трансформирует арххитектуру системы. Например, обычно стараются делать меньше запросов. Кеширование же по событиям побуждает разбивать запросы на более простые, чтобы их можно было кешировать и инвалидировать независимо. Поэтому простое отключение кеша, даже если бы оно было возможно под нагрузкой, не даст адекватного сравнения.

MechanisM Sep 25 2011 at 17:56

а какие бэкенды для кэша? только Redis?
мне бы varnish хотелось…

Suor Sep 25 2011 at 17:58

Только redis, т.к. необходимы его структуры и операции с ними. Конкретно — множества.

jov Sep 25 2011 at 18:11

Откуда желание скрестить ежа с носорогом?
Redis, зачастую, используется как кэш между бд и backend'ом, а varnish исключительно между backend'ом и клиентом.

MechanisM Sep 25 2011 at 18:26

Я понимаю. имелось ввиду что может быть он может работать и в другом режиме.
проект действительно хороший. обязательно буду им пользоваться.
джанга и так у меня работает с сессиями через redis_sessions.

Suor Sep 25 2011 at 18:42

Тоже некоторое время использовал сессии в редисе, собственную реализацию. Когда занимаемая память перевалила через 400 мб, понял что надо от этого избавляться. Переделал на сессии в подписанных куках, это просто просветление — ничего не надо хранить, никуда делать запросов, сессия приходит вместе с запросом.

MechanisM Sep 25 2011 at 18:45

Может посвятишь этому свой следующий пост в блоге Django Framework?
было бы инетесно так-же почитать и комментарии к этому посту о том как другие реализовывают работу с сессиями.

itforge Sep 25 2011 at 18:48

Я пытался доки осилить по подписанным куакам, не понял как они работают. Если я хочу хранить в сессии мегаайт данных, оно что ли в куках будет туда-сюда ходить?

Suor Sep 25 2011 at 18:56

Не будут, есть ограничение на размер кук. И стоит бороться с такими желаниями ) мегабайт на юзера в любом случае слишком много.

Факт в том, что не требуется много информации, чтобы выдать большинство страниц. Частные случаи, для отдельных страниц следует решать отдельно.

vostryakov Sep 25 2011 at 18:54

Очень не плохо! Обычно мы реализовывали кэширование сами на уровне менеджера модели, но у вас более универсальный подход.

Yngvie Sep 25 2011 at 19:12

Хорошее решение.

Только хотел спросить у Вас как Вы отлавливаете массовые апдейты. Но заметил строчку в описании:

4. Массовые апдейты не приводят к инвалидации.

Это надо будет держать в памяти при работе с Cacheops, но в целом спасибо за библиотеку.

Suor Sep 25 2011 at 19:31

Ага, если «сделать всё правильно», то массовый апдейт с условием ортогональным условиям в выборка сбросит весь кеш. Что как-то не очень. Поэтому такие ситуации придётся обрабатывать вручную. К счастью, они не особо часты.

MechanisM Sep 25 2011 at 19:28

в документации забыли упомянуть про «settings.HOME_DIR + settings.FILE_CACHE_DIR»

MechanisM Sep 25 2011 at 19:29

так-же «CACHEOPS_PROFILES»

Suor Sep 25 2011 at 19:33

От CACHEOPS_PROFILES, возможно, следует отказаться, не вижу я в нём особого толка пока.
Файловый кеш вообще не документирован пока, так что документировать его настройки было бы странно.

Документации далеко до полноты, это верно

MechanisM Sep 25 2011 at 19:36

ну я попробовал добавить к проекту таким образом как написано в документации и тут-же выдало ошибку:
'Settings' object has no attribute 'HOME_DIR' просто чтобы хотябы ошибка не вылезала можно было освятить этот пункт в документации.

Suor Sep 25 2011 at 20:15

Ну, вообще-то это баг в обработке настроек, который я только что поправил

qnub Sep 26 2011 at 07:45

просто великолепно! очень вовремя (для меня), очень конкретно и очень полезно! земной, автору, поклон!

odmin4eg Sep 26 2011 at 13:57

Приятно читать пост от замляков, а ещё приятнее что знаком с несколькими людьми из Метадизайна ;)

Удачи вам.

Fak3 Oct 4 2011 at 01:38

Интересно было бы сравнить производительность с Johnny Cache

Suor Oct 4 2011 at 05:21

Johnny Cache, насколько я знаю, инвалидирует сразу все запросы к модели поэтому просто неприменим если изменения часты. В тех же случаях когда он применим он должен быть быстрее потому как проще.

Prophet Oct 6 2011 at 14:06

А что скажете про django-cache-machine, не смотрели? AFAIK в нём реализован кэш по объектам.

Suor Oct 6 2011 at 14:59

Смотрел, там сильно недостаточная инвалидация. Кеш запроса сбрасывается только когда один из объектов из его результатов изменяется. Например, выборка последних новостей так и зависнет если их никто не будет редактировать, а при добавлении новых новостей кеш сбрасываться не будет.