Не знаю технической стороны вопроса.
Может быть можно создать какой-то модуль, который, как 
по расписанию, например ночью, выполнял запросы на генерацию кеша? Тем самым не пользователь и не робот ПС ожидают генерации, тем самым ухудшение отношения и со стороны робота (у него время на индексацию ограниченно) и пользователя.
Такое вообще возможно?
1 лайк
Добрый день, проблема такая действительно есть. В ближайшее время изучим и попробуем найти оптимальные варианты решения.
Спасибо за обратную связь.
2 лайка
Вчера под вечер ровно то же в голову пришло.
Очевидно необходим автопроходчик.
Это называется прогрев кеша, пишется за полдня. Потом просто пробегается по сайтмапу, в 1 поток на закрытом магазине. Можно использовать любой сеошный робот, сейчас их полно, тот же нетпик.
1 лайк
Это всё костыльные решения (проходы по сайтмапу и т.д.) и изначально нужно организовать правильный подход к первой генерации кеша хотя бы для главной страницы. Самой простой пример для избежания race condition описан в первом сообщении. В теории этого вполне достаточно для решения проблемы с нагрузкой при отсутствии кеша и наплыва посетителей, ботов.
Прогрев кеша пока был и остается единственным вменяемым решением в большинстве проектов. Но каждый судит из своей колокольни и исходя из своего опыта.
1 лайк
Давно хотел спросить - как быть с кэшем, если используется модуль геолокации с блоком, выводящим название населенного пункта посетителя?
Получается, подогрев кэша нужно делать для всех более-менее значимых городов?
Кешируются блоки и выборки из базы данных, app/schemas/block_manager/blocks.php тут можно посмотреть что кешируется. Аддоны расширяют эту схему.
Тут надо делать с оглядкой, например, если в момент, когда существует файл .cache-delay перегрузить сервак, файл останется, и будет висеть вечно пока не удалить его руками. Такое непотребство сейчас существует с модулем “YML экспорт”. Так что нужно проверять время создания и если оно слишком старое, удалять его и запускать процесс вновь.
Добрый день, для решения проблем с race condition в версии 4.9.1 появится механизм блокировок.
Из коробки блокировки будут внедрены в:
- Рендер блоков, при условии, что блок кешируется
- Компиляция стилей
- Объединение js скриптов
Для новых установок блокировки будут включены по умолчанию, для обновляющихся блокировки будут выключены.
Для включения блокировок необходимо внести изменения в конфигурационный файл (config.local.php):
$config['lock_backend'] = 'database';
4 лайка
Скажите, что вписывать database или redis?
если тут так
$config[‘session_backend’] = ‘redis’;
просто не очень понимаю связано оно или нет.
вписали database, как указано и полно ошибок такого вида в журнале и похоже они возникают как раз когда чистится кеш.
Ошибки
Stack trace:
#0 [internal function]: Tygh\Backend\Session\Redis->query(‘hmSet’, ‘session:SG:09b5…’, Array)
#1 /var/www/g01/data/www/САЙТ/app/Tygh/Backend/Session/Redis.php(244): call_user_func_array(Array, Array)
#2 [internal function]: Tygh\Backend\Session\Redis->query(‘hmSet’, ‘session:SG:09b5…’, Array)
#3 /var/www/g01/data/www/САЙТ/app/Tygh/Backend/Session/Redis.php(244): call_user_func_array(Array, Array)
#4 [internal function]: Tygh\Backend\Session\Redis->query(‘hmSet’, ‘session:SG:09b5…’, Array)
#5 /var/www/g01/data/www/САЙТ/app/Tygh/Backend/Session/Redis.php(244): call_user_func_array(Array, Array)
#6 [internal function]: Tygh\Backend\Session\Redis->query(‘hmSet’, ‘session:SG:09b5…’, Array)
#7 /var/www/g01/data/www/САЙТ/app/Tygh/Backend/Session/Redis.php(244): call_user" while reading upstream, client: 46.148.182.234, server: САЙТ, request: “GET /favicon.ico HTTP/2.0”, upstream: “fastcgi://unix:/var/www/php-fpm/g01.sock:”, host: “САЙТ”, referrer: “https://САЙТ/santehnika/mebel-dlya-vannyh-komnat-i-zerkala/?gclid=CjwKCAiA1ZDiBRAXEiwAIWyNC0rnlD8SpEDnqT3Cz74-TAEOYkm1Km-NlURqHO_qDO0EAisH”
2019/01/21 00:43:18 [error] 737#737: *214844 FastCGI sent in stderr: "PHP message: PHP Fatal error: Uncaught Tygh\Exceptions\DatabaseException: Sessions: can not connect to the Redis server in /var/www/g01/data/www/САЙТ/app/Tygh/Backend/Session/Redis.php:247
Нужно просто добавить в конфиг новую строку $config[‘lock_backend’] = ‘database’;
Значение у $config[‘session_backend’] оставляйте как есть.
как есть это с Redis?
Ну да, это же разный настройки. Одна для сессий, другая для блокировок.
вот к сожалению когда так включено, то засыпает ошибками и иногда страницы вообще грузят просто ошибку Редиса с табличкой Service unavaible, дошло до того, что они уже и в индекс Гугла попали…
сейчас отключил и ошибок пока нет
$config[‘lock_backend’] = ‘dummy’;
Походу какая-то несовместимость.
Пока не могу проверить у себя, будет ли работать редис и блокировка.
Но вопрос важный, лучше в баг-трекере тему создать.
1 лайк
Проще чистить кеш в моменты минимальной нагрузки, а потом любым спайдером (да тем же content-downloader) пробежаться по сайту и перегенерить кэш…
Что бы использовать редис - нужно его установить, настроить. Для этого нужна либо впска либо выделенные сервер с достаточным количеством оперативки.
Спасибо конечно. Это как бы само собой разумеется.
1 лайк
в общем оказался неверно настроен Redis и в своем логе он советовал что надо сделать
в моем случае вот это
в /etc/rc.local добавил
sysctl -w net.core.somaxconn=65535
echo never > /sys/kernel/mm/transparent_hugepage/enabled
по этой инструкции https://www.techandme.se/performance-tips-for-redis-cache-server/
и помогло
1 лайк