Когда лучше начинать использовать кэширование

Основные принципы кэширования веб-приложений

Веб-приложения прошли большой путь с самого начала. Традиционный процесс создания веб-приложений проходит через несколько этапов проектирования, разработки и тестирования перед тем, как они будут готовы. Как только ваше приложение будет выпущено, реальные пользователи будут постоянно к нему обращаться. Если ваше приложение станет популярно, оно будет доступно по крайней мере нескольким миллионам пользователей ежедневно. Хотя звучит многообещающе, это повлечет за собой дополнительные расходы.

Помимо цены, некоторое время займет выполнение сложных расчетов и операций чтения и записи. Это значит, что ваш пользователь должен дождаться завершения операции. Если ожидание окажется слишком долгим, это может сказаться на пользовательском опыте.

Разработчики систем используют несколько стратегий, чтобы устранить эти проблемы. Кэширование — одно из них.

Кэширование в веб-приложениях — что это?

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

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

Если говорить простым языком, веб-кэширование позволяет повторно использовать HTTP-ответы, которые были сохранены в кэше, с HTTP-запросами аналогичного характера. Давайте рассмотрим простой пример, когда пользователь запрашивает с сервера определенный тип продукта (книги). Можно предположить, что весь этот процесс займет примерно 670 миллисекунд. Если чуть позже в тот же день пользователь выполнит этот же запрос вместо того, чтобы снова повторить те же вычисления и потратить 670 миллисекунд, HTTP –ответ может вернуться к пользователю. Это значительно сократит время отклика. В реальности это может составить менее 50 миллисекунд.

Преимущества кэширования

Существует несколько преимуществ кэширования с точки зрения потребителя и поставщика.

Снижение затрат на пропускную способность

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

Улучшенный отклик

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

Повышенная производительность на том же оборудовании

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

Доступность контента даже при сетевых сбоях

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

Недостатки кэширования

Кэш удаляется во время перезапуска сервера

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

Обслуживание устаревших данных

Одна из основных проблем кэширования — это обслуживание устаревших данных. Устаревшие данные — это необновленные сведения, которые содержат предыдущую версию данных. Если вы кэшировали запрос продуктов, но в то же время, менеджер удалил четыре продукта, пользователи получат списки продуктов, которые не существуют. Такое положение сложно выявить и исправить.

Где можно кэшировать?

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

Кэш браузера

Веб-браузеры имеют небольшой собственный кэш. Обычно браузер устанавливает политику, которая определяет наиболее важные элементы для кэширования. Это может быть пользовательский контент или контент, который будет ценен для загрузки и, вероятно, будет восстановлен. Чтобы отключить кэширование источника, вы можете установить заголовок ответа, как показано ниже:

Прокси-серверы для промежуточного кэширования

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

Обратный кэш

Вы можете реализовать собственную инфраструктуру кэширования в своих внутренних службах. Для этого вы можете воспользоваться такими платформами, как Redis или Memcache.

Прочитайте более подробно о Cache-Control в этой статье.

Что можно кэшировать?

Все типы контента можно кэшировать, но это не значит, что это всегда необходимо.

Совместимость с кэшем

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

· Изображения, логотипы и иконки

Умеренно совместим с кэшированием

Нижеприведенный контент может быть кэширован, но следует соблюдать особую осторожность, так как этот тип контента может регулярно меняться:

• Часто изменяемые JS и CSS
• HTML-страницы
• Запрос контента с файлами cookie

Никогда не кэшируются

Данные типы контента нельзя кэшировать, иначе у вас могут возникнуть проблемы с безопасностью:

· Конфиденциальный контент, например — банковская информация и т.д.

· Чаще всего пользовательские данные не должны кэшироваться, так как они регулярно обновляются

Зачем нужна стратегия кэширования?

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

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

Цель данной статьи — ознакомить вас с базовыми знаниями кэширования для веб-приложений. Мы пропустили такие темы, как заголовки управления, инфраструктура кэширования, руководство по разработке кэш-стратегии и т.д., так как они слишком сложны для этого введения.

Веб-кэширование на примере покупки молока в магазине

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

Если вы — активный пользователь Интернета (а это, скорее всего, именно так), вы постоянно используете кэширование, но можете и не знать «закулисье»: когда и как оно работает.

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

При кэшировании время загрузки страницы снижается с 2 секунд до 1 секунды… что не очень впечатляет, верно? Но без него не обойтись, когда приходится обрабатывать запросы от большого числа пользователей.

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

Чтобы понять мое объяснение, нужно немного знать об основах работы веб-серверов. Приступим!

Как бы выглядел Интернет без кэширования?

Прежде чем мы перейдем к кэшированию, давайте поразмышляем, как Интернет выглядел бы без него. Представьте на мгновение, что вы живете в XVIII–XIX вв. в сельской местности. У вас есть ферма, но нет холодильника. Вы держите несколько коров, но их молоко быстро портится, и поэтому получить с этого выгоду очень сложно.

Кстати, кое-где у людей до сих пор нет холодильников: они либо выпивают свежее молоко сразу, либо смешивают его с зерном и дают забродить — интересный подход, правда?

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

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

Без кэширования вас ограничивает вычислительная мощность серверов. Кэширование используется для загрузки таких статических ресурсов, как:

• изображения,
• CSS,
• статические HTML-файлы,
• JavaScript-файлы.

В идеале нагрузку на серверы хотелось бы уменьшить, каким-то образом сохраняя ответы на распространенные запросы. Серверу не придется обрабатывать каждый новый отдельный запрос — ответ будет получен из кэша. Конечно, всегда можно раскошелиться и добавить еще серверов, но это может привести к неконтролируемому росту расходов.

Кэширование на стороне сервера

Вернемся к нашим коровам. Знаете, что облегчило бы работу нашей молочной фермы?

Магазин с холодильником!

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

Магазин снимает нагрузку с фермы: теперь коров не нужно тревожить для каждого покупателя. Удовлетворением спроса занимается магазин, а вам остается лишь ежедневно доить своих буренок. И еще один плюс: покупать хранящееся в холодильнике молоко теперь смогут и жители окрестных деревень.

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

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

К этому моменту у вас, возможно, уже есть вопросы:

1. Как определить «популярный» запрос?
2. Как долго ответы хранятся в кэше прокси-сервера?

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

Сеть доставки контента

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

Итак, вы начинаете развозить молоко в другие магазины и таким образом удовлетворяете спрос в гораздо более обширном географическом регионе. Это похоже на сеть доставки контента (CDN) — расположенные по всему миру прокси-серверы (такие, как рассмотренные выше).

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

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

Таким образом, ваши серверы могут отправить копию статических ресурсов на каждый из прокси-серверов в сети CDN, с тем чтобы те обрабатывали локальные запросы, пока ресурсы не перестанут быть «свежими». Популярные поставщики услуг CDN — Rackspace, Akamai и Amazon Web Services.

Кэширование на стороне браузера

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

Нас спасет холодильник!

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

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

И тут важно заметить, что молоко в холодильнике НЕ ПОЯВЛЯЕТСЯ САМО СОБОЙ! Все равно нужно сделать исходный запрос, который дойдет до сервера либо прокси-сервера, и только после этого можно закэшировать некоторые файлы локально.

Откуда браузер знает, когда запрашивать новые файлы с сервера? Ведь нужно же как-то обновлять локальные файлы.

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

Когда начинать использовать кэширование

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

Возьмем, к примеру, Heroku — отличный инструмент для развертывания первого веб-приложения. Однако для реализации кэширования придется использовать отдельный сервис — например, CloudFront от Amazon или CloudFlare, — и на изучение этого понадобится больше времени.

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

Обычно причина этого — работа протокола кэширования на стороне браузера. Чтобы обойти кэш браузера и запросить с сервера новые ресурсы, можно нажать Cmd+Shift+R (если у вас Mac) или Ctrl+Shift+R (на PC).

О переводчике

Перевод статьи выполнен в Alconost.

Alconost занимается локализацией игр, приложений и сайтов на 68 языков. Переводчики-носители языка, лингвистическое тестирование, облачная платформа с API, непрерывная локализация, менеджеры проектов 24/7, любые форматы строковых ресурсов.

Мы также делаем рекламные и обучающие видеоролики — для сайтов, продающие, имиджевые, рекламные, обучающие, тизеры, эксплейнеры, трейлеры для Google Play и App Store.

Что такое кэширование сайта и почему это важно

Кэширование сайтов — это одна из наиболее полезных технологий. Ее применение делает сайты чрезвычайно быстрыми, что приводит к улучшению SEO и повышению удовлетворенности пользователей. Не говоря уже о более высокой конверсии, которую дает интернет кэш.

Что такое кэширование?

Сама идея реализации кеширования проста. Позвольте мне привести пример.

Если я спрошу вас, сколько будет 5 умножить 3, вы поймете, что правильный ответ 15. При этом не нужно его вычислять — вы просто помните результат, и не осуществляете никакой умственной обработки. Примерно так и работает кеширование.

Сайты тысячи, а иногда и миллионы раз в месяц. Каждый раз, когда браузер запрашивает веб-страницу, сервер должен выполнять кучу сложных вычислений. Он извлекает последние записи, генерирует шапку и подвал сайта, находит виджеты боковой панели и так далее. Но во многих случаях результат вычислений будет неизменным. Здорово, если бы мы могли заставить сервер запомнить окончательный результат, а не обрабатывать каждый запрос отдельно. Это именно то, что делает кеширование!

Как обслуживаются страницы с кэшем

Интернет кэш — что это такое? Сейчас поясню. Допустим, у вас есть блог с включенным кэшированием. Когда кто-то посещает главную страницу вашего блога в первый раз, он получает ее обычным способом: запрос обрабатывается на сервере, и полученная веб-страница, которая должна быть отображена, преобразуется в HTML-файл и отправляется в браузер посетителя.

Поскольку кэширование включено, сервер сохраняет этот HTML-файл в своей « оперативной памяти » ( или RAM ), это делается очень быстро. В следующий раз, когда вы захотите просмотреть главную страницу, серверу не придется выполнять обработку и преобразование в HTML . Вместо этого он отправит ранее подготовленный HTML-файл в браузер.

Но что, если мой контент изменяется?

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

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

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

Является ли кэширование эффективным?

Сайт, разработанный и реализованный надлежащим образом, может загружаться всего за две секунды. Разве это недостаточно быстро? Необходимо ли использовать кэширование? Ответ — однозначно, да.

Используя кэширование в браузере и на сервере, вы все равно сможете сократить время загрузки. А когда речь идет о скорости загрузки, всегда стоит сделать так много, как только возможно!

Насколько эффективно кэширование? Согласно недавнему исследованию YUI , кэширование в браузере может увеличить скорость сайта на целых 300%!

Типы кэширования

Существует два типа кэширования — серверный и браузерный. Давайте рассмотрим различия между ними.

Кэширование в браузере

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

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

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

Вместо обработки каждого запроса сервер принимает результаты этих запросов и сохраняет их. Затем он обслуживает сохраненные результаты, делая все намного быстрее.

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

Кэш объектов хранит только фрагменты данных, а не полную страницу. Это может быть полезно при сохранении результата сложных операций, таких как создание меню навигации.

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

Есть три вещи, которые нужно знать о кешировании в WordPress: написание эффективного кода, использование плагинов кэширования и использование встроенного кэша хостинга.

Использование плагинов кэширования WordPress

Самое важное правило – никогда не используйте одновременно больше одного плагина кэша страниц интернета. Это не сделает ваш сайт быстрее, а намного медленнее и в результате просто сломает.

Используйте одновременно только один плагин кэширования. При правильной настройке это поможет значительно ускорить работу сайта. Лучшие плагины кэширования — WP Rocket , W3 Total Cache и WP Super Cache .

Использование кэширования, осуществляемого хостингом

Это относится к сайтам, которые работают на WordPress . Я могу рекомендовать WPEngine , Flywheel и Kinsta . Все они предоставляют превосходные сервисы кэширования.

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

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

Написание эффективного кода

Мы не будем вдаваться в подробности, но первое, что вы должны знать — это то, как устроен WordPress .

Например, если вы получаете метаданные для записи, и вызываете get_post_meta($post_id, ‘co-author’, true );,WordPress извлекает все метаданные для этого поста. Поэтому наличие 50 отдельных запросов get_post_meta() для извлечения одной записи не является расточительством.

Следующее, что вам нужно изучить, это как правильно использовать переходные процессы в WordPress . Переходные процессы — это своеобразное решение для кэширования объектов с датой истечения срока действия. Их можно использовать для кэширования подвала или шапки, которые не изменяются с течением времени, за исключением особых случаев. Тогда вы просто очищаете кэш.

Заключение

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

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

Уровни и виды кэширования когда применять и когда кеширование вредно

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

Кэш или кеш (англ. cache, от фр. cacher — «прятать»; произносится [kæʃ] — «кэш») — промежуточный буфер с быстрым доступом к нему, содержащий информацию, которая может быть запрошена с наибольшей вероятностью. Доступ к данным в кэше осуществляется быстрее, чем выборка исходных данных из более медленной памяти или удаленного источника, однако ее объем существенно ограничен по сравнению с хранилищем исходных данных.

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

В первую очередь, хотелось бы пояснить, что кэширование – это одна из наиболее важных составляющих любого проекта. В частности, это единственный способ сделать больше и быстрее при использовании ограниченных ресурсов. А, как известно, ресурсы всегда ограничены: как серверные, так и пользовательские.

Зачем нужен кеш

Кеш приближает данные к месту их использования. В современном мире, состоящим на 98% из интернета, данные обычно лежат очень далеко от пользователя. На всем пути от хранилища к пользователю есть кеши, которые служат только одной цели – чтобы пользователь как можно быстрее получил свои данные.

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

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

Кеш нельзя просто включить

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

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

Очень важно понимать что и как вы собираетесь кешировать, чтобы не нарушать логику работы приложения. И первый вопрос, на который вам необходимо ответить – насколько устаревшие данные можно отдавать клиенту. Естественно можно сделать свой кеш для каждого клиента, это упростит решение вопроса об актуальности данных, но принесет много других проблем.

Основные проблемы кэширования

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

Второй проблемой кэширования является проблема быстродействия. А не выполняются ли наш алгоритм без кэширования быстрее, чем с кэшированием? Несмотря на абсурдность с первого взгляда, она более чем имеет место. Дело в том, что алгоритмы кэширования тоже потребляют ресурсы, и запросто может случиться так, что количество потребляемых кэшем ресурсов превышает количество ресурсов для вычисления самих данных. Это часто случается в 2-х случаях. Первый случай — это когда сайт из 10-ти страниц сажают на мощный фреймворк. Тут все просто – исходных данных настолько мало, что скорость вычисления очень высока, а кэширование только тормозит работу. Второй случай обратный — когда сайт настолько большой, что размер кэша вырастает до объемов приводящих к существенному замедлению их поиска в кэше.

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

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

А вот что касается проблемы актуальности, тут все намного сложнее…

Теория кэша

Автор различает 4 основных типа кэширования информации:

1. Независимый или статичный – имеет место, когда не требуется проверка изменился ли объект. Алгоритм прост – если есть данные в кеше, то отдать данные, иначе их вычислить. Эффективно в рамках работы одного процесса, когда требуется частое использование результатов сложных промежуточных вычислений. После завершения процесса статичный кэш умирает и для повторного процесса все данные вычисляются вновь. Вобщем-то в любом языке программирования все временные переменные – ни что иное, как статичный кеш. Если же требуется кэширование результатов функции, то можно использовать такой алгоритм с использованием static-переменных на примере PHP:

function getData($id)
<
static $data = array();

if (isset($data[$id])) return $data[$id];

// вычисление данных
$data[$id] = $newData;

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

3. Неявно-зависимый – имеет место, когда изменение объекта кэширования зависит от множества факторов. Например, в состав объекта входит множество других объектов, которые тоже могут изменяться. То есть объект неявно (не на прямую) зависит от других, которые тоже могут зависеть от других и т.д. Совокупность этих факторов является неявными зависимостями объекта, и что бы принять решение о том, изменился ли объект нужно «опросить» их все, что не всегда возможно или целесообразно. Например, функция, которая показывает информацию, взятую из базы данных. Мы можем закешировать результат функции, но мы должны знать, когда данные изменятся, что бы их обновить. А это эквивалентно обращению к таблице, что по ресурсоемкости равносильно выполнению функции. А если таблиц много? Смысл кэша теряется.

Это раскрывается через так называемую «таблицу зависимостей». В этой таблице присутствует 2 столбца: объекты и время их изменения. При изменении объектов необходимо обновлять их времена в таблице. Скорость доступа к самой таблице очень высока, (как правило, она находится в статичном или явно-зависимом кеше), и получить времена изменения всех необходимых нам объектов можно очень быстро. И если хоть одно время изменения нужных объектов превышает время кэширования, то кэш необходимо сбросить. Таким образом, неявные зависимости превращаются в явные – объект зависит от некоторого набора времен в таблице зависимостей.

Приведу пример. Есть некий модуль CMS, который занимается отображением комментариев. У нас есть 2 таблицы в БД – пользователей и комментариев, которые связаны соотношением один-ко-многим. При изменении данных некоторого пользователя, мы устанавливаем текущее время в строке «users» в таблице зависимостей. Если изменились комментарии, мы аналогично поступаем со строкой «comments». Модуль знает, что он зависит от «users» и «comments» и если время хотя бы одного из них превышает время изменения кэша, то кэш сбрасывается, иначе — используется. Обращу внимание на то, что «users» и «comments» — это не обязательно время изменения таблицы, это скорее времена изменения некоторой сущности, которая может состоять из множества таблиц и других параметров.

4. Условно-зависимый – имеет место, когда неявно-зависимый кэш может быть приведен к явно-зависимому или статичному при выполнении некоторого условия. Например, можно утверждать, что время последнего изменения таблицы зависимостей – это время последнего изменения данных на сайте. Если для пользователя на странице нет уникальных данных (читай – он не залогинен), то вся страница будет зависеть только от таблицы зависимостей. А значит, всю страницу целиком можно положить в кэш, на данном условии. Сюда же относится кэш, который в нужный момент просто физически удаляется.

Типы кеширования

Есть три основных типа кеширования по механике работы:

• Lazy cache, он же ленивый кеш, он же тупой кеш – самый простой в реализации тип кеширования, зачастую встроен в фреймворки. Кеш просто сохраняет данные и отдает их пока не устареет.
• Synchronized cache, синхронизированный кеш – клиент вместе с данными получается метку последнего изменения и может спросить у поставщика не изменились ли данные, чтобы повторно из не запрашивать. Такой тип кеширования позволяет всегда иметь свежие данные, но очень сложен в реализации.
• Write-through cache, или кеш сквозной записи – любое изменение данных выполняется сразу в хранилище и в кеше. Этот тип кеша может никогда не устаревать, но возникают проблемы с так называемой “когерентностью”.

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

Устаревание и когерентность кеша

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

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

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

Эффективность кеша

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

Частые сбросы кеша, кеширование редко запрашиваемых данных, недостаточный объем кеша – все это ведет к пустой трате оперативной (обычно) памяти, не повышая эффективность работы.

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

Применение разных типов кеширования

Ленивый кеш

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

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

Такой тип кеширования позволит быстрее всех дать ответ.

Синхронизированный кеш

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

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

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

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

Если есть система распределенного кеширования (memcached, Windows Sever App Fabric, Azure Cache), то можно использовать кеш сквозной записи. Рукопашная реализация синхронизации кешей между узлами сама по себе отдельный большой проект, потому не стоит заниматься ей в рамках разработки приложения.

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

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

Что еще нужно учитывать в стратегии кеширования

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

Кешируйте данные как можно позже, непосредственно перед отдачей во внешнюю систему. Кешировать данные, полученные извне, необходимо только в случае проблем с производительностью на этом этапе. Внешние хранилища, такие как СУБД и файловые системы, сами реализуют кеширование, поэтому обычно нет смысла кешировать результаты запросов.

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

Что можно кэшировать?

Некоторый контент легче кэшировать . Об этом говорит сайт https://intellect.icu . Для большинства сайтов кэшировать лучше:

• Логотипы и изображения бренда.
• Не ротируемые изображения в целом (например, значки навигации).
• Стили.
• Общие файлы Javascript.
• Загружаемый контент.
• Файлы мультимедиа.

Эти элементы меняются нечасто, поэтому их можно кэшировать в течение более длительных периодов времени.

А эти элементы нужно кэшировать осторожно:

• HTML-страницы.
• Ротируемые или изменяемые изображения.
• Часто изменяемые Javascript и CSS.
• Контент, запрашиваемый с помощью файлов cookie.

Кэшировать не рекомендуется, вредно или нельзя:

• Активы, связанные с конфиденциальными данными. (банковская информация и т. д.)
• Контент, который зависит от пользователя и часто изменяется.

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

Основной проблематикой кэширования является быстрота реакции на запросы к основным системам хранения и обработки входящей и исходящей структурированной информации.

Представьте, что необходимо осуществить быструю передачу информации, однако скорость доступа к данным крайне низкая. Или другая ситуация: скорость хорошая, но мало доступной памяти или ширина канала недостаточная, или процессорные и дисковые факторы мешают осуществить задачу. В этом случае кэширование – это единственный выход из ситуации.

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

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

Процессорный кэш

Начнем наш разговор о кэшах с самого низкого уровня — с процессора. Кэш-память процессора — это очень быстрая память, которая играет роль буфера между процессором (CPU) и оперативной памятью (RAM). Кэш-память хранит данные и инструкции, к которым обращаются чаще всего, благодаря чему процессор может получать ко всему этому доступ практически мгновенно.

В процессорах имеется особая память, представленная регистрами процессора, которая обычно представляет собой небольшое хранилище информации, обеспечивающее крайне высокую скорость обмена данными. Регистры — это самая быстрая память, с которой может работать процессор, которая расположена максимально близко к остальным его механизмам и имеет небольшой объем. Иногда регистры называют кэшем нулевого уровня (L0 Cache, L — это сокращение от Layer).

У процессоров, кроме того, имеется доступ к еще нескольким уровням кэш-памяти. Это — до четырех уровней кэша, которые, соответственно, называются кэшами первого, второго, третьего, и четвертого уровня (L0 — L4 Cache). То, к какому именно уровню относятся регистры процессора, в частности, будет ли это кэш нулевого или первого уровня, определяется архитектурой процессора и материнской платы. Кроме того, от архитектуры системы зависит то, где именно — на процессоре, или на материнской плате, физически расположена кэш-память разных уровней.

Структура памяти в некоторых новейших CPU

Кэш жесткого диска

Жесткие диски (HDD, Hard Disk Drive), применяемые для постоянного хранения данных — это, в сравнении с оперативной памятью, предназначенной для кратковременного хранения информации, устройства довольно медленные. Однако надо отметить, что скорость постоянных хранилищ информации увеличивается благодаря распространению твердотельных накопителей (SSD, Solid State Drive).

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

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

О быстродействии жестких дисков и оперативной памяти

Разница между временным хранением данных в оперативной памяти и постоянным хранением на жестком диске проявляется в скорости работы с информацией, в стоимости носителей и в близости их к процессору.

Время отклика оперативной памяти составляет десятки наносекунд, в то время как жесткому диску нужны десятки миллисекунд. Разница в быстродействии дисков и памяти составляет шесть порядков!

Одна миллисекунда равна миллиону наносекунд

Consistent hashing Согласованное хеширование (англ. consistent hashing) — особый вид хеширования, отличающийся тем, что когда хеш-таблица перестраивается, только ключей в среднем должны быть переназначены, где — число ключей и число слотов (slots, buckets). В противоположность этому, в большинстве традиционных хеш-таблиц, изменение количества слотов вызывает переназначение почти всех ключей.

Согласованное хеширование достигает тех же целей, что и рандеву-хеширование (англ. rendezvous hashing). Обе методики используют разные алгоритмы, и были разработаны независимо и одновременно.

если данные меняются? используется инвалидация

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

Возможны два механизма, чтобы помочь решить эту проблему:

• Инвалидация, основанная на тегах для управления зависимостями данных;
• Инвалидация, основанная на сроке действия для зависимостей, связанных со временем.

Виды кэширования

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

Необходимо понимать, что работу с данными можно производить как на стороне клиента, так и на сервере. Притом, серверная обработка данных централизована и имеет ряд несомненных преимуществ (особенно для службы поддержки).

Существует несколько видов кэширования, предлагаем рассмотреть каждый вид, его особенности и рекомендации по применению:

1. Браузерное кэширование или клиентское кэширование

Представляет собой составление для браузера команды использовать имеющуюся кэшированную копию. Работа такого кэширования основана на том, что при повторном посещении, браузеру отдается заголовок 304 Not Modified, а сама страница или картинка загружаются из локального пользовательского кэша. Получается, что вы экономите на трафике между браузером посетителя и хостингом сайта. Соответственно, страница вашего сайта начинает загружаться быстрее.

1.1 Кэширование файлов и картинок

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

Это первый уровень кэширования, который состоит в отдаче заголовка «expired» и заголовка «304 Not Modified». Наиболее эффективным считается кэширование на 2 недели.

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

1.2 Кэширование https

Специальные заголовки вида strict-security. Позволяет браузеру всегда обращаться по https к выбранному домену. Сохраняет это состояние довольно жестко и, в случае отмены этого вида кэша, браузер еще довольно долго будет пытаться загрузить страницу по https, при этом игнорируя текущие заголовки.

1.3 Кэширование центра сертификации

Так называемый, stamp центра сертификации.

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

1.4 Кэширование страниц

Когда страница уже сгенерирована, нужно постоянно отслеживать ее актуальность. Для этого вы должны использовать серверный кэш с отслеживанием времени изменения отдельных частей страницы (если страница строится из множества динамически генерируемых блоков). При таком подходе в каждом ответе от сервера установлены специальные заголовки, обозначающие время изменения страницы, которые затем отправляются браузером пользователя при повторном обращении к странице сайта. Сервер при получении таких заголовков можем проанализировать текущее состояние страницы (возможно, даже отрисовать ее), но вместо содержимого страницы отдать заголовок «304 Not Modified», что для пользовательского браузера будет означать, что можно показать страницу из своего (браузера пользователя) кэша.

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

Как правило, кэш подразделяется по типу пользователей:

— для авторизованных;
— для неавторизованных.

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

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

2. Серверное кэширование

Под серверным кэшированием понимаются все виды кэширования, при котором данные хранятся на серверной стороне. Эти данные не доступны клиентским браузерам. Кэш создается и хранится по принципу «один ко многим» (многие, в данном случае, — это клиентские устройства).

2.1 Кэширование страницы целиком

Наиболее эффективный кэш. Чем он интересен? Самое большое его достоинство в том, что отдача страницы происходит практически в момент обращения, как следствие – это возможность обработки миллионов запросов даже на самом слабом сервере со скоростью работы памяти и с незначительным задействованием процессора.

Пожалуй, любой когда-либо мечтал о сайте, работающем со скоростью «ping» или быстрее.
Но и у этого типа кэша есть свои минусы: например, невозможность кэшировать страницы для авторизованного пользователя, либо пользователя, содержимое страницы которого зависит от текущих переменных пользователя.

Используйте этот кэш, если серверу известны все статичные состояния внешних данных, такие как: uri, get (без дополнительных параметров), пользователь не авторизован — то есть, фактически, это идеальное состояние страницы для гостевых пользователей. Учитывайте тот факт, что при таком кэшировании архитектура сайта или приложения всегда должна однотипно обрабатывать входящие запросы и отдавать однотипные ответы. Такое состояние есть в любом приложении или сайте, его нужно лишь отследить и применить к нему кэш.

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

2.2 Кэширование результатов компиляции php-файлов

Различают как чистую компиляцию кода, так и его оптимизацию во время компилирования (подмена скриптов). Наиболее яркие примеры:

— APC;
— XCache;
— Компиляция с подменой скриптов HipHopVirtualMachine.

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

2.3 Кэширование отдельных блоков страницы

Это, пожалуй, самый интересный, но и сложный вид кэширования. Тем не менее, он тоже может быть эффективным, и на его примере легче всего объяснить принципы кэширования в целом.

Необходимо отслеживать: состояние таблиц, состояние сессии пользователя, выключать ли кэширование при POST или GET запросах (http query), зависимость от текущего адреса, постоянство кэширования (при изменении предыдущих условий) или его динамическую подстройку.

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

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

2.4 Кэширование php на основе неразделяемых ресурсов

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

2.5 Кэширование php на основе общих ресурсов

Такое кэширование применяйте для хранения сериализированных данных. Например: конфигурационного файла, состояния таблиц, списков файловой системы.

2.6 Кэширование mysql на основе query cache

Это довольно известная и наиболее освещенная тема. Тем не менее, хотелось бы рассмотреть специфику работы с timestamp и то, как можно избежать постоянного сброса query cache.

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

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

Мы предлагаем следующий выход из ситуации:

Как правило, любой материал публикуется в определенные моменты времени. К примеру, 00:00. Все что нужно сделать — создать запрос, который будет оценивать таблицу по максимальной дате, при этом, меньшей текущей.

Да, этот запрос кэшироваться не будет, но будут кэшироваться все запросы к этой таблице, если их количество больше одного. Эта простая операция существенно улучшит жизнь sql-кэширования.

Кэшировать эти запросы имеет смысл, если чтений из таблицы немного больше чем записи.

2.7 Кэширование mysql результатов работы, агрегирующие таблицы

Существует правило: обновлений данных должно быть значительно меньше, чем чтения для их отдачи.

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

Что выбирать для агрегирования? Обычно это какая-то статистическая информация о числе записей, дате последнего обновления, авторе последнего обновления и тому подобное.

Простой веб-сервер

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

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

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

При последующих запросах, направленных на получение тех же данных, поиск в кэше окажется успешным, это — так называемое «попадание кэша». Данные в ответ на запрос будут поступать из дискового буфера до тех пор, пока они не будут перезаписаны, что, при повторном обращении к тем же данным, приведет к промаху кэша.

Кэширование баз данных

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

Простой веб-сервер с базой данных

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

Кэширование ответов веб-сервера Клиентское кэширование

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

Кэш ответов и кэш приложения

Ответы веб-сервера кэшируются в оперативной памяти. Кэш приложения может храниться либо локально, в памяти, либо на специальном кэширующем сервере, который использует базу данных, вроде Redis, которая хранит данные в оперативной памяти.

HTTP-кэш любят все

браузеры — быстрее открывают страницу (повторно, «Назад») поисковики — быстрее индексируют прокси — лучше работают А нагрузка — снижается… Защита от умника с кнопкой F5

Браузеры/прокси могут сохранять HTTP-ответы Есть статус ответа HTTP 304 Not Modified Есть заголовки для управления кэшированием Причем частично в довольно диких комбинациях Куча костылей для проксей

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

Минимум 5 уровней кеширования: данные (в RAM), рендер модуля (HTML), рендер страницы(HTML), статика на клиенте(JS/CSS), объектные коды скриптов (Opcache) и все их нужно отключить на время разработки .

Управление HTTP-кэшированием

• HTTP 1.0:
• (по времени) Last-Modified, If-Modified-Since
• Expires, Pragma: no-cache
• HTTP 1.1: (по времени и значениям)
• ETag, If-None-Match
• Vary Cache-Contro

Мемоизация функций

Сейчас поговорим об оптимизации производительности серверного приложения за счет мемоизации. Это — разновидность кэширования, применяемая для оптимизации работы с ресурсоемкими функциями. Данная техника позволяет выполнять полный цикл вычислений для определенного набора входных данных лишь один раз, а при следующих обращениях к функции с теми же входными данными сразу выдавать найденный ранее результат. Мемоизация реализуется посредством так называемых «таблиц поиска» (lookup table), хранящих ключи и значения. Ключи соответствуют входным данным функции, значения — результатам, которые возвращает функция при передаче ей этих входных данных.

Мемоизация функции с помощью таблицы поиска

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

Кэширование в браузере

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

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

Перед нами весьма полезная технология, которая дает следующие преимущества всем участникам обмена данными:

• Улучшаются впечатления пользователя от работы с сайтом, так как ресурсы из локального кэша загружаются очень быстро. Во время получения ответа не входит время прохождения сигнала от клиента к серверу и обратно (RTT, Round Trip Time), так как запрос не уходит в сеть.
• Уменьшается нагрузка на серверное приложение и на другие серверные компоненты, ответственные за обработку запросов.
• Высвобождается некоторая часть сетевых ресурсов, которыми теперь могут воспользоваться другие пользователи интернета, экономятся средства на оплату трафика.

Кэширование в браузере

Кэширование и прокси-серверы

В компьютерных сетях прокси-серверы могут быть представлены специальным аппаратным обеспечением или соответствующими приложениями. Они играют роль посредников между клиентами и серверами, хранящими данные, которые этим клиентам требуются. Кэширование — это одна из задач, которую они решают. Рассмотрим различные виды прокси-серверов.

▍Шлюзы

Шлюз (gateway) — это прокси-сервер, который перенаправляет входящие запросы или исходящие ответы, не модифицируя их. Такие прокси-серверы еще называют туннелирующими прокси (tunneling proxy), веб-прокси (web proxy), прокси (proxy), или прокси уровня приложения (application level proxy). Эти прокси-серверы обычно совместно используются, например, всеми клиентами, находящимися за одним и тем же файрволом, что делает их хорошо подходящими для кэширования запросов.

▍Прямые прокси-серверы

Прямой прокси-сервер (forward proxy, часто такие серверы называют просто proxy server) обычно устанавливается на стороне клиента. Веб-браузер, который настроен на использование прямого прокси-сервера, будет отправлять исходящие запросы этому серверу. Затем эти запросы будут перенаправлены на целевой сервер, расположенный в интернете. Одно из преимуществ прямых прокси заключаются в том, что они защищают данные клиента (однако, если говорить об обеспечении анонимности в интернете, безопаснее будет пользоваться VPN).

▍Веб-ускорители

Веб-ускоритель (web accelerator) — это прокси-сервер, который уменьшает время доступа к сайту. Он делает это, заранее запрашивая у сервера документы, которые, вероятнее всего, понадобятся клиентам в ближайшем будущем. Подобные серверы, кроме того, могут сжимать документы, ускорять выполнение операций шифрования, уменьшать качество и размер изображений, и так далее.

▍Обратные прокси-серверы

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

▍Пограничное кэширование

Обратные прокси-серверы расположены близко к серверам. Существует и технология, при использовании которой кэширующие серверы располагаются как можно ближе к потребителям данных. Это — так называемое пограничное кэширование (edge caching), представленное сетями доставки контента (CDN, Content Delivery Network). Например, если вы посещаете популярный веб-сайт и загружаете какие-нибудь статические данные, они попадают в кэш. Каждый следующий пользователь, запросивший те же данные, получит их, до истечения срока их кэширования, с кэширующего сервера. Эти серверы, определяя актуальность информации, ориентируются на серверы, хранящие исходные данные.

Прокси-серверы в инфраструктуре обмена данными между клиентом и сервером

Кеширование для приложения использующее HMVC архитектуру

Блочная структура естественна Удобно кэшировать!

Юзают авторы поделия под названием Kohana Framework

Однако они о кэшировании НЕ ЗНАЮТ! и поэтому его там правильного нет

Оценка эффективности кэша

• Главное — ВЫИГРЫШ В ПРОИЗВОДИТЕЛЬНОСТИ
• Профилирование С кэшем и БЕЗ кэша Hit/Miss (попадания/промахи)
• Низкие hit: горячие/взрыв/дублирование /размер
• Размер кэша, количество вытеснений

Типичные фейлы (Анти-паттерны кэширования)

• Слишком мало
• Слишком много

Fail № 1 «Положил и точно заберу» Например, сессии в memcached

Fail № 2 Кэширование авторизованных страниц Или одного и того же списка с выбранным элементом (итог — комбинаторный взрыв)

Fail № 3 Аппарат искусственного дыхания Будет очень грустно его отключать (сбрасывать кэш)

Fail № 4 Cache hit под 100 %, а все тормозит! Кэшировали яро, но не то, что надо

Выводы

• Кэш — не БД!
• Обычно внешний кэш лучше (масштабируется)
• Обычно полезны теги
• Всегда нужна оценка работы кэша
• Стараться кэшировать целые страницы
• HMVC memcached, redis
• Теги, Last-Modified
• PHP: обязательны APC/XCache, OPCashe, JIT, igbinary
• Тюнить кэш и делать более тонкую настройку кеширования СУБД
• Поменьше фреймворков, побольше разума

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

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

См. также

• оптимизация программ , latency numbers every programmer should know , задержки в передаче данных , Таблица которую должен знать каждый инженер
• оптимизация сайта , производительность сайта ,
• кэширование , memcached ,

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