Pull to refresh

Comments 32

Исходники пакета не смотрел, но выглядит всё очень изящно! Теперь сделать подобную прослойку к varnish'у и вообще красота будет.
Используется ли это решение на живом сайте с большим трафиком?
Ммм, те этот портал на чистом django написан?
нет, часть на перле
А можно, не интимно, рассказать какой прирост дает это на реальном проекте?
Какой прирост сложно сказать, проект в котором этот кеш используется, до его применения был реализован на совсем другой платформе. Но прирост есть.

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

Само использование кеширования трансформирует арххитектуру системы. Например, обычно стараются делать меньше запросов. Кеширование же по событиям побуждает разбивать запросы на более простые, чтобы их можно было кешировать и инвалидировать независимо. Поэтому простое отключение кеша, даже если бы оно было возможно под нагрузкой, не даст адекватного сравнения.
а какие бэкенды для кэша? только Redis?
мне бы varnish хотелось…
Только redis, т.к. необходимы его структуры и операции с ними. Конкретно — множества.
Откуда желание скрестить ежа с носорогом?
Redis, зачастую, используется как кэш между бд и backend'ом, а varnish исключительно между backend'ом и клиентом.
Я понимаю. имелось ввиду что может быть он может работать и в другом режиме.
проект действительно хороший. обязательно буду им пользоваться.
джанга и так у меня работает с сессиями через redis_sessions.
Тоже некоторое время использовал сессии в редисе, собственную реализацию. Когда занимаемая память перевалила через 400 мб, понял что надо от этого избавляться. Переделал на сессии в подписанных куках, это просто просветление — ничего не надо хранить, никуда делать запросов, сессия приходит вместе с запросом.
Может посвятишь этому свой следующий пост в блоге Django Framework?
было бы инетесно так-же почитать и комментарии к этому посту о том как другие реализовывают работу с сессиями.
Я пытался доки осилить по подписанным куакам, не понял как они работают. Если я хочу хранить в сессии мегаайт данных, оно что ли в куках будет туда-сюда ходить?
Не будут, есть ограничение на размер кук. И стоит бороться с такими желаниями ) мегабайт на юзера в любом случае слишком много.

Факт в том, что не требуется много информации, чтобы выдать большинство страниц. Частные случаи, для отдельных страниц следует решать отдельно.
Очень не плохо! Обычно мы реализовывали кэширование сами на уровне менеджера модели, но у вас более универсальный подход.
Хорошее решение.

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

Это надо будет держать в памяти при работе с Cacheops, но в целом спасибо за библиотеку.
Ага, если «сделать всё правильно», то массовый апдейт с условием ортогональным условиям в выборка сбросит весь кеш. Что как-то не очень. Поэтому такие ситуации придётся обрабатывать вручную. К счастью, они не особо часты.
в документации забыли упомянуть про «settings.HOME_DIR + settings.FILE_CACHE_DIR»
От CACHEOPS_PROFILES, возможно, следует отказаться, не вижу я в нём особого толка пока.
Файловый кеш вообще не документирован пока, так что документировать его настройки было бы странно.

Документации далеко до полноты, это верно
ну я попробовал добавить к проекту таким образом как написано в документации и тут-же выдало ошибку:
'Settings' object has no attribute 'HOME_DIR' просто чтобы хотябы ошибка не вылезала можно было освятить этот пункт в документации.
Ну, вообще-то это баг в обработке настроек, который я только что поправил
просто великолепно! очень вовремя (для меня), очень конкретно и очень полезно! земной, автору, поклон!
Приятно читать пост от замляков, а ещё приятнее что знаком с несколькими людьми из Метадизайна ;)

Удачи вам.
Johnny Cache, насколько я знаю, инвалидирует сразу все запросы к модели поэтому просто неприменим если изменения часты. В тех же случаях когда он применим он должен быть быстрее потому как проще.
А что скажете про django-cache-machine, не смотрели? AFAIK в нём реализован кэш по объектам.
Смотрел, там сильно недостаточная инвалидация. Кеш запроса сбрасывается только когда один из объектов из его результатов изменяется. Например, выборка последних новостей так и зависнет если их никто не будет редактировать, а при добавлении новых новостей кеш сбрасываться не будет.
Sign up to leave a comment.

Articles