Comments 24
Может проще использовать CDN? В России уже есть один — см. www.ngenix.net
Как быть с зависимостями, что если cache- запрос Б зависит от результата запроса А?
Проверить в грфе, выстроить по порядку.
Обычные вложености.
В первом проходе получить А, про Б забыть…
Во втором получить Б…
Если что-то хитро генериться — оно просто дописывает в граф нужный ей «хвост»
потом система пройдет по графу, найдет те ключи которые надо запросить и пачкой запросит.
Ничто не мешает строить граф не обычным тупым массивом с вариантами элемента как «строка»\«запрос к БД»\«запрос к кешу»
А классами, определяя фунции traverse как угодно.
Главная суть в том что при генерации страницы вначале надо собрать все ключи которые надо получить, потом их все получить. разом
Как ходить по графу и что он есть такое на уровне кода — частности
В первом проходе получить А, про Б забыть…
Во втором получить Б…
Если что-то хитро генериться — оно просто дописывает в граф нужный ей «хвост»
потом система пройдет по графу, найдет те ключи которые надо запросить и пачкой запросит.
Ничто не мешает строить граф не обычным тупым массивом с вариантами элемента как «строка»\«запрос к БД»\«запрос к кешу»
А классами, определяя фунции traverse как угодно.
Главная суть в том что при генерации страницы вначале надо собрать все ключи которые надо получить, потом их все получить. разом
Как ходить по графу и что он есть такое на уровне кода — частности
Интересная задумка.
Спасибо, но для меня это не задумка а повод биться головой об стенку с криками деградирую...
три года назад я ничем кроме этого наверное и подумать бы не смог…
три года назад я ничем кроме этого наверное и подумать бы не смог…
Не стоит биться. Не все сферы применения окучены ;)
Лично я давно на mysqlnd перебрался.
А на асинхроные вызовы базы так вообще несколько лет назад
Жалко только драйвера кривые и не все можно асинхронить :(
А на асинхроные вызовы базы так вообще несколько лет назад
Жалко только драйвера кривые и не все можно асинхронить :(
Просмотрел внимательно ссылку что вы дали и хотел один момент осветить…
Асинхроный запрос к базе данных чтука не совсем удобная.
Потому как в один момент времени, с одного конекшена может быть только один запрос.
Сделаете другой — потеряете все данные, они просто перетрутся.
Держать много конекшенов плохо — конект относительно долгая операция, но…
опять же есть multi_query && multi_result :)
Вот только база данных в отличие от кешеда — не резиновая :(
Асинхроный запрос к базе данных чтука не совсем удобная.
Потому как в один момент времени, с одного конекшена может быть только один запрос.
Сделаете другой — потеряете все данные, они просто перетрутся.
Держать много конекшенов плохо — конект относительно долгая операция, но…
опять же есть multi_query && multi_result :)
Вот только база данных в отличие от кешеда — не резиновая :(
Собирать много запросов в пачку — это понятно. Но вот причём тут дерево — я не понял :(
1. Нет гарантии того, что все ключи окажутся на одном сервере… Т.е. если у вас 15 серверов и вы запрашиваете 5 ключей, то с большой вероятностью они окажутся на разных серверах.
2. Иногда шаблон нельзя сгенерить не получив значения ключа.
2. Иногда шаблон нельзя сгенерить не получив значения ключа.
Хм. Спасибо, что заставили подумать об асинхронности еще раз. Уже пытался придумать, как это реализовать, но как-то отвлекли.
Если задача не нравиться
Не нравится, когда не понимают разницы между формами слова «нравиться» и «нравится».
Спасибо! Достаточно актуально порешать эту тему с мульти-запросами.
А я сейчас реализовал этот алгоритм на php при оптимизации своей CMS — Оптимизация работы с деревьями (на примере многоуровнего меню)
Sign up to leave a comment.
Поиграем в CacheGraph?