Новый модуль - CHI::Cascade (кэширование на основе зависимостей)

Хочу представить общественности новый модуль, который написал уже довольно давно и успешно использую в своей работе.

Если в кратце - этот модуль управляет кэшированием (любые кэши из под CHI модуля - memcached, file cache и т.п..) и расчётом данных, но с учётом указанных программистом зависимостей (как явных, так и через регулярные выражения). Другими словами, это синтез принципов кеширования и концепции утилиты make. Цель была - создать модуль для динамических веб-приложений, которые генерируют сайт на ходу с большим количеством расчётов (например сайт со множеством категорий, которые могут быть разбиты на подстраницы), при этом надо было добиться, чтобы информация обновлялась максимально быстро (например, если что-то изменилось внутри категории - одновить сразу все страницы категории и, например, вдобавок другие, которые могут зависеть от первой страницы какой либо категории - например, индексная главная страница с превью содержимым из первой страницы какой либо категории). Другая цель - максимально обеспечить посетителей данными (например, пока расчитываются свежие - отдавать старые из кеша другим запросам)

Где почитать подробнее: http://blog.perlover.com/2012/... ade-intro/

Где взять: не свежая, но стабильная версия: CPAN
Свежая, стабильная и лучше, но меньше документированная: GitHub
Ссылки все в статье, чтобы не приводить здесь много линков

P.S. Интересно узнать мнение программеров - как часто у них была нужда в таком модуле? Я лично в нём сильно нуждался, но ничего подходящего не нашёл. Пока, хоть модуль уже наверное полгода на CPAN, не вижу какой либо активности по его использованию. Если кого заинтересует он - готов продолжить написание статей по его использованию на своём блоге.

С уважением, Perlover

0

Я так понимаю страница целиком падает в кеш, но не всегда есть смысл кешировать весь хтмл, а только какие-либо области страницы и мета информацию. Времени на инвалидацию кеша тратиться меньше и зависимостей расчитывать меньше. Нужен только шустрый шаблонизатор и, например, редис. Разгонял сайт до 1500 rps. На core i3 с 2Gb ram, на боевом тазу показатели выше будут. При этом подходе есть много плюсов. Можно менять шаблоны и не надо перекешировать весь сайт, а также мета теги, заголовки, текст и т.д. Естественно мое решение не может быть универсальным в отличие от вашего.

0

Вообще то нигде не сказано, что у меня кэширование идёт HTML. Я не кэширую вообще HTML, только данные (scalar, hashref, arrayref). И у меня также кешируются только данные, а потом натягивается HTML после кэша.

Модуль для другого. Например. Есть категория чего либо. В ней - скажем 10000 элементов. Категорию надо разбить на страницы, скажем по 100 элементов. С моим модулем можно сделать так: описать отдельное правило с кодом, который строит всю портянку одним SQL запросом с множественными JOIN, например (назовём это "тагет A". Он может исполнятся и 20 секунд, например - всё таки сложные JOINы могут столько исполнятся на больших базах). Эта портянка запихивается после расчёта в кэш. Определяем второй "тагет B", который зависит от первого. А именно - тагет отдельной страницы любой (у меня можно тагеты определяет regexp-ами, поэтому можно сказать условно B:(\d+) тагет). Модуль отслеживает, что "тагет B" зависит от "тагет A". Он автоматически даст для кода тагета B только свежие данные (расчитывать или нет, он сам определит) из первого расчёта (A), который может выполнить уже более простую функцию - просто "выпил" нужной страницы (код тагета может получить номер страницы, которую от него хотят), или скажем, достроить какие то ещё данные. Тогда скрипты генерации сайта просто запрашивают тагет для такой то страницы (B:5 например) и всё. Если что либо изменится с первым тегатом (A) (например, раз в 3 часа мы, для примера, просто удаляем метку для тагет A - как в аналогии с makem стираем файл сделанный touch-ем, например) - тогда сразу все страницы выдаются свежие (менее чем за секунду). А можно, если пофантазировать, то тагет A может тоже быть regexp-овым для многих категорий, и он в свою очередь может зависить от главного одного тагета reset. Тогда сбросив reset, сайт полностью обновляет инфу почти сразу, все категории перестраиваются. Обычное кэширование такого не даст.

А всё что вы описали - простой пример кеширования на expires сроках. Чем дольше быдет expires, тем менее оперативную информацию будет отображать сайт. А чем меньше - тем чаще будут вызываться коды для расчёта. В моём модуле коды для расчёта будут вызываться только тогда, когда либо изменятся зависимые тагеты, либо значение истечёт в кеше (я в проектах делал бесконечный expires). Как ваш пример будет обеспечивать динамику сайта - не понятно. И расчёт тоже. Особенно если будут запросы к SQL, несколько простых JOIN-ов в ваших 1500 rps просто завалят сервер по принципу снежного кома. С этим модулем же будет идти один расчёт одним процессом, другие же будут отдавать старые данные, пока не расчитаются новые. А как только расчитаются - всё будет отдаваться новое. Также гарантируется только один вызов кода для одного тагета в один момент времени на одном сервере.

Всё это и описано в статье. Похоже, вы её просто не читали.

0

Вы правы, статью не успел прочитать (с телефона был). Да действительно вещь занятная, на досуге покопаю поглубже.

В моем примере TTL бесконечный, содержит json структуры данных, пересчитываются только при изменении и только одним процессом, хранение идет по объектам - сущностям (например документ, группа и т.д.). MySQL используется только как запасное хранилище.
Кратко процесс кеширование выглядит так:
1. Заносятся данные в мускул,
2. Идентификатор и имя таблицы передается в систему кеширования и ставятся в очередь,
3. По набору правил для этой таблицы идет расчет и занесение данных в кеш.


Сборка страницы идет на нгинкс, для этого имеется быстрый роутинг и менеджер данных. Путь разбирается на составные части и проверяется по грамматике, если некорректен, то 404. Если все устраивает, то получаем метаинформацию страницы, в которой есть описание кешируемых областей и шаблона оформления. Далее вытаскиваем данные mget-ом собираем в один объект и отправляем на шаблонизатор. Если не удалось получить данные страницы то 404. Время отклика от запроса до ответа 1 мс на локальной машине. А expires - это действительно прошлый век.

0

Из вашего описания я понял, что если данных в кеше нет, то страница на nginx будет 404. Но ведь memcached, например, может выкинуть данные из кеша, даже если expires бесконечен. Просто когда ему перестает хватать slabs. Это получается, что у вас будет куча 404 при достижении этих лимитов?

И не понятно, как с поисковыми ботами быть - они же в такие моменты будут получать 404 на страницы, которые иногда бывают 200. Страницы то будут снова в индекс попадать поисковика, то опять удаляться. Сайт будет иметь проблемы с СЕ трафиком.

Также не понял - а где идёт расчёт данных и в какие моменты происходит? Хотя это не очень важно для меня, так как ваша описанная модель мне не подходит.
P.S. IMHO если и ворочить данными, то лучше сериализацию в кеш делать через Storable - быстрее будет точно, и компактнее. Хотя если конечно тот, кто процесс, который данные обрабатывает, не работает на perl, а только с json, то тогда да.

Добавлено через 5 минут
А можете сообщить, что это за модуль для nginx, который работает с кэшем и имеет шаблонизатор и понимает json?

0

Сами писали

0