Новый модуль для оптимизации кеширования сайтов

Вот решил самописный модуль в массы продвигать
Написан на Perl. Использую в своей работе
Этот модуль - "сердце" моих категорийных мультиязыковых сиджетюбов :-)

http://blog.perlover.com/2012/08/24/chi-cascade-intro/

Если интересно - welcome

Бенчмарки до, после есть?

Хех.
Я забыл уже, как код на перле выглядит ;)
Надо будет потом поподробнее посмотреть -- может где идею оприходую.

Stup писал:

Бенчмарки до, после есть?

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

Так а как ты все-таки решаешь проблему гонок конкурентного обновления кешей одного и того же узла?

Цитата:

Так а как ты все-таки решаешь проблему гонок конкурентного обновления кешей одного и того же узла?

Я решаю так - сделал тотализатор и назначаю ставки. Чей узел победил, тот и срывает куш

А если серьёзно - не понял смысл вопроса (точнее каждый его может понимать по своему). Что там именно решать, и почему "всё таки"?

Цитата:

Например, вы вычисляете что либо скриптами, чтобы выдать www страничку пользователя. На это, скажем требуется, например, 5 секунд. Например, строится дерево категорий из базы, затем сортировка и т.п.. Пока длятся эти 5 сек, на сайт заходит второй пользователь. В кеше ещё нет результата, так как он вычисляется и процесс, обрабатывающий запрос второго пользователя начинает также вычислять всё тоже самое. И вот система трудится над тем же самым, уже работает два ядра процессора, два коннекта к базе и т.п.. А потом заходит третий за эти 5 сек. Всё тоже самое.

Это и есть проблема. Я так понял, модуль пытается ее решить. Как именно? Путем разбиения на мелкие подзадачи?

Цитата:

Как именно? Путем разбиения на мелкие подзадачи?

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

Noobus Boobus писал:

Так а как ты все-таки решаешь проблему гонок конкурентного обновления кешей одного и того же узла?

по идее она должна решаться локом на узел.
PS гуглить по слову dogpile

Noobus Boobus писал:

Это и есть проблема. Я так понял, модуль пытается ее решить. Как именно? Путем разбиения на мелкие подзадачи?

На мелкие задачи сам программист должен разбить, если требуется. Хотя у меня есть данные, которые расчитываются более 1-5 минут (очень сложные SQL запросы с множественным JOIN - например большая портянка всей категории с 1 по 100 страницу, а уже сами страницы объявлены как зависимые от этой портянки - если портянка поменяется (1-5 мин), то остальные страницы сразу же изменятся: распилка - обычная работа на уровне массива данных + можно ещё выполнять разные задачи для каждой страницы). Но при этом, страницы пользователю отдаются и он не чувствует задержки. При этом, как новые данные расчитаются, другим пользователям сразу начнут отдаваться свежие данные. Ещё пример - главная страница мультикатегорийного сайта - как правило топ нескольких категорий, которые предворяются картинкой для каждой категории. У меня главная страница описана как цель, которая зависит от топа, скажем, 200 категорий, причём точнее, от топа первых страниц каждой категории (чтобы брать от туда кликабельные тумбы - нет нужды во второй, третьей странице). А сама каждая первая страница категории в свою очередь зависит от всей портянки одной категории. Получается, достаточно измениться портянке категории, как меняется первая страница, а от нее меняется и главная страница. То есть у меня главная страница менятся каждый раз, когда измениться хотя бы одна первая страница какой либо из 200 категорий. И всё работает довольно быстро.

Сам модуль в кеше хранит два значения - служебную метку, и данные, которые были расчитаны. Служебная метка хранит дату, когда данные расчитаны и ещё что-то по мелочи (локировки, например). Метка - аналог нулевого файла - цели в make (как touch file). Без этой метки нельзя организовать подобную работу на основе зависимостей, как в make. В обычном варианте с кешированием сохраняют данные и ещё как нибудь может быть время, когда они устаревают (не все кеши могут поддерживать храние expires, например, простой файловый кеш).