Сайт стал дольше грузиться после перевода на Fenom

Доброй ночи!
Перевел тут один сайт на fenom — и он стал дольше грузиться. Полез проверять в чем дело. Оказывается, при загрузке страничке не из кэша, fenom очень даже выигрывает, а вот для кэшированных страниц, fenom всегда отдает контент медленнее. Но это на моем конкретном сайте, еще может быть с хостингом чего не того, поэтому решил проверить на mohost.pro.

И получил ту же ситуацию, причем, если смотреть через debugParser — он этого не показывает
s3703.h2.modhost.pro/index.php?id=4418&debug=1&cache=1с использованием fenom
s3703.h2.modhost.pro/index.php?id=4418
у ресурса с ID №1 около 5000 тысяч дочерних документов.
код, вызывается для верности х16 раз:
{$_modx->runSnippet('pdoResources',[
    'parents'    =>1,
    'limit'      =>4000,
    'depth'      =>0,
    'showLog'    =>0,
    'tpl'        =>'@INLINE {$id}-{$menuindex}-{$createdon}-{$publishedon}
'
])}
0.0004 s - Query Time - Shows how long MODx took talking to the database 
3 - Query Count -Shows how many database queries MODX made 
0.1051 s - Parse Time - Shows how long MODX took to parse the page 
0.1055 s - Total Time - Shows the total time taken to parse/ render the page 
cache - Source - Shows the source of page, whether is database or cache.
s3703.h2.modhost.pro/index.php?id=4417&debug=1&cache=1без fenom
s3703.h2.modhost.pro/index.php?id=4417
код, вызывается для верности тоже х16 раз:
[[pdoResources?
    &parents=`1`
    &limit=`4000`
    &depth=`0`
    &showLog=`0`
    &tpl=`@INLINE {{+id}}-{{+menuindex}}-{{+createdon}}-{{+publishedon}}
`
]]
0.0002 s - Query Time - Shows how long MODx took talking to the database 
2 - Query Count -Shows how many database queries MODX made 
0.0634 s - Parse Time - Shows how long MODX took to parse the page 
0.0636 s - Total Time - Shows the total time taken to parse/ render the page 
cache - Source - Shows the source of page, whether is database or cache.
И что в итоге? конечно на таком лабораторном сайте разница не такая как на боевом, но у меня получилось что fenom при загрузке из кэша всегда проигрывает, около 40мс.

Как победить эту задержку?

UPD:
пароль на админку: MJK5OJm77Nef

UPD: если кто захочет повторить тест, вот так создается куча ресурсов в modx:
<?php
for($i=1;$i<5000;$i++){
$response = $modx->runProcessor('resource/create', array(
    'pagetitle' => $i
    ,'parent' => 1
    ,'template' => 1
    ,'published' => 1
));

}
И вот так можно посмотреть время выполнения:
<b>[^qt^]</b> - Query Time - Shows how long MODx took talking to the database 
<b>[^q^]</b> - Query Count -Shows how many database queries MODX made 
<b>[^p^]</b> - Parse Time - Shows how long MODX took to parse the page 
<b>[^t^]</b> - Total Time - Shows the total time taken to parse/ render the page 
<b>[^s^]</b> - Source - Shows the source of page, whether is database or cache.
Алексей
08 декабря 2015, 19:52
modx.pro
1
3 349
0

Комментарии: 11

Fi1osof
09 декабря 2015, 15:21
+1
Суть проблемы кроется в кешировании контента отработанного документа. В штатном режиме, если прописаны кешируемые элементы, в кеш ресурса пишется конечный HTML. Вот на примере вашего сайта: joxi.ru/D2PjRW0SddY6Zr
А в случае с феном в кеш пишется сырой контент, а не конечный HTML joxi.ru/DrlaPn9i44JxXm и он отрабатывается каждый раз даже при работе из кеша. Отсюда и потеря в производительности.
    Василий Наумкин
    09 декабря 2015, 16:22
    0
    Это потому, что парсер pdoTools подлезает в самом конце, уже после сохранения кэша документа.

    Если подлезать раньше, то начинаются другие проблемы, поэтому оставил пока так.
      Fi1osof
      09 декабря 2015, 21:03
      0
      Да, сталкивался с проблемами «До и После» в phpTemplates. Понимаю о чем ты. Тогда вот такой вопрос: как можно в сниппете отпарсить полностью чанк с феномом? К примеру, делаем сниппет fenom и вызываем [[fenom?chunk=`myChunk`]], а в сниппете этом выполняем типа $modx->pdoTools->getChunk($chunk), только так, чтобы возвращался уже полностью отпарсенный чанк. Тогда MODX должен будет в кеш страницы сложить уже конечный результат кешируемого сниппета [[fenom?chunk=`myChunk`]]. А если делаем не кешируемым [[!fenom?chunk=`myChunk`]], то соответственно он будет каждый раз отрабатываться. Тогда будет все ОК с управлением кеширования. Или в данном случае топикстартеру достаточно было содержимое контента закинуть в отдельный чанк и в контенте прописать только вызов кешируемого чанка?
        Василий Наумкин
        09 декабря 2015, 21:10
        1
        +2
        Да, можно делать отдельным сниппетом:
        <?php
        $pdo = $modx->getService('pdoTools');
        if (!$isset($placeholders)) {
        	$placeholders = array();
        }
        
        return $pdo->getChunk($tpl, $placeholders);

        Можно вообще не использовать Fenom в контенте страницы и шаблонах, а только в чанках — это самый простой и беспроблемный способ работы. Именно он по умолчанию и включен.
          Fi1osof
          09 декабря 2015, 21:13
          +1
          А, ну тогда ОК, тогда и разобрались.
            Алексей
            10 декабря 2015, 10:37
            0
            тоесть, если у меня в шаблоне стоит следующий вызов через fenom
            {$_modx->resource->pagetitle}
            , то его надо заменить на вызов чанка
            [[$pagetitle]]
            и уже в коде чанка pagetitle вызывать свой fenom:
            {$_modx->resource->pagetitle}
            И тогда все будет работать как надо?
          Fi1osof
          05 января 2016, 17:36
          0
          Кстати, Василий, только сейчас вот переосмыслил вот эту твою фразу (с учетом этой информации):
          Это потому, что парсер pdoTools подлезает в самом конце, уже после сохранения кэша документа.
          Очень сомневаюсь, что твой парсер может влезть уже после сохранения кеша, так как кеш сохраняется вообще в самую последнюю очередь, когда уже все отработано и скрипт в принципе завершает свою работу. Для этого навешивается специальный метод. Соответственно, если у тебя есть уже отработанный HTML, ты по тому же принципу можешь передать ресурсу код для кеширования и у тебя в кеше нормальный HTML будет. Важно только чтобы некешируемые элементы так и остались в этом коде элементами.
        Василий Наумкин
        09 декабря 2015, 16:20
        +1
        Зашел на сайт, он на тестах показывает ошибку, что маловато памяти. Установил выборку 1 раз 1000 ресурсов, вызываю по очереди всё. Перед первым вызовом делаю полную очистку кэша.

        Не Fenom
        1 запуск — 0.2594 s
        2 запуск — 0.0522 s

        Fenom
        1 запуск — 0.2845 s
        2 запуcк — 0.0674 s

        Разница в районе погрешности на простейших чанках и 1000 итераций. Если такой результат не устраивает, всегда можно вернуться к сниппету IF и фильтрам вывода.
          Алексей
          09 декабря 2015, 20:46
          0
          ок, информацию принял! спасибо за ответ, а то я уж думал это только у меня так.
          К слову сказать, sitemap на синтаксисе fenom при ~50000 страниц становится нерабочим для яндекса (слишком долгий ответ сервера, яндекс гарантированно такой сайтмап отвергнет, главное вовремя обнаружить :-) ). Из-за чего и весь сыр-бор. Откатился, и сделал все по-старинке на обычных {{+pls}} pdoTools.
          Слава богу что и так работает! Очень удобно все делать на fenom. Чего только стоят массивы вместо JSON в join'ах, select'ах и where'рах.
          PS: Последний раз использовал IF года два назад
            Василий Наумкин
            09 декабря 2015, 21:02
            +1
            А нафига в карте сайта Fenom-то? Да еще и на 50 000 документов. Тогда хоть кэширование скомпилированных чанков надо включать.

            А вообще, там просто str_replace нужен, он по умолчанию и используется.
              Fi1osof
              09 декабря 2015, 21:06
              5
              +3
              Да, 50к — это явно перебор. Лучше делать сайтмап с постраничностью. Вот такое у меня норм работает, поисковики нормально на автомате кушают.
            Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.
            11