дело не в сложности, а в best practice

в смысле кешировать результат запроса, а не вывод компонента?

понятно, что можно вызвать рендер шаблона за startCache(){}

просто гетлисты и прочие выборки в теле компонента уже в печенках. никакого повторного использования кода)

Тут главная проблема - инвалидация кэша. С шаблонами компонентов тегированный кэш как бы из коробки. А в моделях надо будет строить сложную структуру удаления кэша. Опять же могут быть коллизии при конкурентных запросах. В компоненте из БД получаются целостные данные и в кэш отправляется их представление. А в модели могут быть 100500 join на таблицы в которых данные уже изменились.

да, нам нужна атомарность разумеется и/или выдача старого кеша

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

инвалидация по тегам, да

в битриксе теги в БД сидят, и это не круто на больших оборотах

да, разумеется классы будут под каждую сущность

это либо выборка из ИБ, либо из ХИБ, редко что-то еще

С другой стороны можно забить на теги и удалять по CacheDir. Только надо для себя выработать оптимальную структуру раскидывания кэшей и их зависимости

Доброй ночи всем

Есть кто с генерацинй фидов сталкивался?

Если использовать Entity\Query, то в качестве ключей кеша можно использовать md5 от getQuery

Или от getFilter если состав полей не меняется

в "$USER->IsAutorized()"

Что делает -> ???

С другой стороны можно забить на теги и удалять по CacheDir. Только надо для себя выработать оптимальную структуру раскидывания кэшей и их зависимости

мы идем дальше - кеш в ОП. кешДир больше не работает, и становится просто тегом)

мы идем дальше - кеш в ОП. кешДир больше не работает, и становится просто тегом)

по сути он и есть просто тег. Формулировка - наследие файлового кэша )))

Если использовать Entity\Query, то в качестве ключей кеша можно использовать md5 от getQuery

getQuery будет доступен только перед самым исполнением запроса, после того, как он сформирован? это не очень удобно мне кажется. он же будет все равно по параметрам собираться.

Ну да. Сначала он формируется по фильтру. И собственно по хешу от getQuery мы узнаем, что запрос изменился/не изменился. И собственно вызываем query или отдаем кэш

в "$USER->IsAutorized()"

если юзер залогинился, то выдаст true

есть под рукой простое решение с тегами в ОП?) их нет в коробке у мемкеша и редиса.

Сорри, ОП это что?

Оперативная память?

да

если юзер залогинился, то выдаст true

Это я как раз понял, меня интесует сам оператор " -> ", никак не найду его роль

Посмотрел в исходники. Тегированный кеш без вариантов в БД

Это я как раз понял, меня интесует сам оператор " -> ", никак не найду его роль

Вызов метода класса. ООП

Ааа, вот почему я и не въехал, простите, и большое спасибо!

Посмотрел в исходники. Тегированный кеш без вариантов в БД

не уловил мысль

есть под рукой простое решение с тегами в ОП?) их нет в коробке у мемкеша и редиса.

С другой стороны можно написать собственную реализацию тегированного кеша, скопировав битриксовский класс и заменив вызов БД на обращение к мемкешу или редису или еще к чему

теперь понял - полюбому через бд, ок

да, можно и битрикс взять за основу

только сделать селект по мемкешу и редису не тоже, что по мускулу

но может и прокатит, у нас вроде всегда будут точные ключи в руках

да, можно и битрикс взять за основу

там все равно все сводится к получению ид и $cache->cleanDir($path);

так, стоп - это ничего не меняет. в мемкеше редисе можно удалить только по ключу, там нет тегов

есть патч к мемкешу, но не хочется пачкать руки, так сказать

только сделать селект по мемкешу и редису не тоже, что по мускулу

Не городить свой селект а тупо создать/забрать кэш из CacheDir "MySuperPuperTagCache" Стандартную работу с кэшем то никто не отменял)))

PHPCache

стандартная это на файлах и с тегами в БД?)

Можно вообще где-нить в onBeforeProlog инициализировать весь свой тегированный кэш стандартными методами, сериализовать и положить в кэш (хоть файловый, хоть мем) далее в своих компонентах использовать свою функцию получения тегов не из БД через стандартный битриксовский класс, а из кэша по уникальному CacheDir

так, что-то навороченно очень получилось

надо, что-то простое

Исли время кеша протухло, то опять забрать стандартными методами из БД

в общем вроде интересная тема?) работа с кешем вне компонентов и на больших данных, с тегами и в ОП, через свой класс-модель для сущности

Самое простое, как уже говорил. Продумать структуру CacheDir'ов и при изменении данных последовательно их чистить.

Неудачный пример был

$obCache->cleanDir($cache_dir_users); $obCache->cleanDir($cache_dir_cities); $obCache->cleanDir($cache_dir_countries); при изменении, например названия страны

Подумал тут. При кешировании запросов будут глюки с пагинацией. Если много юзеров смотрели страницу 1, а на страницу 3 зашло меньше народу, то у страницы 3 ттл будет позже чем у 1

да, страница 3 пересоберется раньше. если кешить, как обычно через компонент - будет по другому?

да, страница 3 пересоберется раньше. если кешить, как обычно через компонент - будет по другому?

Хотя да, в принципе то же самое

В общем задача не сильно сложная. Главное построить зависимости удаления кеша

Задача №2 после кэша. Действия над данными после запроса. Желательно будет всю информацию получить в запросе. Никаких getByID в цикле. Все пути к картинкам, файлам желательно будет получить в том же запросе, а это сложно при отношении один-ко-многим. Ну или комбинировать кеш запросов с кешем предствавлений

Или делать запись в кэше на каждый элемент с полным набором его свойств

воот

часто меняется один товар, и из-за него сгорает весь кеш еще 100500 товаров. хотя они реально не поменялись. так вот если хранить полную инфу по каждому товару отдельно, то можно делать агрегатную выборку буквально получая только ИД товара, чтобы остальные данные забрать уже из кеша по товару. Это сильно ускорит ребилд кеша.

а в период формирования кеша по товару - получения св-в - цен - скидок - торговых предложений - прочих вложенных сущностей - и тд можно сделать несколько оптимизированных, но отдельных запросов, чтобы все-таки было по человечески

Думаю, это неплохое сырье для новой статьи на тему эффективной работы с кешем. Будет что поразносить, ахах)

Зато Билл Клинтон не станет Первой леди.

Однако доброе утро!

Американцы в чате?)

Зато Билл Клинтон не станет Первой леди.

всю ночь не спал наверное, за Трампа болел?

да блин проснулся. сижу на толчке и читать больше нечего. кругом истерия. кругом пздц творицца. путина так громко не избирали, как эти истерички.

ERROR: S client not available

даже мать его нефть и доу джонс упали в обмором.

А бан есть тут?

дятлы блин

меня?

запахло жареным пуканом

вообще

есть такое. подгорает

вообще

нет, вроде. к илье можно обратиться чтобы выгнать. а так удобно выключить нотификации.

у нас выборы тише потому что результат заранее известен

Block user

ладно. я помолчу.

вообще

есть

спс

Лёх, откуда такие страсти?)

Лёха проснулся в плохом настроении, спросил в первый попавшийся чатик про бан, узнал что бан есть и ушёл материться в другой чат.

)))

Настроение хорошее, просто подгорает...

Друзья есть кто работает с нерезидентами РФ по безналичному расчету?

да

стоп. в качестве кого?

в качестве исполнителя

да

как оформляешь отношения?

можешь поделиться рыбой договора и счета с актом?

точно так же, как и с резидентами

за услуги по разработке интересует в первую очередь

точно так же, как и с резидентами

у валютного контроля вопросов не возникает?

договор обычный по законам РФ с оплатой в рублях. счета и акты по стандартным правилам той страны, с кем работаю

у валютного контроля вопросов не возникает?

нет, оплата в рублях