Fenom парсер - производительность и кэш
update: Выводы таковы: автор модуля — хам, а в самом pdoTools снипеты не корректно кешируются, и при кешируемом вызове — лезут в базу и тормозят работу. Снипеты в modx должны кешироваться по определению, если их вызывать без!.. Автор модуля признал, что проблема есть, но не считает падение производительности проблемой, увы
Сделал на одном сайте два простых одинаковых шаблона, один на fenom, другой на модкс синтаксисе и заметил, что fenom медленнее работает, особенно, когда уже есть кэш. Такое впечатление, что он не все берет из кеша, в отличии от дефолтного синтаксиса.
Вот к примеру добавляю загрузку словаря на феном версии
{$_modx->lexicon->load('dic:default')}
{$_modx->lexicon('dic_test')}Получается он как бэ кеширует этот код но не до конца.
На шаблоне же без фенома аналогичный код, который выводит ту же запись из словаря:
[[%dic_test? &namespace=`dic`]]Аналогичная штука ситуация и во многих других случаях, например:
{'pdoCrumbs' | snippet : [
'showAtHome' => '0',
'showHome' => '1'
]}Тогда как аналогичный вызов:
[[pdoCrumbs?
&showAtHome=`0`
&showHome=`1`
]]В итоге у меня в простом шаблоне фенома 22 запроса при повторном обращении к ресурсу.
А на таком же шаблоне без фенома — 12.
При этом на некешированном обращении к тому же ресурсу 67 запросов на стандартном синтаксисе и 72 на феноме. тут разрыв не такой большой, но все равно феном проигрывает.
И вся эта ситуация отчетливо заметна на скорости загрузки в браузере.
При первом обращении к странице после сброса кеша разница небольшая (5%-10% в пользу стандартного), а последующие обращения когда уже есть кеш — процентов 30% в пользу стандартного.
Может кто подскажет, это нормальное поведение? или может какие то косяки в настройках кеширования где то?
опция кеширования скомп. чанков фенома до лампочки, как и пишет автор плагина
Комментарии: 37
Добавление комментариев отключено
С вторим нужно смотреть.
в его случае кешированная загрузка не кушает дополнительный запрос в отличии от:
Глюк с кешированием чанков, обрабатываемых феномом? Ведь по идее я вызываю pdoCrumbs кешировано в обоих вариантах, в т.ч. и втором, где нет воскл. знака. Если кстати я его ставлю во втором варианте то он жрет не на одну кваери болше, а на 3. То есть некешированый вызов как бы срабатывает, но не до конца… а выходит вызов с насильным применением cacheManager фиксит этот глюк и приравнивает вызов к вызову через [['snippet']]?
Рабочий пример:
Cтатья от Ильи Уткина по данному вопросу Ссылка
Кроме того оборачивать каждый снипет еще одним — будет в два раза больше снипетов. А сделав один универсальный снипет-обретку, которому подсовывать имя нужного снипета, то все равно будет проблема с передачей пргментов, это получается снипет-обертку нужно будет обучить всем возможных аргументам для всех возможных вызываемых снипетов… Или как то можно написать обертку, чтобы она брала все аргументы и все отдавала таргетному снипету? сделать какой-то enum params?
конечно же в данном случае там имеет смысл время 0 задавать (бесконечно хранить)… ну да, помогает оно, кеш тогда работает правильно на феноме. Но каждый вызов каждого снипета оформлять такой жуткой хренью… совсем не кошерно, прям огромная ложка дегтя в бочке с феномом:)
UPD: не, не помогает такой вариант:
все равно недокешируется:
3 {pdoCrumbs | snippet: Array ( [showAtHome] => 0 [showHome] => 1 [cacheTime] => 0 ) } 3 0.0030658 0.0148139
в отличии от варианта с обертыванием
С Fenom всё иначе, там код есть всегда, но в зависимости от вызова, он либо грузит данные из кэша сниппета, либо работает без него. В любом случае, сами тэги всегда нужно обработать, в кэше они сохранятся как теги, а не как результат.
Лично мне такая более предсказуемая система нравится гораздо больше, чем вечная угадайка с тегами MODX. Работают они, или нет? Что туда попадает, и как отрендерится? Каждый второй совет по проблемам в MODX — это почистить кэш, и регулярный ответ «кэш чистили, не помогает».
Ну а кому ближе логика работы тегов MODX — их и используйте. Бездумное переписывание вообще всего на Fenom не ускорит ваш сайта автомагически, нужно понимать что, где и зачем вы делаете.
Но сами теги Fenom в ресурсе остаются, и их Fenom обрабатывает всегда. А вот теги MODX заменяются в кэше на результат, поэтому их парсить повторно не нужно.
Это всё пишу по памяти, могу ошибаться, да и поменять что-то могли.
Дело не в количестве запросов, а во времени их выполнения.
А вот проблема с кэшированием все таки наблюдается. Обратите, пожалуйста, внимание на мои скрины с дебагом, как раз при появлении лишних запросов к бд снипетами, которые должны быть закэшированы, и проявляется существенное проседание скорости. Когда я эти снипеты прячу в обертку через getCache, запросы лишние уходят и при этом время отработки значительно сокращается. Но это ведь не выход. И конечно же главный параметр для сравнения — скорость, а количество запросов — это уже как следствие, чтобы разобраться где кроется проблема. Ну и исходя из результатов по скорости я все таки бы отнес данный эффект к проблемам, а не к особенностям работы системы. На самом то деле мне все равно запилить небольшой интернет-магазин на мод-икс синтаксисе или на феном, мне даже проще на моде, потому что я с ним ранее работал. Просто хотелось бы внести вклад в развитие Вашего продукта и донести информацию о том, что проблема все таки есть… Ну или если я делаю что-то не так, пожалуйста, помогите разобраться, думаю, что решение будет полезно многим
Не нужна работа с файлами, не нужно наследование шаблонов, не нужны циклы и функции, присвоение переменных — не мучай себя, работай с парсером MODX, раз он супербыстрый.
Может потом вдруг окажется, что из-за костылей с парсером, когда нужно вызвать несколько сниппетов, вместо одного цикла, у тебя просадки по скорости выйдут значительно серьёзнее.
Вместо того, чтобы использовать снипет [[If]] с адским синтаксисом или писать новый снипет, пконечно удобней реализовать на феноме {If…
Просто не пойму, это у меня только такой глюк, что он лезет в базу при чтении каждого кешированного снипета, или нормальное поведение? Определил ведь уже, что протормозы то именно из за этого
PS: Ну а с костылем-оберткой в кэшер — просто эксперимент был по предложенному коду… конечно такое оставлять в продакшине нельзя, да и уже заметил, что оно глючно работает с этой оберткой, элементы меню путает в pdoMenu, названия страниц в pdoCrumbs.
— Fenom дёргает pdoTools::runSnippet()
— Тот дёргает pdoTools::_loadElement()
— Ну а тот делает modX::getObject() для получения содержимого сниппета из БД
Вот и лишний запрос. Наверное, можно переписать так, чтобы без запроса проверять кэш, но пусть это делает тот, кому это сильно надо.
Другой вопрос — кто в состоянии и знает как и где что править, автор расширения почему-то приходит на ум первым :)) Если нет времени это делать, покажи файлы, части кода где это можно исправить — и кто-то из комюнити исправит, у кого хватит скилов, дадут тебе обратно исправленный код и выложишь в репозитории. Поставь задачу сообществу — и наверняка кто-то из нас сделает. Нет проблем. Стороннему человеку (не автору кода) найти в чужом коде что-то — проблема куда большая чем для человека, который его писал и проектировал изначально. Поэтому без твоей поддержки тут будет сложновато :)
А вот до сих пор никому было не нужно. Да и сейчас толпы желающих не видно, ты один.
Отсутствие кэширования чего-либо, это не глюк.
Голословно. Fenom выигрывает в производительности за счёт других возможностей.
«Покажи», «кто-то исправил» — хорошо устроился. Тебя волнует — ты и исправляй, не жди никого.
Разрешите выполнять? Бегом?
Ну так ты чего тут сидишь, раз нет проблем?
Да вот вообще никакого желания тратить своё время на тебя нет.
Тему закрываю, всё осудили.