Постоянный объектный кэш сохранит результаты запросов на одной странице и если такие же запросы есть на другой странице, то результат запроса будет взят уже из кэша. К примеру сквозной блок "Последние новости".
Поставьте плагин Query Monitor и посмотрите как это работает.
Так у меня и так все страницы берутся из кеша, причем заранее все закешированные и подготовленные.
webinfo#: Вот я об этом и спрашивал уже несколько раз. Зачем выделять капсом то, на что ты не можешь дать ответа? Чтобы подчеркнуть, что ты этого не знаешь? Так это уже давно ясно.
Да, я уже много раз говорил что весь кеш и все страницы заранее подготовленный. ( я уже просто не знаю как это объяснить что все страницы заранее закешированны )
webinfo#: Вопрос как раз не в этом, а в том, каким образом создаётся эта "готовая страница".
Так и сказали бы, что для этого момента когда готовая htmlстраница отдается, этот объектный кеш и не нужен и никак это на производительности и увелчении скорости уже не скажется т.к. отдается уже готовая htmlстраница.
А в какой момент их плагин туда кладёт? Кто кэш прогревает?
Там несколько вариантов, когда пользователь впервые заходит на некешированную страницу ( НО, ЕСТЬ ПРЕДВАРИТЕЛЬНОЕ СОЗДАНИЕ КЕША, И, КАК БЫ ВСЕ СТРАНИЦЫ ЗАРАНЕЕ УЖЕ СОЗДАНЫ И ОБНОВЛЯЮТСЯ В 24 ЧАСА ), когда я создаю и публикую контент, в этот момент и кешируется страница попадая в кеш, и прелоад, в течении +/- 24 часов все страницы в кеше или переобновлены в кеше.
Короче, пользователь практически не видит и не получает не закешированные страницы, он практически всегда получает готовый кэш, так как кеш подготавливается заранее всех страниц за 24 часа по кругу и сначала автообновляется.
Давайте говорить о моменте где пользователь получает готовый кеш, готовую htmlстраницу, как при этом нужно ли это используется объектный кеш который снижает нагрузку на MySQLзапросы и т.п.
Это как они не заметят? А по страницам сайта кто ходит?
Так они уже готовую страницу получают, причем заранее подготовленную, в виде html, ну ходят и ходят, отдаются им уже заранее подготовленные html страницы, которые берутся из специальной папочки, в которую их плагин кеширования положил, у посетителя загружается сверх быстро вариант уже закешированной страницы в виде htmlдокументя, никакой работы с базой данных там не идет, да и с phpвидать тоже.
Этим занимается плагин кэширования, это посетители сайта не замечают и не заметят никогда, это уже дело сервера, на скорости для посетителей в браузере это не влияет.
Ты за столько лет ленишься пройти базовые учебные курсы и научиться искать простые ответы?
Да так же как и вы, вон там статью с верху посоветовали вот так же, а так особо и непонятно нужно ли это при действующем страничном кеше, никто не знает.
Ничего я не ленюсь, бывает мелкие вопросы непонятны.
У тебя сколько страниц на сайте? Как часто они меняются? Как часто будешь "прогревать" кэш?
Примерно около 4К, примерно думаю за +/- 24/сутки обновятся на автомате, про прогрев кэша что-то не понял, они складываются в папочку в виде готовых html’лок и потом отдаются посетителям.
Вы не поверите это я видел, но я все равно не понимаю если посетитель получает уже заранее подготовленную HTMLстраницу в чистом виде, в виде htmlкода, там не работы WordPress’а, не интерпретатораPHP, там вообще ничего нету, чистый htmlотдает сервер.
Выдержка, из статьи которую вы указали:
Тем не менее, постоянное кэширование объектов (или внешнее кэшированое) в WordPress легко реализуется с помощью сторонних плагинов, например Memcached Object Cache или APC Object Cache. Оба плагина позволяют использовать оперативную память сервера для хранения объектов WordPress, при этом объекты не пропадают при окончании запроса. Такой подход существенно снижает нагрузку на базу данных MySQL.
И опять я не понимаю, зачем это нужно и какое снижение нагрузки на базу данных MySQLесли посетитель получает уже заранее подготовленный HTMLкод в виде готовой страницы?
Постоянный объектный кэш сохранит результаты запросов на одной странице и если такие же запросы есть на другой странице, то результат запроса будет взят уже из кэша. К примеру сквозной блок "Последние новости".
Поставьте плагин Query Monitor и посмотрите как это работает.
Вот я об этом и спрашивал уже несколько раз. Зачем выделять капсом то, на что ты не можешь дать ответа? Чтобы подчеркнуть, что ты этого не знаешь? Так это уже давно ясно.
Вопрос как раз не в этом, а в том, каким образом создаётся эта "готовая страница".
А в какой момент их плагин туда кладёт? Кто кэш прогревает?
Там несколько вариантов, когда пользователь впервые заходит на некешированную страницу ( НО, ЕСТЬ ПРЕДВАРИТЕЛЬНОЕ СОЗДАНИЕ КЕША, И, КАК БЫ ВСЕ СТРАНИЦЫ ЗАРАНЕЕ УЖЕ СОЗДАНЫ И ОБНОВЛЯЮТСЯ В 24 ЧАСА ), когда я создаю и публикую контент, в этот момент и кешируется страница попадая в кеш, и прелоад, в течении +/- 24 часов все страницы в кеше или переобновлены в кеше.
Короче, пользователь практически не видит и не получает не закешированные страницы, он практически всегда получает готовый кэш, так как кеш подготавливается заранее всех страниц за 24 часа по кругу и сначала автообновляется.
Давайте говорить о моменте где пользователь получает готовый кеш, готовую html страницу, как при этом нужно ли это используется объектный кеш который снижает нагрузку на MySQL запросы и т.п.Это как они не заметят? А по страницам сайта кто ходит?
А каким образом они оказываются в папочке?
Что говорит поиск и чаты? Ты как искал?
Ты за столько лет ленишься пройти базовые учебные курсы и научиться искать простые ответы?
Да так же как и вы, вон там статью с верху посоветовали вот так же, а так особо и непонятно нужно ли это при действующем страничном кеше, никто не знает.
Ничего я не ленюсь, бывает мелкие вопросы непонятны.У тебя сколько страниц на сайте? Как часто они меняются? Как часто будешь "прогревать" кэш?
Когда ты уже начнёшь пользоваться ПСами и головой?
https://wpmag.ru/2013/keshirovaniye-wordpress/
Вы не поверите это я видел, но я все равно не понимаю если посетитель получает уже заранее подготовленную HTML страницу в чистом виде, в виде html кода, там не работы WordPress’а, не интерпретатора PHP, там вообще ничего нету, чистый html отдает сервер.
Выдержка, из статьи которую вы указали:
И опять я не понимаю, зачем это нужно и какое снижение нагрузки на базу данных MySQL если посетитель получает уже заранее подготовленный HTML код в виде готовой страницы?