Кэш рекламы, что это такое
Обновлено: 05.07.2024
Модуль Advanced Cache представляет собой набор передовых стратегий кэширования, которые помогают минимизировать нагрузку на сервер, обеспечивая при этом доступ к свежему контенту для пользователей.
Установка с помощью Maven
Maven — это самый простой способ установить модуль. Добавьте в свой пакет следующее:
Удаление
Возвратите политику кэширования в /modules/cache/config/contentCaching/defaultPageCache/cachePolicy@class к значению по умолчанию info.magnolia.module.cache.cachepolicy.Default .
Удалите узел /modules/advanced-cache и его подузлы.
Завершите работу Magnolia, удалите JAR-файл модуля Advanced Cache ( magnolia-advanced-cache.jar ) из WEB-INF/lib и снова запустите Magnolia.
Стратегии кэширования
Показ старого контента при повторном кэшировании
При использовании этой стратегии кэш не очищается полностью при обновлении контента, а записи сохраняются. После обновления, когда приходит первый запрос, запускается создание новой записи в кэше, и все последующие запросы на ту же запись обслуживаются из старого содержимого кэша, пока не будет готова новая запись.
Задайте для /modules/cache/config/contentCaching/defaultPageCache/cachePolicy@class значение info.magnolia.module.advancedcache.ServeUntilRecachedCachePolicy .
Задайте для /modules/cache/config/contentCaching/defaultPageCache/flushPolicy/policies/flushAll@class значение info.magnolia.module.advancedcache.NotifyFlushListeningPolicy .
Нетерпеливое повторное кэширование
При использовании этой стратегии кеш хранит список наиболее часто обслуживаемых записей. Система пытается обновить эти записи, как только обнаруживает обновление содержимого. Все остальные записи повторно кэшируются по запросу. Можно настроить количество записей для немедленного повторного кэширования и установить время жизни наиболее обслуживаемого контента.
Чтобы включить активное повторное кэширование:
Задайте для /modules/cache/config/contentCaching/defaultPageCache/cachePolicy@class значение info.magnolia.module.advancedcache.EagerRecacheCachePolicy .
Задайте для /modules/cache/config/contentCaching/defaultPageCache/flushPolicy/flushAll@class значение info.magnolia.module.advancedcache.EagerRecacheFlushPolicy .
Задайте для /modules/cache/config/contentCaching/defaultPageCache/executors/store/cacheContent@class значение info.magnolia.module.cache.executor.Store .
Изменение политики очистки по умолчанию
По умолчанию статистика об обслуживаемых страницах сохраняется на неопределенный срок. Если вы хотите, чтобы система очищала кеш после каждого обновления контента:
Создайте узел свойства resetAfterUpdate в flushPolicy .
Установите значение true .
По умолчанию первые 100 записей автоматически кэшируются при каждом обновлении. Чтобы изменить этот номер:
Создайте узел свойства awaitRecache в flushPolicy .
Установите значение, равное количеству первых записей в списке, которые вы хотите повторно кэшировать.
Изменение времени ожидания по умолчанию
По умолчанию Magnolia ждет 10 секунд перед попыткой повторного кэширования контента. Это время ожидания контролируется свойством blockingTimeout, настроенным в серверной части Ehcache 3. Свойство blockingTimeout применяется ко всей фабрике кэшей.
Если вы хотите изменить время ожидания для определенной политики кэширования, добавьте свойство timeout с количеством миллисекунд ожидания (значение по умолчанию — 10 000).
Изменения в политиках кэширования и исполнителях вступают в силу немедленно. Установка неверных значений может сделать экземпляр Magnolia недоступным. В этом случае попробуйте приложение Groovy Rescue.
Временная метка последней очистки
Расширенные политики сброса обновляют свойство lastUpdateTimestamp для записи последнего события сброса. Временная метка позволяет соответствующей политике кэширования определить, какие записи кэша необходимо создать повторно. Когда вы делегируете кэш расширенной политике кэширования, создайте свойство по пути, который включает имя вашей пользовательской политики.
Пример 1. Обслуживание старого контента при повторном кэшировании
/modules/advanced-cache/config/notifyFlushListeningPolicy/ @lastUpdateTimeStamp (настраиваемый)
Пример 2. Активное повторное кэширование
/modules/advanced-cache/config/eagerRecacheFlushPolicy/ @lastUpdateTimeStamp (настраиваемый)
где находится имя вашей пользовательской политики.
Безголовая персонализация и кэширование
Чтобы безголовая персонализация правильно работала с кэшированием контента в Magnolia, необходимо установить для параметра /modules/cache/config/contentCaching/ /cachePolicy@includePersonalizedDescendants значение true .
При настройке этого свойства функция динамического кэширования страниц отключается.
Информацию о предстоящих улучшениях см. в MGNLCACHE-245.
Конфигурация мультисайтового кэша
Когда контент публикуется, кэш общедоступного экземпляра сбрасывается для отображения нового контента. Это увеличивает нагрузку на сервер и влияет на все сайты в многосайтовой среде. Вы можете настроить несколько конфигураций кэша, чтобы сбрасывать только те записи кэша, которые принадлежат тому же подразделу (сайту), что и опубликованный контент.Используйте модуль приложения Advanced Cache для простой настройки или просто сделайте это вручную:
Установите /modules/advanced-cache/config@createSeparateCachesForEachSite=true. Это создает кэши для каждого определенного сайта. Он использует конфигурацию по умолчаниюPageCache для каждого сайта, если /modules/cache/config/contentCaching/SITE-NAME не существует.
Установите `/server/filters/cache@class=info.magnolia.module.advancedcache.filter.SiteAwareCacheFilter.` Этот фильтр выбирает правильный кеш для конкретного сайта, поэтому вам не нужно иметь отдельные фильтры кеша для каждого кэш.
Для всех рабочих пространств с поддержкой сайтов (тех, которые имеют отдельные поддеревья для каждого сайта):
Исключите рабочую область из политики очистки по умолчанию: /modules/cache/config/contentCaching/defaultPageCache/flushPolicy/policies/flushAll/excludedWorkspaces@WORKSPACE_NAME=WORKSPACE_NAME .
Зарегистрируйте эту рабочую область в политике сброса с учетом сайта: /modules/cache/config/contentCaching/defaultPageCache/flushPolicy/policies/flushSiteAware/workspaces@WORKSPACE_NAME=WORKSPACE_NAME .
Расширенные методы кэширования страниц включают кэширование страниц и BLOB-объектов, определение места их кэширования и способа их извлечения из кэша как на сайтах WebCenter, так и в системах Satellite Server.
41.1 О расширенном кэшировании страниц
Кэширование повышает скорость, с которой сайты WebCenter обслуживают страницы. Контент, отображаемый в кэше, не нужно повторно отображать при каждом запросе. Это сокращает время отклика.
Система кэширования имеет несколько уровней. Это позволяет регенерировать кэшированные объекты на одном уровне кэша, в то время как клиент получает кэшированное содержимое из другого уровня кэша. WebCenter Sites — это внутренний уровень кэша, а Satellite Server — внешний уровень кэша.
41.2 Настройка кэша сайтов WebCenter
Как сайты WebCenter, так и Satellite Server кэшируют страницы, пейджлеты и большие двоичные объекты. WebCenter Sites предоставляет три различных кэша механизма визуализации: кэш страницы CS, кэш BlobServer и кэш SS.
Все кэши можно настроить и очистить следующим образом:
Информацию об установке сроков действия для кэша сайтов WebCenter и кэша BlobServer см. в разделе Установка срока действия для отдельной записи.
Информацию об удалении объектов из кэша WebCenter Sites, BlobServer и Satellite Server см. в разделе Явное удаление записей из кэша.
Для кэша страниц сайтов WebCenter существует два уровня кэширования:
В базе данных.
В памяти. Кэш памяти — это прозрачное подмножество кэша базы данных; однако его можно настроить независимо.
См. эти темы:
41.2.1 Настройка максимального размера кэша
Кэш базы данных WebCenter Sites не имеет параметра настройки максимального размера. Подмножество памяти кэша страниц позволяет указать максимальное количество присутствующих записей.
Установите положительное целое число в свойстве cc.SystemPageCacheCSz в файле wcs_properties.json, чтобы указать максимальное количество записей, которые могут существовать в кэше.
Установка значения 0 приводит к тому, что все записи добавляются, а затем быстро удаляются. Однако этого следует избегать.
Свойство cc.SystemPageCacheCSz не должно иметь значение -1 .
Кэш использует алгоритм наименее использовавшихся ранее (LRU) для определения того, какую запись следует обрезать при достижении максимального размера.
Максимальный размер не отражает совокупное количество байтов, хранящихся в кэше.
41.2.2 Установка срока действия для отдельной записи
Срок жизни записи в кэше страниц определяется настройкой cscacheinfo. Объект CacheInfo получает значения, которые не заданы явно в поле cscacheinfo, из файла конфигурации. Синтаксис CacheInfo см. в разделе Синтаксис строк CacheInfo.
41.2.3 Явное удаление записей из кэша
WebCenter Sites предоставляет два способа удаления записей из кэша: вручную и автоматически с помощью CacheManager.
41.2.3.1 Удаление вручную
Вы можете удалить запись из кэша страниц вручную с помощью сервлета CacheServer. CacheServer предоставляет два варианта:
Очистить весь кеш.
Принудительно очистить все страницы в момент истечения срока их действия. Чтобы вызвать сброс всех функций CacheServer, вы должны войти в систему как пользователь с правами уничтожения в таблице SiteCatalog и указать параметр all=true при вызове сервлета CacheServer. Если вы не укажете параметр, то все записи с истекшим сроком действия (те, срок действия которых в прошлом) удаляются из кеша немедленно. Записи, срок действия которых еще не истек, не удаляются.
Запись с истекшим сроком действия ни в коем случае не будет обслуживаться из кеша, даже если она все еще находится в таблице базы данных. WebCenter Sites проверяет дату истечения срока действия любой страницы, которую он извлекает из кэша, прежде чем обслуживать страницу. Если WebCenter Sites попытается обслужить страницу с истекшим сроком действия, она будет немедленно удалена из кэша и будет создана новая страница.
41.2.3.2 Автоматическое удаление
CacheManager — это модуль, тесно связанный со страницей WebCenter Sites и механизмами кэширования больших двоичных объектов. Он позволяет управлять содержимым всех кэшей рендеринга на основе элементов, загруженных на страницу, срока действия страниц или параметров, переданных на страницы.
CacheManager сам по себе может быть предметом отдельного документа. Обзор его функциональности представлен здесь. Полную информацию о методах и обязательных аргументах см. в Javadoc COM.FutureTense.Cache.CacheManager.
- CacheManager создается с помощью одного из двух конструкторов. Один конструктор устанавливает CacheManager со всеми зарегистрированными в данный момент серверами Satellite. Другой конструктор позволяет указать, какими серверами Satellite должен управлять этот экземпляр CacheManager.
- Затем необходимо заполнить CacheManager страницами и большими двоичными объектами. Это делается с помощью одного из следующих методов:
Содержимое кэшей Page, Blob и Satellite тесно связано друг с другом. Всегда, кроме как в результате ошибки конфигурации, любой объект, кэшированный на Satellite Server, присутствует в кэше WebCenter Sites. Это означает, что WebCenter Sites имеет запись обо всех записях во всех кэшах механизма рендеринга. CacheManager использует эту запись для управления содержимым каждого из кешей без необходимости напрямую опрашивать каждый кеш для получения информации.
Этот метод позволяет заполнить CacheManager на основе даты последнего добавления записи в кэш. Вы можете выбрать, хотите ли вы заполнить его всеми записями, измененными до или после указанной даты.
Этот метод позволяет заполнить CacheManager на основе даты последнего изменения элемента в записи. Как и в случае с setByCachedDate(ICS, boolean, String) , вы можете выбрать, нужны ли вам все записи, элементы которых были изменены до или после указанной даты.
Этот метод позволяет заполнить CacheManager на основе пар "имя-значение", присутствующих в ключе кэша (включая имя страницы).
Этот метод позволяет заполнить CacheManager на основе точных идентификаторов элементов, хранящихся на страницах или больших двоичных объектах в кэше.
После заполнения CacheManager может управлять содержимым кэшей. Это делается с помощью одного из четырех основных методов обслуживания:
flushCSEngine(ICS ics, режим int)
Этот метод очищает все страницы и большие двоичные объекты, находящиеся в настоящее время в CacheManager, из кэшей страниц WebCenter Sites и больших двоичных объектов.
и встроенные в него теги. Satellite Server интерпретирует эти теги и преобразует их в ключ кеша, а затем сбрасывает из кеша соответствующие страницы.
refreshCSEngine(ICS ICS, режим int)
Этот метод отправляет запрос (с помощью ICS.ReadPage или ICS.BlobServer ), который регенерирует объект и автоматически повторно заполняет кэш.
Вы можете использовать эти методы, чтобы воспользоваться преимуществами кэширования с двойной буферизацией, инструмента, который может обеспечить чрезвычайно высокую производительность динамических сайтов. См. Общие сведения о дизайне страниц и кэшировании.
41.3 Настройка кэша сервера BLOB-объектов
Кэш BlobServer – это кэш по принципу "все или ничего". Его записи либо глобально кэшируются, либо глобально не кэшируются. Кэширование BlobServer отключено, если включена защита или если bs.security=true .
См. эти темы:
41.3.1 Рекомендации по настройке максимального размера кэша
Свойство bs.bCacheSize в файле wcs_properties.json сайтов WebCenter указывает количество записей, содержащихся в кэше больших двоичных объектов. Если для размера задано отрицательное число, размер кэша больших двоичных объектов может расти неограниченно.
41.3.2 Установка срока действия для отдельной записи
Сервер BLOB-объектов не поддерживает истечение срока действия кэшированных записей. Все кэшированные объекты находятся в кэше в течение времени ожидания, определяемого свойством bs.bCacheTimeout в файле wcs_properties.json сайтов WebCenter. Отрицательный тайм-аут указывает, что записи не должны истечь по тайм-ауту. Положительное целое число указывает количество минут, в течение которых объект находится в кэше.
41.3.3 Явное удаление записей из кэша
Вы можете использовать BlobServer для удаления из кэша отдельных записей или всех записей.
41.3.3.1 Удаление вручную
Чтобы удалить запись из кеша вручную, переименуйте параметр blobtable в flushblobtable . Это удаляет из кэша запись, соответствующую остальным параметрам.
Для удаления всех записей из кеша вручную есть два варианта.
Вызовите сервлет BlobServer с параметром flushblobtables (обратите внимание на "s").
Вызовите сервлет CacheServer, как описано выше. Обратите внимание, что при этом из кеша удаляются все страницы и все большие двоичные объекты.
41.3.3.2 Автоматическое удаление
Поскольку элементы зависимостей больших двоичных объектов записываются при создании ссылок на большие двоичные объекты, вы можете вызывать CacheManager для управления большими двоичными объектами и страницами. CacheManager всегда управляет большими двоичными объектами и страницами вместе. См. CacheManager, О CacheManager и Включение CacheManager.
Разработчикам следует проверять статус объекта перед показом BLOB-объектов. Это позволяет избежать таких проблем, как BlobServer, обслуживающий большой двоичный объект после того, как актив был аннулирован (это происходит только с базовыми активами).
41.4 Настройка кэша Satellite Server
Вы настраиваете общий кэш Satellite Server в файле wcs_properties.json.
Однако конфигурация кэша часто переопределяется для каждого отдельного объекта.
41.4.1 Настройка максимального размера кэша
Обновите свойство cache_max в файле wcs_properties.json, указав максимальное количество записей, которое может храниться в кэше одновременно.
Если для свойства задано отрицательное целое число, кэш не ограничивается по размеру. Любое положительное целое число указывает максимальное количество записей, которые могут храниться в кэше.
41.4.2 Явное удаление записей из кэша
Вы можете удалить отдельные записи из кэша Satellite Server вручную или с помощью CacheManager, как описано в этом разделе.
Ручное удаление: Satellite Server включает сервлет FlushServer. Отправив запрос GET этому сервлету, указав имя пользователя, пароль и параметры сброса, можно сбросить все содержимое кэша Satellite Server. Невозможно сбросить отдельные записи с помощью GET .
Автоматическое удаление: можно очистить кеш Satellite Server с помощью CacheManager. CacheManager может сбрасывать записи на Satellite только в том случае, если соответствующий объект кэшируется на сайтах WebCenter. Это связано с тем, что WebCenter Sites отслеживает содержимое кэша Satellite Server.
При очистке кэша Satellite Server с помощью CacheManager соответствующий объект кэшируется на сайтах WebCenter. Соответствующий объект требуется из-за того, что WebCenter Sites отслеживает содержимое кэша Satellite Server.
Подходящими методами CacheManager для работы с кэшем Satellite Server являются flushSSEngines() и refreshSSEngines() . См. раздел Явное удаление записей из кэша.
41.5 Синтаксис строки CacheInfo
Поля cscacheinfo и sscacheinfo в SiteCatalog заполняются строкой CacheInfo. Узнайте, как формат строки, состоящей из двух частей и разделенной запятыми, определяет, следует ли кэшировать страницу и когда истечет срок ее действия.
Примеры значений следующие:
Строка CacheInfo: первая часть
Первая часть в CacheInfo должна иметь одно из следующих значений:
Если значение равно false , страница не кэшируется.
Если значение равно true , страница кэшируется в соответствии с информацией, представленной во втором элементе.
Если значение пустое, проверяется свойство wcs_properties.json cs.alwaysusedisk. Если для этого свойства задано значение yes, то пустое значение интерпретируется как имеющее то же поведение, что и true. Если задано значение no (значение по умолчанию), то пустое значение интерпретируется как имеющее то же поведение, что и false .
Если значение равно *, оно считается пустым.
Строка CacheInfo: вторая часть
Это описывает, когда страница, которая должна быть кэширована, должна быть удалена из кеша. Если первый элемент имеет значение false (или интерпретируется как false ), то второй элемент игнорируется.
Существует три способа указать срок действия страницы:
Допустимые значения включают:
Если второй элемент начинается с символа тильды (~), то следующее значение должно быть целым числом. Значение этого целого числа — это количество минут, в течение которых страница будет оставаться в кеше после ее первого создания. Отрицательное значение или 0 указывает, что срок действия страницы никогда не истечет (она навсегда останется в кеше).
Абсолютный момент времени
Если второй элемент начинается с символа at ( @ ), то следующее значение должно быть датой, выраженной в формате строки даты JDBC, то есть ГГГГ-ММ-ДД ЧЧ:ММ:СС . По истечении этой даты кэшированные страницы удаляются из кеша, и страница больше не кэшируется.
В целом синтаксис TimePattern соответствует формату, используемому в большинстве таблиц cron UNIX. Он позволяет указывать срок действия в определенное время или время каждый день, месяц, неделю, день недели и год.
Ожидается, что формат TimePattern станет наиболее широко используемым форматом для определения срока действия страницы.
Если вторым элементом является *, то страница будет использовать режим истечения времени ожидания, как описано в разделе Время ожидания страницы. Значение времени ожидания считывается из свойства cs.pgCacheTimeout файла wcs_properties.json.
Если второй элемент пуст, то он ведет себя так же, как *.
41.6 Рекомендации по кэшированию
В идеале веб-страница WebCenter Sites должна иметь не более шести-десяти кэшированных первичных страниц, обслуживаемых удаленным спутниковым сервером. Слишком большое количество страниц в кэше приводит к избыточному кэшированию и отрицательно влияет на производительность системы.
В этих темах описываются методы, предотвращающие избыточное кэширование и улучшающие время отклика и пропускную способность:
41.6.1 Несколько страниц на странице
Создавайте шаблоны страниц таким образом, чтобы на каждой странице было меньше некешированных страниц. Style=pagelet по умолчанию из тега не всегда лучший выбор. Меньшее количество страниц на странице улучшает время отклика и пропускную способность.
Переключитесь с удаленного Satellite Server на Co-Resident Satellite Server, если у вас уже есть шаблоны страниц и изменить их дизайн невозможно. Между сервлетом WebCenter Sites и сервером Co-Resident Satellite не требуется никакого обмена данными. Co-Resident SatelliteServer, скорее всего, даст лучшее время отклика, чем Remote Satellite Server, если на странице больше некешированных страниц.
Сократите количество кешированных страниц, объединив их. Сначала проверьте, использует ли каждый вызов значение атрибута стиля страницы по умолчанию. Сократите количество страниц, встроив вызовы как вызовы элементов ( style=element ).
Типичный вариант использования для указания style="element" – это когда внешний вызывающий шаблон (будь то страница или страница) использует те же c , cid, что и внутренний вызываемый шаблон страницы. Поскольку срок действия обоих кэшированных объектов истекает одновременно (т. е. они имеют одинаковые зависимости активов), нет смысла кэшировать их по отдельности.
Вместо того, чтобы кэшировать подстраницы непосредственно на удаленном спутниковом сервере, создайте резервную копию подстраниц с помощью кэша подстраниц на сервлете ContentServer, используя вариант style="embedded". То есть встроить вызовы как фрагменты страницы ContentServer ( style=embedded ).
Например, если список обзоров продуктов на веб-странице содержит десять элементов, это означает, что к каждому из них применяется по умолчанию style="pagelet". Из-за стиля страницы для отображения этого списка потребуется десять циклов обмена данными между сервлетом WebCenter Sites и удаленным спутниковым сервером. Однако, если существующие вызовы для подстраниц настроены на использование style="embedded" — при этом обеспечивается кэширование самого шаблона внешнего списка — тогда требуется только один круговой обход для всей страницы со списком продуктов. Это связано с тем, что только внешний шаблон обслуживается удаленным спутниковым сервером, а остальные подстраницы обслуживаются только сервлетом ContentServer.
41.6.2 Совместное использование кеша между страницами
Когда cid передается каждому кэшированному pagelet, кэш не распределяется между веб-страницами. Например, сайт может содержать 5000 веб-страниц, каждая из которых передает cid в leftnav. Также будет кэшироваться 5000 левых навигаторов независимо от вызывающей веб-страницы. Этот сценарий может привести к двум ситуациям:
Когда редактируется и публикуется один ресурс Страницы в дереве навигации сайта, все 5000 левых навигаторов не кэшируются. Это связано с тем, что только что опубликованный ресурс Страницы зарегистрировал зависимость от всех страниц leftnav.
Когда редактируется и публикуется один объект статьи, кэшированная внешняя веб-страница (обычно это шаблон макета) и левая навигация не кэшируются и требуют повторной оценки. Поскольку cid передается в leftnav, Content Server также не кэширует внешнюю веб-страницу и leftnav. Такой подход неэффективен, поскольку статья не имеет ничего общего с иерархией навигации по сайту.
Чтобы избежать чрезмерного кэширования в таких ситуациях, измените левую навигацию так, чтобы она всегда принимала cid страницы, а не любой cid. Вызывающий шаблон должен иметь возможность определить, к какой странице он принадлежит, чтобы передать это в качестве аргумента кеша. Только cid страницы должен регистрировать зависимость кеша от пейджлета и никакие другие ресурсы страницы. Псевдокод выглядит следующим образом:
Таким образом, кешированная версия этой страницы привязывается только к связанному объекту Страницы владельца. Когда один объект страницы редактируется в дереве навигации сайта и публикуется, только один файл leftnav, чей cid= , будет раскэширован. Когда редактируется и публикуется один объект статьи, необходимо переоценить только кэшированную внешнюю веб-страницу (обычно это шаблон макета).
Когда редакторы ежедневно обновляют и изменяют систему, выбор разработчиков оказывает огромное влияние на эффективность системы. Без предлагаемого улучшения даже редактирование одного ресурса может привести к тому, что система будет выполнять гораздо больше работы во время публикации, чем требуется. Аргументы, которые явно передаются каждому пейджлету, напрямую влияют на общую производительность.
Самое быстрое решение для кэширования для сайтов Drupal и WordPress
Загрузка страниц менее секунды с полным кэшированием страниц
Расширенное кэширование страниц для Drupal и WordPress
Кэш веб-сайта полезен только в том случае, если в нем есть необходимый контент для удовлетворения запросов посетителей. Детальный контроль кеша Pantheon позволяет разработчикам и владельцам сайтов управлять обновлениями определенных ресурсов, страниц, категорий и даже персонализацией в нашей глобальной CDN.
Ваши сайты будут поддерживать высокий уровень попаданий в кэш (т. е. высокую скорость загрузки страниц), а посетители всегда будут иметь доступ к новейшему контенту. Детальный контроль кеша Pantheon предотвращает непреднамеренное аннулирование кеша всего сайта. Нет необходимости выбрасывать весь кэш каждый раз, когда вы вносите небольшие изменения в содержание сайта.
Увеличение производительности за счет полного кэширования страниц
Расширенное кэширование всей страницы Pantheon значительно улучшает загрузку страниц за счет кэширования всей веб-страницы — от html до CSS и ресурсов. Средняя веб-страница состоит из 30-80 ресурсов, которые необходимо загрузить, прежде чем страница будет полностью отображена. Начальная загрузка страницы веб-сайта предоставляет инструкции для изображений, шрифтов, текста, CSS, javascript и других ресурсов, необходимых для создания и отображения полностью отображаемой веб-страницы. Ключевым активом для кэширования для максимально быстрой загрузки является фактическая «html-страница», которую не могут сделать большинство поставщиков хостинга и CDN.
Расширенное кэширование Drupal
В Drupal 8 реализованы невероятные улучшения в функциях кэширования. Благодаря модулю Pantheon Advanced Page Cache метаданные кэширования ядра Drupal передаются в точки присутствия по всему миру. Когда ваши данные изменяются в Drupal, ваш глобальный кеш выборочно очищается.
Технология суррогатного ключа, встроенная в модуль, дает вашим сайтам Drupal более точный механизм очистки кэша и, как правило, более высокую частоту попаданий в кэш. «Пометив» кэшированный ответ идентификаторами используемых данных, такими как автор и категория, при изменении вашего сайта модуль может выборочно удалить только то, что необходимо, на основе суррогатных ключей.
Расширенное кэширование WordPress
Подключаемый модуль Pantheon Advanced Page Cache для WordPress работает сразу после установки и не требует настройки. Изменения в сообщениях, страницах, категориях, изображениях и тегах автоматически обновляют кеш и распространяются на все наши более чем 70 глобальных точек присутствия (POP).
Наш подключаемый модуль использует технологию суррогатного ключа, чтобы предоставить сайтам WordPress значительно более точный механизм очистки кеша и, как правило, более высокую частоту попаданий в кеш. «Пометив» кэшированный ответ идентификаторами используемых данных, такими как автор и категория, при изменении данных WordPress плагин может выборочно удалить только то, что необходимо, на основе суррогатных ключей. Он даже работает с REST API WordPress!
Запуск веб-сайта на WordPress — это хорошо, пока вы не столкнетесь с ошибкой. Будут времена, когда вы столкнетесь с различными ошибками на своем веб-сайте, некоторые из которых будут большими, а другие — небольшими.
Все, что вам нужно сделать, это набраться терпения и провести небольшое исследование. Скорее всего, кто-то еще столкнулся с той же проблемой, что и вы, и нашел решение, которым поделился с другими разработчиками веб-сайтов.
ОШИБКИ WORDPRESS
Иногда это может быть неприятно, когда вы сталкиваетесь с этими ошибками, потому что вы хотите потратить время на работу с содержанием вашего веб-сайта, но вместо этого вам приходится тратить все свое время на поиск решения проблемы.
В большинстве случаев нам просто нужно преодолеть это разочарование и набраться терпения, потому что вероятность того, что вы найдете решение в Интернете, очень высока. Вам просто нужно поверить, что вы не единственный, кто столкнулся с этой проблемой, и кто-то другой мог найти и поделиться решением.
ОШИБКА РАСШИРЕННОГО КЭША PHP
Иногда, когда мы заходим в наш WordPress, чтобы внести некоторые изменения на сайт или по какой-либо другой причине, мы видим эту ошибку на экране.
«Внимание!
Файл /home/username/public_html/wp-content/advanced-cache.php уже существует. Пожалуйста, удалите его вручную перед использованием этого плагина. Если вы продолжаете видеть это сообщение после его удаления, обратитесь в службу поддержки вашего хостинга».
Эта ошибка должна быть устранена, чтобы внести какие-либо изменения на ваш сайт или даже получить доступ к определенным разделам вашего WordPress.
Обратите внимание, что существуют другие типы ошибок, связанные с расширенным кешем php, но решение, упомянутое в этом посте, предназначено для ошибки, указанной выше.
Ошибка Advanced Cache Php в WordPress
Что касается решения, то оно написано в самом предупреждении. Подробно об этом позже с картинками. Как только вы удалите заранее кэшированный php-файл из корневой папки, эта ошибка исчезнет после обновления страницы.
Это было легко! не так ли?
Теперь вы начинаете работать над своим веб-сайтом и вносите некоторые изменения, и все готово. Вы проверяете свой веб-сайт, снова возвращаетесь на панель инструментов и снова видите ту же ошибку/предупреждение.
ЧТО ПРОИСХОДИТ??
Это означает, что решение, упомянутое в предупреждении, является временным, и каждый раз, когда вам нужно будет вносить какие-либо изменения на свой веб-сайт, вам придется удалять php-файл расширенного кеша.
СВЯЗАТЬСЯ С ПОДДЕРЖКОЙ ВЕБ-ХОСТИНГА
Поэтому, чтобы найти решение, следуйте второй части предупреждения и обратитесь в службу поддержки веб-хостинга. Вы рассказываете им о проблеме с расширенным кешем php и спрашиваете решение. Они скажут вам, что это проблема с плагином, и вы должны удалить этот плагин или внести изменения в этот плагин. Но вы спросите, что это за плагин, и вам скажут, что плагин связан с кешем, и вам придется изменить его настройки, так как он мешает настройкам WordPress.
Теперь вы вернулись к исходной точке. Когда вы исчерпали оба варианта, упомянутых в предупреждении, но проблема все еще остается, вам сначала нужно понять, почему возникает проблема с расширенным кэшем php, а затем применить решение.
ПРИЧИНА, ПОЧЕМУ ВЫ ПОЛУЧАЕТЕ ОШИБКУ РАСШИРЕННОГО КЭША PHP
Эта ошибка возникает, если вы установили два или более подключаемых модуля для ускорения работы вашего веб-сайта. Например, у меня были установлены и активированы эти два плагина одновременно.
Более одного плагина кэширования для оптимизации скорости веб-сайта
Оба этих плагина мешали друг другу, и поэтому я получал вышеупомянутую ошибку расширенного кэша php. По-видимому, оба плагина хотят получить доступ к этому файлу.
Файл advanced-cache.php используется подключаемыми модулями кэширования, чтобы сигнализировать об активности кэша. Если используется более одного подключаемого модуля кэширования, второй подключаемый модуль обнаружит файл как активный, и он не будет кэшировать веб-сайт и, следовательно, не будет работать должным образом, после чего вы получите эту ошибку.
РЕШЕНИЕ: КАК УДАЛИТЬ ЭТУ ОШИБКУ ADVANCED-CACHE.PHP
1- УДАЛИТЬ PHP-ФАЙЛ РАСШИРЕННОГО КЭША
Сначала вам нужно удалить файл, чтобы внести какие-либо изменения в свои плагины. Чтобы удалить php-файл расширенного кеша, вам нужно открыть файловый менеджер на Cpanel вашего хостинга.
Диспетчер файлов на Cpanel веб-хостинга
Затем вам нужно выбрать папку Public_html, расположенную в левой части экрана.
Нажмите Public_html в левой части диспетчера файлов, чтобы просмотреть элементы в этой папке
После выбора папки Public_html вам нужно выбрать Wp-Content.
В разделе public_html выберите wp-content
Открыв папку wp-content, вы увидите в правой части экрана все файлы и папки внутри wp-content. Там вы найдете файл advanced-cache.php.
Выберите файл advanced-cache.php
Выберите файл advanced-cache.php, щелкните его правой кнопкой мыши и нажмите "Удалить". На экране появится следующее всплывающее окно.
Нажмите «Подтвердить», чтобы удалить файл advanced-cache.php
Нажмите «Подтвердить», чтобы удалить файл.
Совет: не проверяйте пропуск корзины и удаляйте файлы навсегда, так как если что-то пойдет не так, вы всегда сможете восстановить файл.
Также читайте в Infinity Folder:
Как безопасно путешествовать во время и после COVID-19
Облегчите жизнь, упаковав эти 9 вещей для круиза с детьми
Почему вам следует выбрать курорт All Inclusive для вашего следующего отпуска
2- ВНЕСИТЕ ИЗМЕНЕНИЯ В ПЛАГИНЫ КЭШИРОВАНИЯ, ЧТОБЫ РЕШИТЬ ПРОБЛЕМУ РАЗ И НАВСЕГДА
После того, как вы удалили php-файл расширенного кеша, вы сможете вносить изменения в свои плагины и их настройки.
Решите, какой из двух подключаемых модулей для кэширования у вас есть, а для другого вы можете либо деактивировать подключаемый модуль, либо изменить его настройки, чтобы он не выполнял кэширование.
Сохраните настройки и повторите попытку после внесения некоторых изменений на свой веб-сайт. Надеюсь, ошибка больше не повторится, а ошибка расширенного кеша php исчезнет навсегда.
ЗАКЛЮЧЕНИЕ
Ошибки будут всегда, все, что вам нужно сделать, это набраться терпения и искать решение. Создание и поддержка веб-сайта — непростая задача. Вам придется столкнуться с множеством проблем.
Эту ошибку также можно исправить, если понять, как она возникла. Каждая ошибка такая, и если вы понимаете ее причину, вы на шаг ближе к ее устранению.
Основная проблема с расширенной ошибкой php заключалась в том, что два плагина пытались использовать один и тот же файл, в результате чего один из них не получил к нему доступа и, следовательно, не работал. Это привело к ошибке, которая не позволяла вам вносить какие-либо изменения на ваш веб-сайт. Как только вы избавитесь от другого плагина или измените его настройки, проблема больше не возникнет.
Сообщите нам в разделе комментариев, помогло ли вам решение, чтобы другие могли извлечь из него пользу.
Подпишитесь на нас в Twitter и Instagram, чтобы быть в курсе наших новых публикаций.
Не забудьте поделиться статьей в социальных сетях, если решение сработало для вас. Просто нажмите на значок ниже, чтобы поделиться статьей на соответствующей платформе.
Это сообщение было посвящено тому, как избавиться от ошибки Advanced Cache Php в WordPress.
Читайте также: