kashey Dec 25 2008 at 13:00

Поиграем в CacheGraph?

3 min

675

Website development*

+53

Comments 24

gorod Dec 25 2008 at 13:58

Может проще использовать CDN? В России уже есть один — см. www.ngenix.net

-18

el777 Dec 25 2008 at 14:06

Вообще это совершенно разные вещи.
CDN нужен разным tub-ам, чтобы быстро и дешево присылать большие файлы (видео, музыка и прочее).
А здесь речь идет об ускрении ренедринга страниц, чтобы вы быстрее увидели, что там можно скачать.

stal Dec 25 2008 at 14:02

Как быть с зависимостями, что если cache- запрос Б зависит от результата запроса А?

el777 Dec 25 2008 at 14:06

Проверить в грфе, выстроить по порядку.

kashey Dec 25 2008 at 14:10

Обычные вложености.
В первом проходе получить А, про Б забыть…
Во втором получить Б…

Если что-то хитро генериться — оно просто дописывает в граф нужный ей «хвост»
потом система пройдет по графу, найдет те ключи которые надо запросить и пачкой запросит.
Ничто не мешает строить граф не обычным тупым массивом с вариантами элемента как «строка»\«запрос к БД»\«запрос к кешу»
А классами, определяя фунции traverse как угодно.

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

zhuk Dec 25 2008 at 14:17

Можеш подсказать ссылки на существующие реализации?
Какие-либо CMS это реализуют?

kashey Dec 25 2008 at 14:33

Реализация покуда только синтетическая в (с) Кащей тестах.
Насчет того какие фреймворки поддерживают — не скажу, на работе приходиться работать с чем есть.
В альтернативы лазить поздно, посему и не лазию

kurokikaze Dec 25 2008 at 14:25

Интересная задумка.

kashey Dec 25 2008 at 14:35

Спасибо, но для меня это не задумка а повод биться головой об стенку с криками деградирую...
три года назад я ничем кроме этого наверное и подумать бы не смог…

korchasa Dec 25 2008 at 22:56

Не стоит биться. Не все сферы применения окучены ;)

kashey Dec 26 2008 at 07:30

Лично я давно на mysqlnd перебрался.
А на асинхроные вызовы базы так вообще несколько лет назад
Жалко только драйвера кривые и не все можно асинхронить :(

kashey Dec 26 2008 at 13:04

Просмотрел внимательно ссылку что вы дали и хотел один момент осветить…
Асинхроный запрос к базе данных чтука не совсем удобная.
Потому как в один момент времени, с одного конекшена может быть только один запрос.
Сделаете другой — потеряете все данные, они просто перетрутся.
Держать много конекшенов плохо — конект относительно долгая операция, но…
опять же есть multi_query && multi_result :)
Вот только база данных в отличие от кешеда — не резиновая :(

7vies Dec 25 2008 at 14:53

Собирать много запросов в пачку — это понятно. Но вот причём тут дерево — я не понял :(

kashey Dec 25 2008 at 15:01

Оно служит для сборки

Damnedest Dec 25 2008 at 15:45

1. Нет гарантии того, что все ключи окажутся на одном сервере… Т.е. если у вас 15 серверов и вы запрашиваете 5 ключей, то с большой вероятностью они окажутся на разных серверах.
2. Иногда шаблон нельзя сгенерить не получив значения ключа.

-1

kashey Dec 25 2008 at 15:49

1.Не поверите — но это как раз хорошо :)
Если 5 ключей сидят на 5ти серверах, то при multi-get они будут качаться с 5ти серверов одновременно.
2.Вы плохо читали — «Второй проход рендера»