Минимизация размера кеша

[Koc]

Есть 2 куска html на странице, которые хочется закешировать

1. Вывод дерева категорий с подсветкой активной жирным: 1200 древовидных категорий, выбирается одним запросом, долговато гидрируются доктриной и потом еще в твиге небыстро шуршат

2. Вывод товаров, похожих данному (по городу, категории). Естественно основной товар мы не показываем.

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

Как быть? Подсвечивать активную категорию дополнительно жсом? Удалять текущий просматриваемый товар из списка похожих тоже жсом? Какие-то жжесткие хаки получаются.

 

[Breeze]

как вариант хранить один html и через dom добавлять атрибут активности на стороне сервера
тоже хак

 

[cDLEON]

кешируйте данные

 

[Breeze]

кешируйте данные

если еще не закешированы

 

[Koc]

кешируйте данные

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

как вариант хранить один html и через dom добавлять атрибут активности на стороне сервера
тоже хак

ага, и про регулярки/легкий strpos тоже думал)

 

[fixxxer]

для кэширования что нужно? ключ кэширования и инвалидация.

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

удобнее всего такое делать в рамках mvcc архитектуры, когда каждый компонент имеет свои входные параметры, однозначно мапящиеся на cache key, и сам рендерит кусок html-я. либо ввести промежуточный сервис по типу unit of work, который будет делать инвалидацию (или говорить о том, что ее надо сделать, наружу)

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

 

[fixxxer]

там сущности доктрины, они неважнецки сериализуются и скорость их сериализации/десериализации под вопросом

очень подивился, неужели такая навороченная махина как доктрина2 не имеет возможности всунуть кэш-адаптер? загуглил doctrine2 cache, ну вот же http://docs.doctrine-project.org/en/2.0.x/reference/caching.html

 

[Breeze]

ага, и про регулярки/легкий strpos тоже думал)

а про генерацию шаблона для твига?

 

[hell0w0rd]

https://github.com/asm89/twig-cache-extension - есть такая штука)
Но разве для подобного не нужно юзать HttpCache?

 

[Koc]

https://github.com/asm89/twig-cache-extension - есть такая штука)
Но разве для подобного не нужно юзать HttpCache?

да-да, вот именно это и хочу взять. Как раз это можно без http cache.

а про генерацию шаблона для твига?

не понял

очень подивился, неужели такая навороченная махина как доктрина2 не имеет возможности всунуть кэш-адаптер? загуглил doctrine2 cache, ну вот же http://docs.doctrine-project.org/en/2.0.x/reference/caching.html

как бы да, но потом вышла версия 2.2, и там

The result cache is completely rewritten and now works on the database result level, not inside the ORM AbstractQuery
anymore. This means that for result cached queries the hydration will now always be performed again, regardless of
the hydration mode.

а это довольно-таки ресурсоемкое действо.

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

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

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

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

 

[Breeze]

Koc

генеришь не чистый html, который хранишь в кеше, а plain шаблон для твига без циклов и т.д., максимум с if, куда можешь поставить всякие {{selected12345}} или что там есть
а дальше скормить ему массив с активными категориями

 

[Koc]

т.е. что-то типа

<a href="..." {% if id = 3 %} current {% endif %}>Самара</a>
<a href="..." {% if id = 4 %} current {% endif %}>Екатеринбург</a>
<a href="..." {% if id = 5 %} current {% endif %}>Орел</a>

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

 

[Breeze]

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

ЗЫ: и главное не забыть указать в комментарии в шаблоне, что он не сам по себе, а кто его генерит, чтобы не искать спустя 100 лет, откуда ж он такой взялся

 

[Koc]

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

 

[fixxxer]

а это довольно-таки ресурсоемкое действо

я понятия не имею, что такое hydration, но если орм для того, чтобы просто всосать raw database data, делает каждый раз ресурсоемкие операции, то не стоит брать такую орм для нагрузок выше 50 rps

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

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

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

то есть вместо того чтобы разобраться в том, что именно тормозит, тупо наворачиваем кэши сверху? оооооок.

 

[Koc]

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

да, теперь я понял. Но в данном случае инвалидацию сделать легко.

то есть вместо того чтобы разобраться в том, что именно тормозит, тупо наворачиваем кэши сверху? оооооок.

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

 

[fixxxer]

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

у меня такое бывало

 

[cDLEON]

ё-моё.... Ну так зачем брать этот тяжелый кирпич изначально то было ? Я, например, 1 раз запустил - и выбросил.Так же как и зенд. Мне хватило 1 раз запустить без опкешера все эти чудеса, что бы больше ни когда ни чего на них не писать.
PS. А метод который делает "hydration" переопределить нельзя?

 

[hell0w0rd]

https://github.com/doctrine/doctrine2/blob/2.4/lib/Doctrine/ORM/Internal/Hydration/ObjectHydrator.php ну переопредели... метод)

 

[cDLEON]

*бать мои старые костыли!