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


Содержание

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

Кэширование сайтов — это одна из наиболее полезных технологий. Ее применение делает сайты чрезвычайно быстрыми, что приводит к улучшению 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 . Переходные процессы — это своеобразное решение для кэширования объектов с датой истечения срока действия. Их можно использовать для кэширования подвала или шапки, которые не изменяются с течением времени, за исключением особых случаев. Тогда вы просто очищаете кэш.

Заключение

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

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

Данная публикация представляет собой перевод статьи « What is Website Caching and Why is it so Important » , подготовленной дружной командой проекта Интернет-технологии.ру

Что такое кэш сайта и зачем он нужен?

На данный момент на моём блоге рассмотрен весь цикл создания сайта на CMS для OpenCart и WordPress.

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

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

А начнём мы данный цикл статей с общих понятий и сегодня мы рассмотрим что такое кэш сайта и зачем он нужен.

Что такое кэш сайта?

Кэш сайта – это совокупность наиболее часто используемых в процессе работы объектов: изображений, html-шаблонов, файлов js, css, а также результатов запросов в базу данных сайта.

Процесс занесения объектов ресурса в кэш называется кэшированием сайта.

Надо сказать, что понятия кэша и кеширования не ново. Впервые оно прозвучало в далёком 1968 году в статье журнала IBM System Journal о модернизации памяти в разрабатываемой тогда модели компьютеров IBM System/360 (S/360).

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

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

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

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

Приложения взаимодействуют с кэшом по следующей схеме:

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

Настройки времени хранения кэша сайта хранятся в файлах конфигурации веб-серверов и самого ресурса.

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

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

Где происходит кэширование сайта и что это такое?

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

Различают серверное и клиентское кэширование сайта.

Серверное кэширование сайта

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

В данном случае, как правило, кэшируются статические html-страницы и результаты запросов в БД. При этом кэш сайтов может храниться как в виде отдельных файлов, так и размещаться в оперативной памяти вашего удалённого сервера (с использованием memcached).

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

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

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

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

Это его нам всегда рекомендуют очищать при обращении в тех. поддержку сайта при каких-то неисправностях.

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

Настройки кэширования сайта в веб-браузерах клиентов хранятся в конфигурационных файлах веб-серверов.

Если ваш ресурс на хостинге использует Apache, то настройки кеширования сайта будут храниться в файле .htaccess в виде директив max-age и expires, если же используется Nginx, то ищите соответствующие правила в nginx.conf и вызываемых в нём файлах.

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

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

Илон Маск рекомендует:  Что такое код farheapchecknode

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

Но к кэшированию этот механизм не имеет никакого отношения.

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

Чем полезны знания о кэше сайта?

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

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

Такая вот интересная цепная реакция ��

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

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

Как в старой шутке, перефразированной под нашу тему: «– Ты кэш видишь? – Нет. – А он есть» ��

Но, в один прекрасный момент, вам понадобилось изменить картинку на своём ресурсе и вы загрузили её обратно с тем же именем…

Знакомая ситуация? �� Тогда не буду говорить, что вы увидели в итоге.

Или вы стали разработчиком (или таковый являетесь) и в процессе разработки какого-то модуля, плагина или шаблона вы вносите огромное число правок в исходный код. Обновляете страницу…

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

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

Вот и всё, что я хотел вам рассказать.

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

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

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

На этом всё. Всем удачи! ��

P.S.: если вам нужен сайт либо необходимо внести правки на существующий, но для этого нет времени и желания, могу предложить свои услуги.

Более 5 лет опыта профессиональной разработки сайтов. Работа с PHP, OpenCart, WordPress, Laravel, Yii, MySQL, PostgreSQL, JavaScript, React, Angular и другими технологиями web-разработки.

Опыт разработки проектов различного уровня: лендинги, корпоративные сайты, Интернет-магазины, CRM, порталы. В том числе поддержка и разработка HighLoad проектов. Присылайте ваши заявки на email cccpblogcom@gmail.com.

И с друзьями не забудьте поделиться ��

HTTP-кеширование

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

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

К счастью, HTTP предлагает мощное решение: кэширование . В этом посте объясняется, как HTTP может дать указание браузерам повторно использовать дорогие ресурсы, экономя пропускную способность и время. Мы начнем с обзора концепций кэширования, а затем опишем, как эволюционировал механизм кэширования HTTP между HTTP / 1.0 и HTTP / 1.1.

Основы кэширования

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

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

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

Как это сделать? HTTP предлагает два основных средства, первое из которых мы сейчас рассмотрим.

Expires и истоки кеширования HTTP


Expires был введен в HTTP / 1.0 , и, вместе с Pragma , Last-Modified и If-Modified-Since , первую систему кэширования , состоящей протокола HTTP. Это самый простой из имеющихся в вашем распоряжении заголовков кэширования HTTP, указывающий дату, когда данный ресурс устареет:

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

Повторная проверка с Last-Modified и If-Modified-Since

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

Введите If-Modified-Since. Расширяя наш пример выше, представьте, что браузер хотел получить image.jpeg 15 апреля, на следующий день после даты, указанной в Expires заголовке. Вы заметите, что приведенный выше фрагмент кода содержит Last-Modified заголовок, который указывает, когда сервер в последний раз полагал, что изображение было обновлено.

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

Если изображение изменилось, сервер просто ответит полным ответом, содержащим новое изображение. В противном случае он может ответить 304 Not Modified :

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

cache-control и эволюция HTTP-кеширования

Ограничения Expires привели к появлению cache-control в HTTP/1.1, что значительно увеличило гибкость, с которой разработчики могли кэшировать ресурсы. Вместо того, чтобы строго полагаться на даты, cache-control принимает ряд директив, пару из которых мы обсудим сейчас, а остальные сворачиваются в дискуссии о повторной проверке, безопасности и многом другом.

Директива max-age

Думайте о max-age директиве как о более простой альтернативе Expires . Если вы хотите указать, что ресурс истекает в течение одного дня, вы можете ответить следующим заголовком cache-control :

Обратите внимание, что max-age относится ко времени запроса, поэтому таймер начинает отсчитывать время, когда ресурс входит в кеш. Вы можете спросить: «Зачем переходить на секунды по датам?»

У Марка Ноттингема есть хорошее объяснение , и он подчеркивает простоту, работы с max-age . Учтите следующее:

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

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

Повторная проверка с Etag и If-None-Match

HTTP / 1.1 также представил новую стратегию переаттестации для дополнения If-Modified-Since , сосредоточенную вокруг того, что называют «тегами сущностей».

Вы можете рассматривать теги сущностей как способ, с помощью которого серверы могут однозначно идентифицировать версию ресурса с помощью буквенно-цифрового идентификатора, указанного в заголовке ответа ETag :

Если клиент хочет сообщить серверу, что у него есть конкретная версия ресурса, он предоставляет заголовок запроса If-None-Match при следующем запросе ресурса:

Если последняя версия ресурса не соответствует тегу сущности «abc», сервер ответит новой версией. В противном случае он ответит 304 Not Modified .

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

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

Вы можете указать директиву must-revalidate внутри cache-control чтобы информировать клиентов о том, что они должны использовать механизм проверки, будь то теги сущностей или If-Modified-Since , прежде чем выпускать устаревшую копию ресурса из кэша (в случае, если сервер недоступен).

Обеспечение конфиденциальности кэша с помощью private и public

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

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

Чтобы смягчить это, в HTTP / 1.1 были введены директивы public и private в cache-control , которые, хотя и несовершенны, позволяют указывать такие общие кэши, если вы не хотели, чтобы они хранили копию ресурса.

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

Подавление кэширования с помощью no-cache и no-store

HTTP / 1.1 исправил недостаточность заголовка Pragma в HTTP / 1.0 и предоставил веб-разработчикам средства, с помощью которых можно полностью отключить кэширование.

Первая директива, no-cache заставляет кеш повторно проверять ресурс перед повторным использованием. В отличие от этого must-revalidate , no-cache означает, что браузер значительно обновляется во всех случаях, а не только тогда, когда ресурс устарел.

Вторая директива, no-store это молоток: она сигнализирует, что ресурс ни в коем случае не должен входить в кеш.

Указание специфичных для запроса ограничений кэширования

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

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

В дополнение к указанным выше директивам, в cache-control в вашем распоряжении четыре директивы только для запроса.

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

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

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

И, наконец, директива only-if-cached сообщает промежуточным кэшам, что клиент хочет получить только кэшированный ответ, и что в противном случае ему не следует связываться с сервером для получения свежей копии. Если кеш не может удовлетворить запрос, он должен вернуть ответ 504 Gateway Timeout .

Vary и согласованные с сервером ответы

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

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

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

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

Илон Маск рекомендует:  FormatFloat - Функция Delphi

Заголовок Accept-Encoding указывает на то, что серверу разрешается возвращать ресурс с gzip версией, если он способен делать это. Если сервер принимает этот заголовок во внимание при решении, какой ответ отправить нам, он перечислит его в заголовке Vary , добавленном к его ответу:

Конечным результатом этого должно быть то, что кеш должен использовать не только значение URL для кеширования ответа, но и что он должен также использовать значение заголовка запроса Accept-Encoding для дальнейшей квалификации ключа кеша. Таким образом, если бы другой запрос был сделан с другим значением для Accept-Encoding заголовка, например deflate , его ответ не заменил бы указанный запрос gzip .

Заключение

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

АйТи бубен

Инструменты пользователя

Инструменты сайта

Содержание

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

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

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

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

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

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

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

WordPress Плагин кэширования WP Super Cache

Скорость до установки плагин WP Super Cache

Скорость после установки и настройки WP Super Cache

1 вариант. (я использую его) После настройки WP Super Cache, для включения браузерного кеширования добавьте код (Источник Как включить кэш браузера в WordPress). ВКЛЮЧИТЕ в Apache mod_headers.

2 вариант. Можно воспользоваться этим руководством Кеширование с помощью htaccess (Apache). Вставляем код в .htaccess вашего сайта. Включаем сжатие gzip для соответствующих MIME-типов файлов

Браузерное кеширование для нестандартных шрифтов

Включаем заголовки Expires для статичных файлов сроком на 1 год (365 дней) и нестандартных шрифтов сайта. 1 вариант

Настройка сжатия и кэширования через .htaccess

Включить кэширование .htaccess для статических файлов возможно на виртуальном хостинге Linux в Plesk и cPanel. Чтобы управлять настройками кэширования, используйте модуль expires. Как настроить кэширование в ISPmanager?

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

Настройка кэширования:

Настройка expires: 1. Для настройки кэширования сайта .htaccess файл должен находиться в корневой директории вашего сайта. Если у вас нет этого файла воспользуйтесь справкой: У меня нет файла .htaccess, что делать?.

Добавьте в файл .htaccess строки следующего вида:

Настройка сжатия

На серверах виртуального хостинга сжатие .htaccess для статических файлов включено по умолчанию. Статические файлы обрабатываются веб-сервером Nginx, доступа к настройке которого нет.

Проверить наличие сжатия можно при помощи ресурса.

Если вам критична настройка сжатия, рекомендуем приобрести VPS сервер.

Не работает кэширование .htaccess

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

Виртуализация KVM, почасовая оплата, резервные копии, готовые шаблоны, 10 доступных ОС на выбор!

Как настроить правильное кэширование в Apache?

Здравствуйте, уважаемые тостеровцы!

На разрабатываемом сайте обнаружил странную проблему с кэшированием изображений, css-, js-файлов.

На сервере использую LAMP:
— Debian GNU/Linux 7.5 (wheezy).
— Apache 2.2.22 (загруженные модули: alias, auth_basic, authn_file, authz_default, authz_groupfile, authz_host, authz_user, autoindex, cgid, deflate, dir, env, expires, fcgid, headers, mime, negotiation, reqtimeout, rewrite, setenvif, ssl, status, suexec, unique_id, xsendfile).
— PHP 5.4.4-14+deb7u11 (cgi-fcgi).

В директории с изображениями разместил файл .htaccess следующего содержания:

При первом запросе страницы серверу передаются следующие заголовки:

И сервер отвечает следующим образом:

Как видно из них, сервер корректно устанавливает заголовки «Cache-Control» и «Expires».
При повторном запросе, когда изображение уже должно находиться в кэше, почему-то все равно отправляется запрос на сервер:

И вот здесь меня смущает «Cache-Control: max-age=0». Так должно быть?

Ответ от сервера:

Соответственно, это каждый раз вызывает задержку при отображении картинок.
Подскажите, пожалуйста, в чем может быть проблема? В какую сторону копать?
Заранее спасибо!

Основы клиентского кэширования понятными словами и на примерах. Last-modified, Etag, Expires, Cache-control: max-age и другие заголовки

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

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

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

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

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

Http заголовки для управления клиентским кэшированием

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

Без кэша (при отсутствии кэширующих http-заголовков)

Как мы видим, каждый раз при отображении картинки cat.png браузер будет снова загружать ее с сервера. Думаю, не нужно объяснять, что это медленно и неэффективно.

Заголовок ответа Last-modified и заголовок запроса if-Modified-Since .

Идея заключается в том, что сервер добавляет заголовок Last-modified к файлу (ответу), который он отдает браузеру.

Теперь браузер знает, что файл был создан (или изменен) 1 декабря 2014. В следующий раз, когда браузеру понадобится тот же файл, он отправит запрос с заголовком if-Modified-Since .

Если файл не изменялся, сервер отправляет браузеру пустой ответ со статусом 304 (Not Modified) . В этом случае, браузер знает, что файл не обновлялся и может отобразить копию, которую он сохранил в прошлый раз.

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

Заголовок ответа Etag и заголовок запроса If-None-Match .

Принцип работы Etag очень схож с Last-modified , но, в отличии от него, не привязан ко времени. Время – вещь относительная.

Идея заключается в том, что при создании и каждом изменении сервер помечает файл особой меткой, называемой ETag , а также добавляет заголовок к файлу (ответу), который он отдает браузеру:

Теперь браузер знает, что файл актуальной версии имеет ETag равный “686897696a7c876b7e”. В следующий раз, когда брузеру понадобится тот же файл, он отправит запрос с заголовком If-None-Match: «686897696a7c876b7e» .


Сервер может сравнить метки и, в случае, если файл не изменялся, отправить браузеру пустой ответ со статусом 304 (Not Modified) . Как и в случае с Last-modified браузер выяснит, что файл не обновлялся и сможет отобразить копию из кэша.

Подробнее о ETag можно почитать здесь.

Заголовок Expired

Принцип работы этого заголовка отличается от вышеописанных Etag и Last-modified . При помощи Expired определяется “срок годности” (“срок акуальности”) файла. Т.е. при первой загрузке сервер дает браузеру знать, что он не планирует изменять файл до наступления даты, указанной в Expired :

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

Такой вид кэша особенно актуален для иллюстраций к статьям, иконкам, фавиконкам, некоторых css и js файлов и тп.

Заголовок Cache-control с директивой max-age .

Принцип работы Cache-control: max-age очень схож с Expired . Здесь тоже определяется “срок годности” файла, но он задается в секундах и не привязан к конкретному времени, что намного удобнее в большинстве случаев.

  • 1 день = 86400 секунд
  • 1 неделя = 604800 секунд
  • 1 месяц = 2629000 секунд
  • 1 год = 31536000 секунд

У заголовка Cache-control , кроме max-age , есть и другие директивы. Давайте коротко рассмотрим наиболее популярные:

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

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

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

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

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

proxy-revalidate
Это то же, что и must-revalidate , но касается только кэширующих прокси серверов.

s-maxage
Практически не отличается от мах-age , за исключением того, что эта директива учитывается только кэшем резличных прокси, но не самим браузером пользователя. Буква “s-” исходит из слова “shared” (например, CDN). Эта директива предназначена специально для CDN-ов и других посреднических кэшей. Ее указание отменяет значения директивы max-age и заголовка Expired . Впрочем, если вы не строите CDN-сети, то s-maxage вам вряд ли когда-либо понадобится.

Как посмотреть, какие заголовки используются на сайте?

Вы можете посмотреть заголовки http-запросов (request headers) и ответов (response headers) в отладчике Вашего любимого браузера. Вот например, как это выглядит в хроме:

То-же самое можно увидеть в любом уважающем себя браузере или http-сниффере.

Настройка кэшировения в Аpache и Nginx

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

Пример конфигурации Apache для контроля Expires

Выставляем различный “срок годности” для различных типов файлов. Один год для изображений, один месяц для скриптов, стилей, pdf и иконок. Для всего остального – 2 дня.

Пример конфигурации Nginx для контроля Expires

Выставляем различный “срок годности” для различных типов файлов. Одна неделя – для изображений, один день – для стилей и скриптов.

Пример конфигурации Apache для Cache-control (max-age и public/private/no-cache)

Пример конфигурации Nginx для Cache-control статических файлов

В заключение

“Кэшировать все то, что можно кэшировать” – хороший девиз для веб-разработчика. Иногда можно потратить всего несколько часов на конфигурацию и при этом значительно улучшить восприятие вашего сайта пользователем, значительно сократить нагрузку на сервер и сэкономить на трафике. Главное – не переусердствовать и настроить все правильно с учетом особенностей Вашего ресурса.

Будем благодарны за рекомендации и поправки в комментариях и не забудьте поделиться статьей с друзьями, если она Вам понравилась ;)

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

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

Такое программное обеспечение, как eAccelerator/xCache/ZendOptimizer для PHP, mod_perl для perl, mod_python для python и др., могут кэшировать серверные скрипты в скомпилированном состоянии, существенно ускоряя загрузку нашего сайта. Кроме этого, стоит найти профилирующий инструмент для используемого языка программирования, чтобы установить, на что же тратятся ресурсы CPU. Если удастся устранить причину больших нагрузок на процессор, то страницы будут отдаваться быстрее и появится возможность выдавать больше трафика при меньшем числе машин.

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

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

Похожие главы из других книг

Глава 3. Кэширование

Глава 3. Кэширование 3.1. Expires, Cache-Control и сброс кэша Кэширование играет одну из основных ролей в быстродействии сайтов и сравнительно просто настраивается на стороне сервера. Веб-разработчики часто сталкиваются с кэшированием, ибо браузеры и проксирующие серверы, пытаясь

Илон Маск рекомендует:  Что такое код ncurses_raw

3.4. Кэширование в iPhone

3.4. Кэширование в iPhone На MacWorld’2008 Steve Jobs анонсировал, что Apple уже продала на текущий момент 4 миллиона iPhone, что составляет по 20 тысяч iPhone каждый день. В докладе Net Applications говорится, что общая доля пользователей Интернета с iPhone поднялась до 0,12% в декабре 2007 года, обогнав, в

Балансировка на сервере

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

7.7. Кэширование в JavaScript

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

Развертывание на сервере

Развертывание на сервере Для выполнения упражнений, предлагаемых в этой книге, необходимо иметь доступ к серверной части служб SharePoint 3.0, которая может быть установлена на одном или нескольких серверах. Сервер должен соответствовать следующим требованиям.1 Операционная

4. Кэширование.

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

12.14.4 Запись о сервере имен

12.14.4 Запись о сервере имен Запись о сервере имен (Name Server — NS) идентифицирует сервер для домена. Если имеются подзоны, необходимы и элементы для дочерних серверов имен подзон, чтобы сервер с более высоким уровнем мог использовать указатели на серверы низшего уровня. Записи

Кэширование

Кэширование В переводе с английского языка слово «cache» означает «тайник». Тайником в нашем случае является специальная системная папка, в которую компьютер записывает все документы, полученные из Интернета. И когда вы будете запрашивать какую-либо веб-страницу вторично,

Как зарегистрироваться на сервере

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

12.2.1. Samba на сервере

12.2.1. Samba на сервере Из п.6.3 вы узнали, как использовать пакет Samba (www.samba.org) для просмотра общих ресурсов сети Windows. В этом параграфе я объясню, как настроить сервер Samba, чтобы открыть общий доступ к ресурсам компьютера под управлением Linux.С помощью Samba вы сможете;? предоставлять

13.4.1. Настройка кэширования на DNS-сервере

13.4.1. Настройка кэширования на DNS-сервере Для того, чтобы насладиться такой возможностью, следует в блок options файла named.conf добавить следующие параметры:forward first;forwarders < 81.3.165.35; 81.3.150.2;>;Директива forwarders задает заключенный в фигурные скобки список IP-адресов DNS-серверов, которым

Память на сервере (все платформы)

Память на сервере (все платформы) Оценка памяти сервера включает множество факторов.* Работа сервера Firebird. Сервер Firebird осуществляет эффективное использование ресурсов сервера. Суперсервер (Superserver) после старта использует приблизительно 2 Мбайта памяти. Классический

ЧАСТЬ VII. Программирование на сервере.

ЧАСТЬ VII. Программирование на сервере.

7.5.4. Обработка на сервере

7.5.4. Обработка на сервере HTML-файлы могут обрабатываться прямо на сервере (так же, как выполняются файлы PHP). С одной стороны, это удобно, потому что код PHP можно будет вставлять в файлы с расширением htm, с другой стороны, HTML-файлы далеко небезопасны, и если хакер сможет их

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

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

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

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

Обзор кэширования

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

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

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

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

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

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

Обзор кэширования

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

Области применения. Кэш используется на разных технологических уровнях, включая операционные системы, сетевые уровни, в том числе сети доставки контента (CDN) и DNS, интернет-приложения и базы данных. С помощью кэширования можно значительно сократить задержку и увеличить количество операций ввода-вывода в секунду для рабочей нагрузки многих приложений с большим количеством операций чтения, таких как порталы вопросов и ответов, игры, сервисы обмена мультимедийными материалами и социальные сети. Информация в кэше может включать результаты запросов к базе данных, сложных вычислений, запросы и ответы API, а также интернет-артефакты, такие как HTML, JavaScript и файлы изображений. Рабочие нагрузки, требующие больших вычислительных мощностей для обработки наборов данных, например сервисы рекомендаций и высокопроизводительное вычислительное моделирование, тоже могут эффективно использовать уровень данных в памяти в качестве кэша. В приложениях такого рода доступ к огромным наборам данных осуществляется в реальном времени на кластерах машин, которые могут охватывать сотни узлов. Скорость работы базового оборудования, осуществляющего обработку данных в дисковом хранилище, представляет собой серьезное препятствие для таких приложений.

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

Рекомендации по кэшированию. При реализации уровня кэша необходимо принимать во внимание достоверность кэшируемых данных. Эффективный кэш обеспечивает высокую частоту попаданий, то есть наличия в кэше запрашиваемых данных. Промах кэша происходит, когда запрашиваемых данных в кэше нет. Для удаления из кэша неактуальных данных применяются такие механизмы, как TTL (время жизни). Следует также понимать, требуется ли для среды кэширования высокая доступность. Если она необходима, можно использовать сервисы в памяти, такие как Redis. В ряде случаев уровень в памяти можно использовать как отдельный уровень хранения данных, в отличие от кэширования из основного хранилища. Чтобы решить, подходит ли такой вариант, необходимо определить для данных в сервисе в памяти соответствующие значения RTO (требуемое время восстановления, то есть сколько времени требуется системе на восстановление после сбоя) и RPO (требуемая точка восстановления, то есть последняя восстанавливаемая точка или транзакция). Для соответствия большинству требований RTO и RPO можно применять характеристики и проектные стратегии разных сервисов в памяти.

Ускорение загрузки контента с веб-сайтов (для браузеров или мобильных устройств)

Уровень Клиентская часть DNS Интернет Приложение База данных
Пример использования Разрешение доменных имен в IP-адреса Ускорение загрузки контента с веб-серверов и серверов приложений. Управление веб-сессиями (на стороне сервера) Повышение производительности приложений и скорости доступа к данным Сокращение задержек, связанных с обработкой запросов к базе данных
Технологии Управление кэшированием с помощью HTTP-заголовков (браузеры) DNS-серверы Управление кэшированием с помощью HTTP-заголовков (CDN, обратные прокси-серверы, интернет-ускорители, хранилища пар «ключ-значение») Хранилища пар «ключ-значение», локальный кэш Буфер базы данных, хранилища пар «ключ-значение»
Решения В зависимости от браузера Amazon Route 53 Amazon CloudFront, ElastiCache для Redis, ElastiCache для Memcached, решения партнеров Инфраструктуры приложений, ElastiCache для Redis, ElastiCache для Memcached, решения партнеров ElastiCache для Redis, ElastiCache для Memcached

Кэширование с помощью Amazon ElastiCache

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

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

Повышение производительности приложений

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

Сокращение стоимости базы данных

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

Сокращение нагрузки на серверную часть

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

Прогнозируемая производительность

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

Устранение «горячих точек» базы данных

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

Повышение пропускной способности чтения (IOPS)

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

Кэширование на стороне сервера против кеширования на стороне клиента для поддержки сопоставления ключ-значение

У меня есть веб-приложение, написанное с extjs и php бэкенд. Бэкэнд имеет доступ к базам данных A а также B , Приложение содержит различные сетки, которые отображают много пользовательской информации; Что важно для этой проблемы, так это userID который отображается в большинстве сеток в виде отдельного столбца.

Эта проблема

По некоторым причинам userID в БД B должен быть заменен пользователем accountID , Но интерфейс все равно должен отображать пользователя userID , Что означает, что я должен иметь некоторую форму отображения между userID — accountID поддерживать ожидаемую функциональность.

Обратите внимание, что сопоставление userID -> accountID доступно в базе данных A

Потенциальные решения

Серверный кеш
Есть приблизительно 10000 пользователей. Одним из вариантов, который я рассмотрел, является серверный кэш, такой как redis чтобы сохранить это отображение. Но для этого все равно нужны результаты запроса, которые нужно проанализировать в бэкэнде, и каждый userID заменен на соответствующий accountID и отправили на передний конец. Так, например, 500 результирующих строк из запроса будет означать 500 redis звонки для получения соответствующего userID (?) Производительность может быть проблемой здесь.

Клиентский кеш
Используйте опцию хранения на стороне клиента, такую ​​как LocalStorage , LocalForage или даже простой hashmap и загрузите детали отображения из redis на передний конец. Затем, когда данные сетки отображаются, используйте эту карту для получения соответствующей userID ,

Отображение должно работать и наоборот, при отправке данных из приложения в базу данных.

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

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

Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL