Меню

Что такое настройка кеша



Рекомендации по работе с кешированием

Если у вас возникли какие либо вопросы которые вы не смогли решить по нашим публикациям самостоятельно,
то ждем ваше обращение в нашей службе тех поддержки.

Кеширование при проектировании сайта

Максим Месилов: В 1С-Битрикс есть производительная система кеширования. Она используется как в стандартных компонентах системы, так может быть применена и при самостоятельной разработке. Основная её задача — снизить время отклика сайта и повысить его устойчивость при нагрузках.

Кеширование

Закладывая в ТЗ проекта интенсивное использование технологии кеширования, можно максимально ограничить нагрузку на базу данных. Это позволит нашему проекту выдержать в будущем значительные нагрузки.

Для реализации кеширования в системе созданы два класса:

  • CPageCache — для кеширования HTML
  • CPHPCache — для кеширования HTML и PHP переменных

Результаты кеширования сохраняются в виде файлов в каталоге /bitrix/cache/ . Если время кеширования не истекло, то вместо ресурсоемкого кода будет подключен предварительно созданный файл кеша.

Правильное использование кеширования позволяет увеличить общую производительность сайта на порядок. Однако необходимо учитывать, что неразумное использование кеширования может привести к серьезному увеличению размера каталога /bitrix/cache/ .

Пример кеширования HTML

«; endif; // записываем предварительно буферизированный вывод в файл кеша $obCache->EndDataCache(); endif; ?>

В данном примере, метод CPageCache::StartDataCache проверит наличие неистекшего и валидного файла кеша. Если такой файл существует, то он будет подключен и выведен на экран, в противном случае будет включена буферизация. Результаты буферизации будут записаны в файл кеша методом CPageCache::EndDataCache.

В первом параметре метода CPageCache::StartDataCache задается интервал времени в секундах, в течение которого файл кеша будет считаться валидным и не истекшим (интервал времени отсчитывается с момента создания файла кеша).

Во втором параметре указывается уникальный идентификатор данного экземпляра кеша. Здесь необходимо подчеркнуть, что если какие-либо переменные могут повлиять на результат выполнения кешируемого кода, то их значения необходимо включить в этот идентификатор.

  • Если на результат выполнения кешируемого кода может повлиять авторизация текущего пользователя, то к идентификатору необходимо добавить результат выполнения функции CUser::GetUserGroupString, возвращающей строку c ID групп текущего пользователя.
  • Если в кешируемом коде вы используете постраничную навигацию, то в данный идентификатор обязательно нужно включить результат работы функции CDBResult::NavStringForCache.
  • При использовании сортировки необходимо также помнить, что в идентификатор необходимо включить значения переменных хранящих в себе поле, по которому идет сортировка и порядок сортировки (например, $by.$sort).

Пример кеширования HTML и PHP переменных

«; endif; // записываем предварительно буферизированный вывод в файл кеша // вместе с дополнительной переменной $obCache->EndDataCache(array( «SECTION_TITLE» => $SECTION_TITLE )); endif; ?>

Отличие данного примера от предыдущего заключается в том, что помимо HTML также кешируется PHP переменная $SECTION_TITLE . Структура и тип кешируемых PHP переменных могут быть произвольными. Метод CPHPCache::InitCache выполняет проверку на наличие неистекшего и валидного файла кеша. Если данный файл найден, то происходит его подключение, при этом все закешированные переменные будут доступны после использования метода CPHPCache::GetVars. Метод CPHPCache::EndDataCache, помимо буферизированного HTML кода, записывает в файл кеша также PHP переменные.

Для отключения кеширования на одной странице, необходимо авторизоваться с административными правами и вызвать эту страницу с параметром &clear_cache=Y . Если, авторизовавшись с административными правами, вызвать любую страницу с параметром &clear_cache_session=Y , то кеш будет отключен для всех страниц, которые будут просмотрены в рамках сессии. Файлы кеша можно удалить в административной части на закладке Очистка файлов кеша страницы Настройки > Настройки продукта > Автокеширование .

Альтернативные способы хранения кеша

Мы убедились, что использовать технологию кеширования для веб-сайта нужно, значит необходимо предусмотреть кеширование ещё на стадии написания ТЗ.

Допустим, через определенное время, наш веб-сайт стал популярным ресурсом. Благодаря активному использованию технологии кеширования мы надежно защитили базу данных от высокой нагрузки, и она может выдержать 3-5 кратное превышение нагрузки.

Однако, у нас, из-за специфики веб-сайта, скопился большой объем самих закешированных данных, использование которых (десятки тысяч файлов) вызывает «некоторые» неудобства — возросла нагрузка на дисковую подсистему. А также, к сожалению, при разработке вкрались ошибки и наши закешированные данные чистятся не полностью, поэтому постепенно их объем на диске становится все больше и больше.

Читайте также:  Настройка принтера epson xp 332

При использовании memcached временные данные будут храниться в оперативной памяти. Можно выделить для хранения кеша недорогой сервер с несколькими гигабайтами памяти.

При этом, устаревшие данные будут автоматически вытесняться и наш кеш перестанет «расползаться» по системе, пожирая все больше и больше места. Допустим, мы выделили в memcached 4GB места для кеширования и можем быть уверенными, что больше 4GB кеш не вырастет, а наименее часто используемые данные будут вытесняться (алгоритм LRU). Очень удобно и эффективно.

Подключение memcached осуществляется в файле dbconn.php.

Для эффективной работы системы настройки по умолчанию нужно изменить. Примеры:

Если memcached используется на одной машине, там же, где и находится сам веб-сервер, то использование сокета будет быстрее.

Подключение APC осуществляется в файле dbconn.php:

Подробнее про установку и настройку APC смотрите в документации www.php.net/apc.

Параметр cacheenginenone

Очень часто встречающаяся проблема при работе с кешем — в закладке Хранение кеша страницы Настройки > Производительность > Панель производительности появляется параметр cacheenginenone, а кеширование при этом не производится. По сути данный параметр — это указание системы, что выбранный вами способ хранения кеша не работает. Можно сказать, что подходящего способа кеширования для системы нет, поэтому она и не будет выполнять его, как будто оно не включено вовсе.

Для того, чтобы решить эту проблему, нужно правильно настроить способ кеширования. Например, данный параметр может появиться, если вы указываете, что кеш должен храниться c помощью APC, но данное приложение настроено неправильно или отключено. Вам нужно проверить его настройки или включить его, если требуется.

Кеширование в собственных компонентах

Подробное описание кеширования в компонентах описано в уроке Кеширование в собственных компонентах в рамках главы Компоненты.

Рекомендации по работе с кешированием

  • Оптимизировать проект так, чтобы без использования кеширования сложность и количество запросов было минимально. Например, для облегчения запросов, возможно, потребуется создание специфических для проекта индексов. Также, в некоторых случаях, будет эффективнее разбить один сложный запрос на несколько более простых и легких. Это снизит общую нагрузку к базе и позволит более эффективно использовать кеширование.

Юналиев Рамиль: Если разработчик делает 1000 запросов и говорит «и так сойдет, оно же кешируется», то это конечно неправильно, любым инструментом нужно уметь пользоваться.

Сербул Александр: Иногда во время разработки активно используются технологии кеширования, однако при возрастании нагрузки база данных подвергается перегрузкам. Почему? Для предупреждения данного риска необходимо сначала обеспечить наиболее оптимальную работу с базой данных с выключенным кешированием, прежде чем его включать (рекомендую менеджерам интернет-проектов взять это на заметку и включить в чеклист контроля качества проекта). Типичный кейс данной «ловушки» такой — при включенном кешировании кастомизированное меню использует 0 SQL-запросов, при выключенном — 5000!

Лучше установить большее время кеширования, а актуальность данных в кеше поддерживать с помощью Тегированного кеширования. Тогда кеш будет обновляться только при изменении данных, а соответственно не будет лишней нагрузки на сервер, как в случае с малым временем, когда кеш создается по истечении указанного периода времени независимо от актуальности данных.

При формировании идентификатора кеша необходимо учитывать только нужные параметры, избегая излишней вариативности.
Неправильный ИД будет приводить к тому, что кеширование будет не эффективно из-за того, что большая часть хитов будет попадать мимо кеша.

Пример создания кеша для новостей, когда срок активности новости скоро истекает, и кеш достаточно будет создать на весь день всего один раз:

Источник

HTTP протокол: основные правила Интернета, которые должен знать каждый веб-разработчик. Как браузер взаимодействует с сервером.

Тема 13: Кэширование в HTTP: механизмы клиентского и серверного кэша в HTTP

Привет, читатель блога ZametkiNaPolyah.ru! Продолжим знакомиться с протоколом HTTP в рубрике Серверы и протоколы и ее разделе HTTP протокол. Эта запись будет о кэширование в HTTP протоколе. Мы с тобой поговорим о том для чего вообще нужно кэширование в HTTP, о правилах кэширования, о том, какие могут быть ошибки при кэшировании, а так же о том какие есть механизмы о клиента и сервера для управления процессом кэширования в HTTP и о различных моделях при кэширование.

Читайте также:  Настройка зажигания москвича 2140

Кэширование в HTTP

Для чего нужно кэширование в HTTP протоколе

HTTP протокол работает в сети интернет, пожалуй, это основной протокол седьмого уровня модели OSI, используемый для связи между узлами. Причем узлы могут находить на разных континентах и их может разделять огромная цепочка узлов и станций. Поэтому разработчики стандарта HTTP протокола были очень озабочены его эффективностью. Одним из механизмов увеличения эффективности HTTP протокола является кэширование. Кэширование в HTTP протоколе позволяет снизить нагрузку на конечный сервер и транзитные сервера не только на седьмом уровне модели OSI, но и на четвертом и ниже.

Сейчас мы не будем вдаваться в технические подробности реализации кэширования HTTP сервера, но общее представление о том, как происходит кэширование в HTTP получим. Хочу отметить, что кэширование в HTTP очень упрощает жизнь клиентам и серверам и значительно снижает нагрузку на сеть, зачастую пользователь даже не догадывается, что содержимое (обсуждение содержимого в HTTP), которое он видит в окне своего браузера – это результат работы механизма кэширования в HTTP.

Кэширование в HTTP реализовывалось для того, чтобы избавиться от необходимости отправлять лишние HTTP запросы от клиента, а так же для того, чтобы сервер не отправлял HTTP ответы целиком так, как будто механизма кэширования нет вовсе. Кэширование в протоколе HTTP управляется, как со стороны сервера, так и со стороны клиента, это необходимо для более точного и удобного восприятия содержимого конечным пользователем.

Так же хочу обратить ваше внимание на то, что механизмы кэширования HTTP сервера (например, веб-сервер Apache) и HTTP клиента (любой браузер) зависят непосредственно от разработчика, сейчас мы рассматриваем общие принципы кэширования протокола HTTP без привязки к какому-либо приложению.

Правильность кэширования в HTTP

Первое правило кэширования в HTTP заключается в том, что сервер должен посылать кэшированные HTTP ответы с самой последней версией содержимого. При этом суть заключается в том, что клиент может получать данные не с конечного HTTP сервера, а с ближайшего сервера, у которого в кэше есть информация о том, что содержится в URI (URI в HTTP), который был указан в HTTP запросе, поэтому должны выполняться следующие правила:

  1. Проверка достоверности. Сервер, который дает ответ на запрос должен всегда быть в курсе о содержимом конечного сервера, к которому идет обращение.
  2. Новизна кэша. Новизна кэша определяется конечным сервером.
  3. Предупреждение. Транзитный сервер должен предупреждать клиента о том, что его информация из кэша не самая «свежая».

Если все эти правила будут соблюдены, можно спокойно утверждать о том, что клиент получит самую достоверную и новую информацию от транзитного сервера, при этом, не обращаясь к конечному.

Предупреждения при кэшировании в HTTP

Предупреждения при кэшировании отправляет сервер в поле заголовка Warning HTTP ответа в том случае, когда информация из кэша теряет свою актуальность. При этом клиент, получив такое HTTP сообщение может обратиться не к кэшу транзитного сервера, а к первоначальному серверу или предпринять какие-либо другие действия.

Механизмы управления кэшированием в HTTP. Поле заголовка Cache-Control в HTTP

В версии протокола HTTP 1.1 в качестве механизмов управления кэшированием используется поле заголовка Cache-Control. Заголовок Cache-Control позволяет управлять HTTP кэшем, как клиенту, так и HTTP серверу при помощи директив, которые они передают вместе с ответами и запросами. При этом директивы, передаваемые в поле заголовка Cache-Control, отменяют значения по умолчанию для кэширования в HTTP. Необходимо отметить тот момент, что директивам заголовка Cache-Control должны повиноваться все участники цепочки обмена данными между конечным сервером и клиентом.

Для управления кэшированием HTTP клиенты могут использовать директивы, которые указаны в таблице ниже. Директивы поля заголовка Cache-Control для клиента

Номер Директивы поля заголовка Cache Control для клиента и их описание
1 Директива поля заголовка Cache Control для клиентского запроса: no cache

Директива no-cache говорит серверу о том, что для последующего запроса ответ не должен отправляться из кэша без проверки с содержимым исходного сервера.

2 Директива поля заголовка Cache Control для клиентского запроса: no store

Директива no-store говорит серверу о том, что ни запрос клиента, ни ответ сервера не должны кэшироваться. Это сделано для безопасности.

3 Директива поля заголовка Cache Control для клиентского запроса: max age = seconds

Директива max-age говорит серверу о том, что кэш должен быть не старше времени, которое указано в секундах.

4 Директива поля заголовка Cache Control для клиентского запроса: max stale [ = seconds ]

Директива max-stale говорит серверу о том, что клиент примет кэшированный HTTP ответ в том случае, если его возраст не превышает времени, указанного в секундах.

5 Директива поля заголовка Cache Control для клиентского запроса: min fresh = seconds

Директива min-fresh говорит серверу о том, что клиент примет кэшированный HTTP ответ в том случае, если время жизни кэша не больше указанных секунд.

6 Директива поля заголовка Cache Control для клиентского запроса: no transform

Директива min-fresh говорит серверу о том, что к запрашиваемому ресурсу не должно применяться никаких преобразований.

7 Директива поля заголовка Cache Control для клиентского запроса: only if cached
Директива min-fresh говорит серверу о том, что клиент примет только кэшированный HTTP ответ, если подходящего ответа нет в кэше сервера, то делать ничего не надо.

Мы рассмотрели механизм управления кэшированием HTTP клиентом, теперь давайте разберемся с механизмами управления кэшированием со стороны HTTP сервера. Другими словами: как HTTP ответы могут управлять кэшированием. Управление кэширование со стороны сервера происходит аналогичным образом – при помощи заголовка Cache-Control, но директивы заголовка Cache-Control у сервера свои и, соответственно, свои механизмы управления кэшированием при HTTP соединение. Давайте сведем серверные директивы заголовка Cache-Control в одну таблицу.

Номер Директивы поля заголовка Cache Control для сервера и их описание
1 Директива поля заголовка Cache Control ответа сервера: public

Директива ответа сервера Public говорит о том, что ответ сервера можно сохранять в любом кэше.

2 Директива поля заголовка Cache Control ответа сервера: private

Директива ответа сервера private говорит о том, что ответ сервера нужно сохранять в закрытом кэше, который предназначен только для этого пользователя.

3 Директива поля заголовка Cache Control ответа сервера: no cache

Директива ответа сервера no cache говорит о том, что кэшированный ответ не должен отправляться клиенту без его предварительной проверки.

4 Директива поля заголовка Cache Control ответа сервера: no store

Директива ответа сервера no store говорит о том, что ответ сервера нельзя сохранять в кэше.

5 Директива поля заголовка Cache Control ответа сервера: no transform

Директива ответа сервера no transform говорит о том, что к ответу сервера не должно применяться никаких преобразований ни одним из узлов цепочки.

6 Директива поля заголовка Cache Control ответа сервера: must revalidate

Директива ответа сервера must revalidate говорит о том, что если HTTP сообщение сервера устарело, то к нему должна применяться предварительная проверка.

7 Директива поля заголовка Cache Control ответа сервера: proxy revalidate

Директива ответа сервера proxy revalidate говорит о том, что и предыдущая директива, но только для промежуточных серверов.

8 Директива поля заголовка Cache Control ответа сервера: max age = seconds

Директива ответа сервера max age говорит о том, сколько живет кэш на сервере.

9 Директива поля заголовка Cache Control ответа сервера: s maxage = seconds

Директива ответа сервера s maxage говорит о том, что и директива max-age, но для CDN-серверов

Общий синтаксис механизмов кэширования в HTTP вы сможете найти ниже.

Источник

Adblock
detector