Идеология кэширования в проекте

Имеется готовый магазин на чистом php, в связи с чем скорость генерации страницы с товаром = 0,01 сек.

Интегрирую его с ModX, чтобы иметь возможность быстро и просто упаравлять контентом большой информационной части. В целом все нормально интегрировалось, ModX лежит в отдельной базе, данные клиентов и товаров в отдельной (для дополнительной безопасности и скорости).

Скорость работы ModX с контентом устраивает полностью. Проблемы возникают при выводе товаров и каталога из-за моего недостатка опыта работы с системой.

На сайте используются ЧПУ, обрабатываемые на уровне ядра магазина (того, который не относится к ModX). Когда url ведет на товар или раздел каталога, ядро по url вычисляет элемент в базе и выводит контент элемента.

Для того, чтобы интегрировать магазин и ModX я использовал следующую схему:
1. Подвесил плагин на OnPageNotFound, который обрабатывает URL. Если ModX не нашла контент в своей базе, магазин начинает искать товар и раздел каталога в своей.
2. Создал ресурсы «Товар» и «Каталог» в ModX в которых просто вызываются сниппеты [[!GetGoods] и [[!GetCatalog]] соответственно.
3. Плагин, если находит товар в базе магазина делает форвард на созданный ресурс:
$modx->setPlaceholder('GoodsID', $GoodsID);
$modx->sendForward(1340);
4. В ресурсе вызывается сниппет, который по плейсхолдеру заполняет контент.

В результате все работает, но не так быстро как хотелось бы. Причина кроется в том, что ModX не кэширует ресурс «Товар» и каждый раз, когда на него осуществляется sendForward создает страницу заново. В итоге страница создается за 0,2-0,3 секунды.

И беда даже не в моих сниппетах, по которым стоит запрет кэширования, они также отрабатывают за 0,01 сек. Мешают сниппеты ModX'а (Wayfinder, getResource и т. д.), используемые в шаблоне страницы, по ним кэширование разрешено, но оно не осуществляется.

Кто что подскажет? Как можно ускорить работу системы? Хочу, чтобы либо Wayfinder кэшировался, либо (в идеале) кэшировалась вся страница с товаром.
Константин
Константин
14 марта 2015, 10:15
modx.pro
1 354
0

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

Василий Наумкин
Василий Наумкин
14 марта 2015, 13:29
0
1. Работать лучше по OnHandleRequest — просто быстрее, чем когда MODX сам будет искать и не находить страницу. Ты же знаешь, какие url для вывода товаров?

2. Стандартаные сниппеты лучше сразу заменить на аналоги из pdoTools.

3. Если все товары выводятся через одну страницу, то она не может кэшироваться в принципе. Иначе у всех товаров будет одно название и свойства =)

Ну и генерация страницы за 0,2 — 0,3 сек — это хорошая скорость. У нас тут на modx.pro до 0,7 бывает и вроде нет ощущения, что сайт тормозит.
    Константин
    Константин
    14 марта 2015, 14:53
    0
    1. Спасибо. Это есть в планах, но я уже замерил производительность. До попадания в плагин проходит порядка 0,02 сек. Т.е. это не самое узкое место. Даже если перейду на OnHandleRequest — выиграю 0,01 сек.
    2. Попробую, может Wayfinder лучше заработает.
    3. Это в простейшем случае она не может кэшироваться, согласен. Но я же спрашиваю про то, как идеологически правильно заставить ее кэшироваться. Т.е. надо подразумевать, что я могу реализовать все что угодно, просто опыта работы с ModX не хватает, чтобы придумать качественный вариант (вот и спрашиваю у профессионалов).

    Мне в голову сразу приходит 2 варианта:
    1. Вполне достаточно кэшировать не всю страницу, а только некоторые сниппеты, как это происходит на страницах обычных ресурсов. Т.е. когда я пишу [[Wayfinder]] [[!getResources]] в content'е ресурса, в core\cache\resource сохраняются результаты вывода Wayfinder и используются в дальнейшем. Но вот в моем варианте для ресурса 1340 («Товар») в core/cache вообще ничего не сохраняется. :( Это приводит к тому, что Wayfinder, определенный в шаблоне ресурса, каждый раз жрет 0,07 сек. Где-то косяк. Если его найти, меня вполне устроит, что кэшироваться будет не вся страница.

    2. Можно закэшировать всю страницу своими силами. Сделать пустой шаблон, поставить туда сниппет GetFullPage, а внутри использовать $modx->cacheManager->get() / set(). Перенаправить, если это возможно, сгенерированный ModX ресурс в переменную, сохранить ее в кэш, а потом вывести. Просто не знаю, насколько это правильный подход и как сделать такого рода перенаправление.

    В общем, я ищу идеи, как быть в такой ситуации.

    Ну и генерация страницы за 0,2 — 0,3 сек — это хорошая скорость. У нас тут на modx.pro до 0,7 бывает и вроде нет ощущения, что сайт тормозит.
    Да это я согласен. Описанная система уже работает на реальном магазине и никто не жалуется, но я же вижу подскочившую в 10 раз нагрузку на сервер, меня это раздражает. И в теории я теперь могу туда впихнуть ровно в 10 раз меньше сайтов, поэтому пытаюсь оптимизировать процесс.

    Кроме того, одно дело 0,7 сек на генерацию, а потом 0,001 сек на чтение из кэша, и совсем другое — 0,2 сек на постоянную генерацию. :(
      Василий Наумкин
      Василий Наумкин
      14 марта 2015, 15:53
      0
      Но вот в моем варианте для ресурса 1340 («Товар») в core/cache вообще ничего не сохраняется
      Наверное, ресурс отмечен как «некэшируемый» в его настройках. Вот и не кэшируется ничего.

      Можно использовать getCache — он закэширует принудительно что угодно. Ну и у pdoMenu есть своё кэширование, и у pdoPage.

      Посмотреть, какой именно сниппет тормозит при выводе страницы можно через debugParser.
        Константин
        Константин
        17 марта 2015, 18:19
        0
        Огромное спасибо за помощь! Действительно ресурсы были некэшируемыми (убрал с них в свое время кэширование и забыл об этом). После установки кэширования страница повторно открывается за 0,02 сек. Этот результат устраивает на 100%, больше ничего изобретать не буду (разве что OnHandleRequest использую при анализе URL'ов).

        А debugParser прикуплю на днях, полезная штука.

        Еще раз спасибо.
Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.
5