Идеология кэширования в проекте
Имеется готовый магазин на чистом php, в связи с чем скорость генерации страницы с товаром = 0,01 сек.
Интегрирую его с ModX, чтобы иметь возможность быстро и просто упаравлять контентом большой информационной части. В целом все нормально интегрировалось, ModX лежит в отдельной базе, данные клиентов и товаров в отдельной (для дополнительной безопасности и скорости).
Скорость работы ModX с контентом устраивает полностью. Проблемы возникают при выводе товаров и каталога из-за моего недостатка опыта работы с системой.
На сайте используются ЧПУ, обрабатываемые на уровне ядра магазина (того, который не относится к ModX). Когда url ведет на товар или раздел каталога, ядро по url вычисляет элемент в базе и выводит контент элемента.
Для того, чтобы интегрировать магазин и ModX я использовал следующую схему:
1. Подвесил плагин на OnPageNotFound, который обрабатывает URL. Если ModX не нашла контент в своей базе, магазин начинает искать товар и раздел каталога в своей.
2. Создал ресурсы «Товар» и «Каталог» в ModX в которых просто вызываются сниппеты [[!GetGoods] и [[!GetCatalog]] соответственно.
3. Плагин, если находит товар в базе магазина делает форвард на созданный ресурс:
В результате все работает, но не так быстро как хотелось бы. Причина кроется в том, что ModX не кэширует ресурс «Товар» и каждый раз, когда на него осуществляется sendForward создает страницу заново. В итоге страница создается за 0,2-0,3 секунды.
И беда даже не в моих сниппетах, по которым стоит запрет кэширования, они также отрабатывают за 0,01 сек. Мешают сниппеты ModX'а (Wayfinder, getResource и т. д.), используемые в шаблоне страницы, по ним кэширование разрешено, но оно не осуществляется.
Кто что подскажет? Как можно ускорить работу системы? Хочу, чтобы либо Wayfinder кэшировался, либо (в идеале) кэшировалась вся страница с товаром.
Интегрирую его с ModX, чтобы иметь возможность быстро и просто упаравлять контентом большой информационной части. В целом все нормально интегрировалось, ModX лежит в отдельной базе, данные клиентов и товаров в отдельной (для дополнительной безопасности и скорости).
Скорость работы ModX с контентом устраивает полностью. Проблемы возникают при выводе товаров и каталога из-за моего недостатка опыта работы с системой.
На сайте используются ЧПУ, обрабатываемые на уровне ядра магазина (того, который не относится к ModX). Когда url ведет на товар или раздел каталога, ядро по url вычисляет элемент в базе и выводит контент элемента.
Для того, чтобы интегрировать магазин и ModX я использовал следующую схему:
1. Подвесил плагин на OnPageNotFound, который обрабатывает URL. Если ModX не нашла контент в своей базе, магазин начинает искать товар и раздел каталога в своей.
2. Создал ресурсы «Товар» и «Каталог» в ModX в которых просто вызываются сниппеты [[!GetGoods] и [[!GetCatalog]] соответственно.
3. Плагин, если находит товар в базе магазина делает форвард на созданный ресурс:
$modx->setPlaceholder('GoodsID', $GoodsID);
$modx->sendForward(1340);В результате все работает, но не так быстро как хотелось бы. Причина кроется в том, что ModX не кэширует ресурс «Товар» и каждый раз, когда на него осуществляется sendForward создает страницу заново. В итоге страница создается за 0,2-0,3 секунды.
И беда даже не в моих сниппетах, по которым стоит запрет кэширования, они также отрабатывают за 0,01 сек. Мешают сниппеты ModX'а (Wayfinder, getResource и т. д.), используемые в шаблоне страницы, по ним кэширование разрешено, но оно не осуществляется.
Кто что подскажет? Как можно ускорить работу системы? Хочу, чтобы либо Wayfinder кэшировался, либо (в идеале) кэшировалась вся страница с товаром.
Комментарии: 5
Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.
2. Стандартаные сниппеты лучше сразу заменить на аналоги из pdoTools.
3. Если все товары выводятся через одну страницу, то она не может кэшироваться в принципе. Иначе у всех товаров будет одно название и свойства =)
Ну и генерация страницы за 0,2 — 0,3 сек — это хорошая скорость. У нас тут на modx.pro до 0,7 бывает и вроде нет ощущения, что сайт тормозит.
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 ресурс в переменную, сохранить ее в кэш, а потом вывести. Просто не знаю, насколько это правильный подход и как сделать такого рода перенаправление.
В общем, я ищу идеи, как быть в такой ситуации.
Да это я согласен. Описанная система уже работает на реальном магазине и никто не жалуется, но я же вижу подскочившую в 10 раз нагрузку на сервер, меня это раздражает. И в теории я теперь могу туда впихнуть ровно в 10 раз меньше сайтов, поэтому пытаюсь оптимизировать процесс.
Кроме того, одно дело 0,7 сек на генерацию, а потом 0,001 сек на чтение из кэша, и совсем другое — 0,2 сек на постоянную генерацию. :(
Можно использовать getCache — он закэширует принудительно что угодно. Ну и у pdoMenu есть своё кэширование, и у pdoPage.
Посмотреть, какой именно сниппет тормозит при выводе страницы можно через debugParser.
А debugParser прикуплю на днях, полезная штука.
Еще раз спасибо.