Comments 12
Я может шокирую, но в Wayfinder'e есть &cacheResults.
Вы бы посмотрели как работает cacheResults у Wayfinder, а потом бы «шокировали». Да, Вайфайндер не делает запросы в БД каждый раз, а берёт массивы из файлов кэша, но во-первых кэш создаётся для каждого ресурса отдельно (возможно ошибаюсь), во-вторых меню он генерирует для каждой страницы заново.
Тут же (в menuCaching) в кэше хранится уже готовый HTML-код, а не какие-то массивы. Перед тем как писать сниппет я сравнил скорость с чистым Wayfinder. Результат очень существенный.
Тут же (в menuCaching) в кэше хранится уже готовый HTML-код, а не какие-то массивы. Перед тем как писать сниппет я сравнил скорость с чистым Wayfinder. Результат очень существенный.
но во-первых кэш создаётся для каждого ресурса отдельно (возможно ошибаюсь),Не ошибаетесь. Более того, он часто создает сразу несколько файлов кеша для одного и того же ресурса (ведь часто на странице несколько раз Wayfinder используется). Часто даже приходится отключать кеш для WF, потому что, к примеру, на одном из моих сайтов с 50000+ документов это было несколько Га кеша, и даже очистка кеша для сайта — задача была невыполнимая для админки, чистить приходилось через консоль.
Ваше решение — отличный компромисс между простотой, эффективностью и производительностью. Для сравнения можно даже глянуть эту попытку закешировать WF. Известные мне кеш-акселераторы тоже с этой задачей не справятся так изящно.
Вопрос только один: для текущей страницы свой кеш меню тоже создается (чтобы не пробегаться каждый раз по заготовке и не заменять все заготовки), или нет? И если есть, можно ли это отключать?
>>Вопрос только один: для текущей страницы свой кеш меню тоже создается (чтобы не пробегаться каждый раз по заготовке и не заменять все заготовки), или нет? И если есть, можно ли это отключать?
Если сниппет menuCaching вызывать кэшируемым (без! ), то всё попадает в общий кэш страницы и при последующем обращении этот сниппет вообще не используется.
Если сниппет menuCaching вызывать кэшируемым (без! ), то всё попадает в общий кэш страницы и при последующем обращении этот сниппет вообще не используется.
Кстати, вот такой еще вопрос: учитываете ли вы в сниппете такой момент, как различные группы ресурсов и доступы к ним? То есть если есть скрытые ресурсы, зашел пользователь с правами на них, они закешировались в общее меню, а потом зашел лимитированный пользователь, а ему так же меню со скрытыми ресурсами выводится.
Пока внутри сниппета это не учтено, но можно сделать так:
[[!menuCaching@top_menu?cacheSuffix=`[[!+modx.user.id:memberof=`Administrator`]]`]]
[[!menuCaching@top_menu?cacheSuffix=`[[!+modx.user.id:memberof=`Administrator`]]`]]
Ну это заточка под конкретную группу, но направление понятно. Можно было бы сделать просто [[!menuCaching@top_menu?cacheSuffix=`[[!+modx.user.id`]]`]], если количество пользователей не большое (в пределах 500-1000). Это было бы точно четкое распределение. Но если особых хитростей в настройках политик нет, то можно и съэкономить на количестве кеш-файлов так [[!menuCaching@top_menu?cacheSuffix=`[[!getGroup]]`]] и прописать в нем возврат id группы. В любом случае это будет гораздо меньшая нагрузка, чем с чистым Wayfinder, и контроль доступов обеспечен.
В общем, решение зачетное!
В общем, решение зачетное!
А вот бы тесты скорости против Wayfinder и getResources увидеть.
Тесты попробую сделать. Особенно прирост скорости будет заметен на менюшках таких как показано на картинке в посте (с выпадашками). Если кто-то опередит и сделает такой тест, буду благодарен.
Готовы результаты тестирования (меню очень большое). Вызовы обоих сниппетов некэшированные, т.е. [[!snippet]] (для теста)
Wayfinder
Первый вызов любой из страниц где есть меню: 2.5815 сек.
Переход на любую другую страницу с этим же меню: 2.4566 сек. (т.е. хвалёный cacheResults не помогает)
Обновляем страницу: 1.0021 сек. (только в этом случае cacheResults спасает)
Тот же Wayfinder, через menuCaching
Первый вызов любой из страниц где есть меню: 2.4842 сек. (в рамках погрешности, естественно разницы нет)
Переход на любую другую страницу с этим же меню: 0.7008 сек. (результат тот же, а время отличается)
Обновляем страницу: 0.4187 сек.
Демо:
Чистый Wayfinder: demo-revo.modx-shopkeeper.ru/testovyij-katalog-1/
menuCaching: demo-revo.modx-shopkeeper.ru/testovyij-katalog-2/
Итог: ходить по незакэшированным страницам не приятно (долго грузится сайт). А с menuCashing стоит открыть только одну страницу и остальные летают.
Wayfinder
Первый вызов любой из страниц где есть меню: 2.5815 сек.
Переход на любую другую страницу с этим же меню: 2.4566 сек. (т.е. хвалёный cacheResults не помогает)
Обновляем страницу: 1.0021 сек. (только в этом случае cacheResults спасает)
Тот же Wayfinder, через menuCaching
Первый вызов любой из страниц где есть меню: 2.4842 сек. (в рамках погрешности, естественно разницы нет)
Переход на любую другую страницу с этим же меню: 0.7008 сек. (результат тот же, а время отличается)
Обновляем страницу: 0.4187 сек.
Демо:
Чистый Wayfinder: demo-revo.modx-shopkeeper.ru/testovyij-katalog-1/
menuCaching: demo-revo.modx-shopkeeper.ru/testovyij-katalog-2/
Итог: ходить по незакэшированным страницам не приятно (долго грузится сайт). А с menuCashing стоит открыть только одну страницу и остальные летают.
Sign up to leave a comment.
Сниппет menuCaching для MODX Revolution