Новая тема   Ответить

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

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

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

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

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

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

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

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

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

 Noobus Boobus
Цитата:

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

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

 Alex AWM
Noobus Boobus писал:

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

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

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