Это по идее должно быть надо любому пользователю шаблонизатора феном на modx, ибо глюки не нужны никому, особенно которые на ровном месте занижают производительность. И это однозначно правильно отнести к глюкам а не просто «плохой оптимизации», потому что кеширование — это одно из основных достоинств modx…
Другой вопрос — кто в состоянии и знает как и где что править, автор расширения почему-то приходит на ум первым :)) Если нет времени это делать, покажи файлы, части кода где это можно исправить — и кто-то из комюнити исправит, у кого хватит скилов, дадут тебе обратно исправленный код и выложишь в репозитории. Поставь задачу сообществу — и наверняка кто-то из нас сделает. Нет проблем. Стороннему человеку (не автору кода) найти в чужом коде что-то — проблема куда большая чем для человека, который его писал и проектировал изначально. Поэтому без твоей поддержки тут будет сложновато :)
Да я не мучаюсь, интересно уже докопаться до истины, и мне то как раз нравится функционал фенома: и условия с циклами, и наследование шаблонов особенно, да и сам синтаксис php логичный вполне.
Вместо того, чтобы использовать снипет [[If]] с адским синтаксисом или писать новый снипет, пконечно удобней реализовать на феноме {If…
Просто не пойму, это у меня только такой глюк, что он лезет в базу при чтении каждого кешированного снипета, или нормальное поведение? Определил ведь уже, что протормозы то именно из за этого
PS: Ну а с костылем-оберткой в кэшер — просто эксперимент был по предложенному коду… конечно такое оставлять в продакшине нельзя, да и уже заметил, что оно глючно работает с этой оберткой, элементы меню путает в pdoMenu, названия страниц в pdoCrumbs.
Не должен, а лезет в базу все равно, массив есть в кеше документа, снипеты кешируемые тоже в нем есть, то есть выходит, что снипеты в кеш сохраняются, а запросы в базу идут:
Верю :) Поэтому исходя от впечатления высокого качества Ваших продуктов и взялся попробовать сделать решение именно на феном, вот я и хочу тоже научиться писать с его применением так, чтобы все работало максимально быстрее… При этом я не переделываю существующий сайт под феном, а пытаюсь с нуля его сделать, сравнивая шаблоны на одном и другом синтаксисе.
А вот проблема с кэшированием все таки наблюдается. Обратите, пожалуйста, внимание на мои скрины с дебагом, как раз при появлении лишних запросов к бд снипетами, которые должны быть закэшированы, и проявляется существенное проседание скорости. Когда я эти снипеты прячу в обертку через getCache, запросы лишние уходят и при этом время отработки значительно сокращается. Но это ведь не выход. И конечно же главный параметр для сравнения — скорость, а количество запросов — это уже как следствие, чтобы разобраться где кроется проблема. Ну и исходя из результатов по скорости я все таки бы отнес данный эффект к проблемам, а не к особенностям работы системы. На самом то деле мне все равно запилить небольшой интернет-магазин на мод-икс синтаксисе или на феном, мне даже проще на моде, потому что я с ним ранее работал. Просто хотелось бы внести вклад в развитие Вашего продукта и донести информацию о том, что проблема все таки есть… Ну или если я делаю что-то не так, пожалуйста, помогите разобраться, думаю, что решение будет полезно многим
Так по факту получается, что феном при кешированном вызове сниппета не просто тэг парсит, а запрос в БД делает зачем-то, отсюда и основная потеря производительности
Эту опцию пробовал тоже — не влияет, как и писал автор. Кстати, вариант с обертками при разработке тоже опасен: изменения в коде обертки не обновляют этот кастомный кэш, и снипеты при этом начинают глючить, нужно всегда помнить чтобы чистить кэш руками после изменений.
Сайт небольшой — понятно, и если насильно закешировать оберткой снипеты, то производительность не сильно падает… Однако без оберток-костылей все кешируемые снипеты кушают плюс один запрос, это явно глюк, может автора попросить глянуть пофиксить ?)
ради интереса обернул кеш-враппером каждый вызов кешируемых снипетов, ситуация стала лучше, но все равно феном медленнее чем мод-икс при кешированных запросах.
Инлайн был взят из примера по pdoTools, а разве такие маленькие инлайны хуже чанков? ведь чанк — это плюс запрос к бд. а инлайн он уже есть тут прям сразу де факто.
По поводу времени кеш тайм. а смысл его задавать? Как я понимаю через это время кеш будет считаться очищенным, а этого не хотелось бы, например страницы с редкой посещаемостью и редкой частотой обновления будут страдать и лишаться кеша раньше, чем могли бы без этого ограничения
конечно же в данном случае там имеет смысл время 0 задавать (бесконечно хранить)… ну да, помогает оно, кеш тогда работает правильно на феноме. Но каждый вызов каждого снипета оформлять такой жуткой хренью… совсем не кошерно, прям огромная ложка дегтя в бочке с феномом:)
Поставил дебагПарсер (спасибо за подсказки), благодаря ему нашел один провтыканый тег [[]] в феном шаблоне, убрал. картина особо не поменялась. На свежую без кеша феном чуть чуть делает мод-икс. А с кешем все плохо, выходит все снипеты на феноме глючно кешируются (недокешируются). разницы между include и insert при подгрузке шаблона из файла не заметил.
Ну это будет костыль по сути дела, ведь проблема похоже кроется в парсинге именно феномом, так как на дефолтном синтаксисе кеш работает полностью на тех же сниппетах.
Кроме того оборачивать каждый снипет еще одним — будет в два раза больше снипетов. А сделав один универсальный снипет-обретку, которому подсовывать имя нужного снипета, то все равно будет проблема с передачей пргментов, это получается снипет-обертку нужно будет обучить всем возможных аргументам для всех возможных вызываемых снипетов… Или как то можно написать обертку, чтобы она брала все аргументы и все отдавала таргетному снипету? сделать какой-то enum params?
Глюк с кешированием чанков, обрабатываемых феномом? Ведь по идее я вызываю pdoCrumbs кешировано в обоих вариантах, в т.ч. и втором, где нет воскл. знака. Если кстати я его ставлю во втором варианте то он жрет не на одну кваери болше, а на 3. То есть некешированый вызов как бы срабатывает, но не до конца… а выходит вызов с насильным применением cacheManager фиксит этот глюк и приравнивает вызов к вызову через [['snippet']]?
Другой вопрос — кто в состоянии и знает как и где что править, автор расширения почему-то приходит на ум первым :)) Если нет времени это делать, покажи файлы, части кода где это можно исправить — и кто-то из комюнити исправит, у кого хватит скилов, дадут тебе обратно исправленный код и выложишь в репозитории. Поставь задачу сообществу — и наверняка кто-то из нас сделает. Нет проблем. Стороннему человеку (не автору кода) найти в чужом коде что-то — проблема куда большая чем для человека, который его писал и проектировал изначально. Поэтому без твоей поддержки тут будет сложновато :)
Вместо того, чтобы использовать снипет [[If]] с адским синтаксисом или писать новый снипет, пконечно удобней реализовать на феноме {If…
Просто не пойму, это у меня только такой глюк, что он лезет в базу при чтении каждого кешированного снипета, или нормальное поведение? Определил ведь уже, что протормозы то именно из за этого
PS: Ну а с костылем-оберткой в кэшер — просто эксперимент был по предложенному коду… конечно такое оставлять в продакшине нельзя, да и уже заметил, что оно глючно работает с этой оберткой, элементы меню путает в pdoMenu, названия страниц в pdoCrumbs.
А вот проблема с кэшированием все таки наблюдается. Обратите, пожалуйста, внимание на мои скрины с дебагом, как раз при появлении лишних запросов к бд снипетами, которые должны быть закэшированы, и проявляется существенное проседание скорости. Когда я эти снипеты прячу в обертку через getCache, запросы лишние уходят и при этом время отработки значительно сокращается. Но это ведь не выход. И конечно же главный параметр для сравнения — скорость, а количество запросов — это уже как следствие, чтобы разобраться где кроется проблема. Ну и исходя из результатов по скорости я все таки бы отнес данный эффект к проблемам, а не к особенностям работы системы. На самом то деле мне все равно запилить небольшой интернет-магазин на мод-икс синтаксисе или на феном, мне даже проще на моде, потому что я с ним ранее работал. Просто хотелось бы внести вклад в развитие Вашего продукта и донести информацию о том, что проблема все таки есть… Ну или если я делаю что-то не так, пожалуйста, помогите разобраться, думаю, что решение будет полезно многим
UPD: не, не помогает такой вариант:
все равно недокешируется:
3 {pdoCrumbs | snippet: Array ( [showAtHome] => 0 [showHome] => 1 [cacheTime] => 0 ) } 3 0.0030658 0.0148139
в отличии от варианта с обертыванием
конечно же в данном случае там имеет смысл время 0 задавать (бесконечно хранить)… ну да, помогает оно, кеш тогда работает правильно на феноме. Но каждый вызов каждого снипета оформлять такой жуткой хренью… совсем не кошерно, прям огромная ложка дегтя в бочке с феномом:)
Кроме того оборачивать каждый снипет еще одним — будет в два раза больше снипетов. А сделав один универсальный снипет-обретку, которому подсовывать имя нужного снипета, то все равно будет проблема с передачей пргментов, это получается снипет-обертку нужно будет обучить всем возможных аргументам для всех возможных вызываемых снипетов… Или как то можно написать обертку, чтобы она брала все аргументы и все отдавала таргетному снипету? сделать какой-то enum params?
в его случае кешированная загрузка не кушает дополнительный запрос в отличии от:
Глюк с кешированием чанков, обрабатываемых феномом? Ведь по идее я вызываю pdoCrumbs кешировано в обоих вариантах, в т.ч. и втором, где нет воскл. знака. Если кстати я его ставлю во втором варианте то он жрет не на одну кваери болше, а на 3. То есть некешированый вызов как бы срабатывает, но не до конца… а выходит вызов с насильным применением cacheManager фиксит этот глюк и приравнивает вызов к вызову через [['snippet']]?