Время кэширования: Что такое кэширование и как оно работает | AWS

09.04.2021 alexxlab

Содержание

Что такое кэширование и как оно работает | AWS

Узнайте о различных отраслях и примерах использования кэширования

Мобильные технологии

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

AWS Mobile Hub – это объединенная консоль для удобного поиска, настройки и использования облачных сервисов AWS, предназначенных для разработки и тестирования мобильных приложений, а также мониторинга их использования.

Интернет вещей (IoT)

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

Кроме того, если вы сохранили предпочтения пользователя устройства, то можете подобрать наиболее подходящие рекомендации для этого пользователя. В этом отдельном примере скорость ответа приложения на полученные координаты критически важна для достижения качественного взаимодействия с пользователем. Кэширование может сыграть в нем важную роль. Интересные места и их координаты можно хранить в хранилище пар «ключ – значение», например в Redis, чтобы обеспечить их быстрое получение. С точки зрения разработки вы можете запрограммировать свое приложение IoT, чтобы оно реагировало на любое событие, если для этого существуют программные средства. При создании архитектуры IoT необходимо рассмотреть некоторые очень важные вопросы, в том числе время ответа при анализе полученных данных, создание архитектуры решения, масштаб которого охватывает N устройств, и экономичность архитектуры.

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

Дополнительные сведения: Managing IoT and Time Series Data with Amazon ElastiCache for Redis

Рекламные технологии

Современные приложения в сфере рекламных технологий особо требовательны к производительности. Примером важной области развития в этой сфере является торг в режиме реального времени (RTB). Это подход к трансляции рекламы на цифровых экранах в режиме реального времени, основанный на принципе аукциона и работающий со впечатлениями на самом подробном уровне. RTB был преобладающим способом проведения транзакций в 2015 году, учитывая то, что 74,0 процента рекламы было куплено программными средствами, что в США соответствует 11 миллиардам долларов (согласно eMarketer Analysis). При создании приложения для торгов в режиме реального времени важно учитывать то, что одна миллисекунда может решать, было ли предложение предоставлено вовремя, или оно уже стало ненужным.

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

Игровые технологии

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

Подробнее о разработке игр см. здесь.

Мультимедиа

Мультимедийным компаниям часто требуется передавать клиентам большое количество статического контента при постоянном изменении количества читателей или зрителей. Примером является сервис потоковой передачи видео, например Netflix или Amazon Video, которые передают пользователям большой объем видеоконтента. Это идеальный случай для использования сети доставки контента, в которой данные хранятся на серверах кэширования, расположенных во всем мире. Еще одним аспектом медиаприложений является пикообразная и непредсказуемая нагрузка. Возьмем, к примеру, публикацию в блоге на веб-сайте, о которой некоторая знаменитость только что отправила сообщение в Twitter, или веб-сайт футбольной команды во время Суперкубка. Такой высокий пик спроса на маленькое подмножество контента – вызов для многих баз данных, потому их пропускная способность для отдельных ключей ограничена.

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

Интернет-коммерция

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

Социальные сети

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

Здравоохранение и здоровый образ жизни

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

Подробнее о создании приложений для сферы здравоохранения на AWS см. здесь.

Финансы и финансовые технологии

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

Подробнее о финансовых приложениях на AWS см. здесь.

Что такое кэширование?—Документация | ArcGIS Enterprise

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

Что происходит во время процесса кэширования?

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

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

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

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

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

Можно ли кэшировать все карты?

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

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

Насколько актуальной должна быть моя карта?

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

Насколько велик кэш и насколько широко распространены изменения данных?

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

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

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

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

Будут ли исходные ГИС-данные доступны после создания пакета листов?

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

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

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

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

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

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

Закладка Кэширование

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

Эта закладка доступна в окне Каталог в ArcMap при публикации сервиса или при отображении свойств сервиса.

Рекомендации по использованию закладки Кэширование находятся в разделе Доступные свойства кэша карты.

Инструмент Создать схему листов кэша картографического сервиса

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

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

Инструмент Управление листами кэша картографического сервера

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

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

Директория кэша

Директория кэша ArcGIS Server – это папка на диске, в которой хранятся листы кэша.

Можно открыть директорию кэша для проверки листов кэша и файла схемы листов conf.xml. Директория кэша также может содержать статус файловой базы геоданных.gdb, который содержит информацию о том, какие листы были построены.

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

Более подробно о директории кэша сервера см. Доступные свойства кэша карты.

Отзыв по этому разделу?

клиентский, сетевой, серверный и уровень приложения

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

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

клиентский;
сетевой;
серверный;
уровень приложения.

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

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

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

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

Ответ также может включать заголовок Last-Modified или Etag. Эти заголовки нужны для проверки возможности повторного использования данных. Статус ответа 304 указывает, что содержимое не изменилось и повторная загрузка не требуется. Обратите внимание на парные заголовки Last-Modified и If-Modified-Since, а также на даты ниже:

Ответ с заголовком «Last-Modified» и последующим запросом с его использованием.

Заголовок Etag используется с If-None-Match аналогичным образом для обмена кодами ответа при определении изменений в контенте, если они имеются.

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

Кэш на сетевом уровне

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

Директива HTTP-заголовка Cache-control: public позволяет различным частям сети кэшировать ответ. С помощью заголовка Cache-Control: public, max-age=31536000 находят ресурсы, которые хранятся в течение одного года.

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

Кэш на серверном уровне

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

Первый подход к более быстрым ответам и экономии ресурсов — настройка кэш-сервера между приложением и клиентом.

Клиенты, запрашивающие одно и то же содержимое на прокси-сервере.

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

proxy_cache_path /path/to/cache keys_zone=my_cache:10m;

server {
  location / {
    proxy_cache my_cache;
    proxy_pass http://aplication;
  }
}

Существует ещё одна директива, которая называется proxy_cache_lock, которая позволяет прокси-серверу делегировать только первый из похожих клиентских запросов за один раз для приложения. Если директива установлена, клиенты будут получать ответ при возврате первого запроса.

Множество клиентов, запрашивающих одно и то же содержимое одновременно.

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

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

В руководстве по кэшированию с NGINX и NGINX Plus содержится более подробная информация и параметры конфигурации.

Кэш на уровне приложения

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

Мемоизация

def price
  @price ||= Price.new(unit_price, category)
end

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

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

Интеллектуальное кэширование в памяти

cache.fetch("category-tax-#{category_id}", expires_in: 1.minute) do
  CategoryTax.new(category_id)
end

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

Многие библиотеки предоставляют этот шаблон, но память приложения — не бесконечный ресурс. Например, менеджер кэша для Node не управляет объёмом потребляемой памяти. Также это может стать проблемой, если ваше приложение кэширует данные в больших объёмах, потребляя всю доступную память.

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

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

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

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

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

Ещё один важный аспект при использовании хранилищ кэша — это состояние гонки, которое происходит, когда разные экземпляры приложения обращаются к некэшированным данным одновременно. API кэширования запросов Rails содержит свойство race_condition_ttl для минимизации этого эффекта.

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

Заключение

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

Не смешно? А здесь смешно: @ithumor

Перевод статьи «Client, Network, Server and Application Caching on the Web»

Highload.today — медиа для разработчиков

Софт — 2 часа назад

Как автоматизировать копирование файлов

На многих проектах есть необходимость копирования огромных файлов — размером 0,5 Гб и более. Например, это может понадобиться для получения последней версии сборки разрабатываемого продукта. В процессе копирования могут возникать сбои или обрывы коннекта, и тогда копирование приходится начинать снова. Хочу поделиться с вами простым скриптом для Windows, который поможет автоматизировать этот процесс, сделать его проще, быстрее и надежнее.

Тестирование — 1 день назад Editorial

Тестирование фронтенда на примере React-приложения

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

Фронтенд — 6 дней назад Editorial

NPM CLI v7 — пять самых важных фич

В феврале 2021 года стал широко доступен апдейт NPM CLI до версии 7. Это одно из важнейших обновлений, в котором был представлен новый функционал и другие важные настройки, упрощающие процесс управления пакетами. Команда разработчиков смогла решить некоторые из распространенных проблем, с которыми сталкивались пользователи. Подробным обзором пяти новых возможностей NPM CLI v.7 поделился разработчик Сахан Амарша (Sahan Amarsha) в материале для Bits and Pieces. Ну а мы в свою очередь спешим поделиться его выводами с вами.

Фронтенд — 6 дней назад Editorial

Tailwind CSS: за и против

По данным опроса The State of CSS 2020, больше всего разработчиков в мире, использующих CSS-фреймворки, сейчас заинтересованы в изучении и применении Tailwind CSS. Он опережает конкурентов в этом рейтинге уже второй год подряд. Команда Tailwind предлагает альтернативный подход для поддержки и стилизации HTML-разметки, но у него есть и свои противники. Проштудировав статьи и комментарии на таких ресурсах, как Dev.to, Product Hunt и Codeburst, мы собрали наиболее популярные доводы за и против использования этого фреймворка.

Софт — 1 неделя назад Editorial

На каком ПО летают на Марсе?

18 февраля состоялось историческое событие, НАСА успешно посадила ровер Perseverance (в переводе на русский — “Настойчивость”) на Марс. Казалось бы, ничего необычного? НАСА проделывала это уже не раз в поиске ответа на вечный вопрос: есть ли жизнь на Марсе?

Мобильные приложения — 1 неделя назад Editorial

Как сделать из веб-сайта веб-приложение (а главное — зачем?)

В своем блоге индийский разработчик Шашват Верма (Shashwat Verma) рассказал, как преобразовать веб-сайт или веб-страницу в прогрессивное веб-приложение (PWA). В качестве примера программист создал PWA из простой классической игры Simon на основе HTML5 (вот ее гитхаб-репозиторий), которую после преобразования можно устанавливать в формате веб-приложения на устройства Android и iOS.

Кэширование — Документация Flask (русский перевод) 0.10.1

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

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

Настройка кэша

Объект кэша создаётся единожды и продолжает работать примерно так же, как это происходит с объектами Flask. Если речь идёт о сервере разработки, то можно создать объект SimpleCache, который представляет собой простейший кэш, хранящий элементы в памяти интерпретатора Python:

from werkzeug.contrib.cache import SimpleCache
cache = SimpleCache()

Для использования memcached нужно установить один из поддерживаемых модулей memcache (его можно взять на PyPI) и запустить где-нибудь сервер memcached. Теперь можно подключиться к серверу memcached:

from werkzeug.contrib.cache import MemcachedCache
cache = MemcachedCache(['127.0.0.1:11211'])

Если вы пользуетесь App Engine, можно легко подключиться к серверу memcache из App Engine:

from werkzeug.contrib.cache import GAEMemcachedCache
cache = GAEMemcachedCache()

Использование кэша

Как теперь воспользоваться этим кэшем? Имеется две очень важные операции: get() и set(). Вот как их использовать:

Чтобы получить элемент из кэша, вызовите get(), указав ей ключ — имя элемента. Если что-нибудь есть в кэше, оно будет возвращено. В противном случае функция вернёт None:

rv = cache.get('my-item')

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

Вот полный пример того, как это обычно выглядит:

def get_my_item():
    rv = cache.get('my-item')
    if rv is None:
        rv = calculate_value()
        cache.set('my-item', rv, timeout=5 * 60)
    return rv

Руководство по HTTP. Кэширование. – PROSELYTE

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

Главная цель кэширования в HTTP/1.1 – оценить необходимость отправки запроса и оценить необходимость отправки полного ответа во многих случаях.

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

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

Пример:


Cache-control: no-cache

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

№	Команда кэширования запроса и описание
1	no-cache Кэш не должен использовать ответ для удовлетворения запроса без успешной повторной валидации начальным сервером.
2	no-store Кэш не должен хранить какую-либо информацию о запросе клиенте или ответе сервера.
3	max-age = seconds Указывает максимальный возраст ответа (в секундах), который клиент может принимать.
4	max-stale [= seconds] Указывает, что клиент принимает ответы, которые превысили время истечения. Если секунды указаны, то ответ не должен превышать время, указанное в секундах.
5	min-fresh = seconds Указывает, что клиент должен принимать ответы, время обновления которых не менее текущего возраста, плюс время, указанное в секундах.
6	no-transform Не преобразует тело сущности.
7	only-if-cached Не принимает новые данные. Кэш может отправлять документ только в том случае, если он уже кэширован и не должен устанавливать связь с сервером для получения более новых существующих копий.

В HTTP ответах сервер может использовать команды, которые указаны ниже:

№	Команда кэширования ответа и описание
1	public Ответ может быть кэширован любым кэшом.
2	private Всё сообщение или его часть предназначены только для одного пользователя и не должны кэшироваться общими кэшами.
3	no-cache Кэш не должен использовать ответ для удовлетворения соответствующего запроса без успешной повторной валидации начальным сервером.
4	no-store Кэш не должен хранить информацию о запросе клиента или ответе сервера.
5	no-transform Не преобразует тело сущности
6	must-revalidate Кэш должен проверить статус валидности документа перед его использованием. Документы, время валидности которых истекло не должны использоваться.
7	proxy-revalidate То же самое, что и must-revalidate, за исключением того, что не общие кэши агентов пользователей, не разрешены.
8	max-age = seconds Указывает максимальный возраст ответа (в секундах), который может быть принят клиентом.
9	s-maxage = seconds Переопределяет команду максимальный возраст, определённый командой max-age или заголовком Expires. Данная директива всегда игнорируется приватным кэшом.

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

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

Для настройки кэширования перейдем в раздел «Файлы → Диспетчер файлов»

Перейдем в папку «public_html».

По умолчанию файл «.htaccess» скрыт. Поэтому нажмем на кнопку «Настройки» и поставим галочку возле «Показать скрытые файлы (dotfiles)».

Далее выберем наш .htaccess и нажмем кнопку «Редактировать».

В появившемся окне нажмем кнопку «Отключить проверку кодировки» и кнопку «Edit».

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

<FilesMatch ".(flv|gif|jpg|jpeg|png|ico|swf|js|css|pdf)$">  
Header set Cache-Control "max-age=2592000"  
</FilesMatch>

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

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

<FilesMatch ".(pl|php|cgi|spl|scgi|fcgi)$">  
Header unset Cache-Control  
</FilesMatch>

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

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

Ниже представлен простой пример использования модуля expires в файле .htaccess:

<IfModule mod_expires.c>  
ExpiresActive On  
ExpiresDefault "access plus 1 month"  

ExpiresByType image/gif "access plus 2 months"  
ExpiresByType image/jpeg "access plus 2 months"  
</IfModule>

В этом примере мы включаем модуль, устанавливаем кэширование по умолчанию на 1 месяц, а далее назначаем для файлов с расширением gif и jpg время хранения в кэше plus 2 months. Время можно указать в годах, месяцах, неделях, днях, часах, минутах, секундах. В том числе можно использовать вариант вида:

ExpiresByType text/html "access plus 1 month 15 days 2 hours"  
ExpiresByType image/gif "modification plus 5 hours 3 minutes"

В качестве типов файлов можно указывать различные MIME types, вот некоторые из них в качестве примера:

image/x-icon  
image/jpeg  
image/png  
image/gif  
application/x-shockwave-flash  
text/css  
text/javascript  
application/javascript  
application/x-javascript  
text/html  
application/xhtml+xml

Веб-кэширование

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

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

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

Другая форма веб-кэширования на стороне сервера включает использование хранилищ ключей / значений, таких как Memcached и Redis. В отличие от обратных прокси-серверов, которые используются для простого кеширования HTTP-ответа на данный HTTP-запрос.Хранилище объектов типа «ключ-значение» может использоваться для кэширования любого веб-контента, необходимого разработчику приложения. Веб-контент обычно извлекается с помощью кода приложения или использования инфраструктуры приложения, которая может использовать хранилище данных в памяти. Еще одно преимущество использования хранилищ ключей / значений для веб-кеширования заключается в том, что они также обычно используются для хранения веб-сеансов и другого кэшированного контента. Это обеспечивает единое решение для различных вариантов использования. Чтобы узнать больше о магазинах «ключ-значение», предлагаемых в Amazon, посетите Amazon ElastiCache.

Другие формы веб-кэширования могут быть реализованы в сетевых компонентах и с поставщиками услуг Интернета.

Сколько времени жить (TTL) | Лучшие практики TTL | Руководство CDN

Сколько времени жить

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

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

Как сети CDN упрощают конфигурацию «Время жизни»

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

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

Использование CDN упрощает процесс, предоставляя удобный метод обновления настроек TTL с панели управления. Это позволяет вам изменять настройки для отдельных ресурсов или целых групп файлов без необходимости вручную возиться с их заголовками HTTP.

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

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

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

HTTP-кеширование | Основы Интернета | Разработчики Google

Дэйв — технический писатель

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

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

Хотя кеширование HTTP стандартизовано в соответствии с Спецификации Internet Engineering Task Force (IETF), браузеры могут иметь несколько кешей, которые различаются по способу получения, хранения и сохранения содержимого.Вы можете прочитать о том, чем отличаются эти кеши, в этой отличной статье, Повесть о четырех тайниках.

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

Включение кэширования

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

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

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

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

Кэш-контроль

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

  
 Заголовочный набор Cache-Control "max-age = 2592000, общедоступный"

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

  
 Заголовочный набор Cache-Control "max-age = 86400, общедоступный"

Cache-control имеет ряд параметров, часто называемых директивами , которые могут быть установлены на конкретно определить, как обрабатываются запросы кеша. Некоторые общие директивы: объяснено ниже; вы можете найти дополнительную информацию на В разделе Оптимизация производительности и в Сеть разработчиков Mozilla.

no-cache : несколько неверно, указывает, что контент можно кэшировать, но если да, его необходимо повторно проверять при каждом запросе перед тем, как передать его клиенту.Это заставляет клиент проверяет актуальность, но позволяет избежать повторной загрузки ресурса, если он не изменилось. Взаимоисключающий с no-store .
no-store : указывает, что содержимое фактически не может быть кэшировано никаким первичный или промежуточный кеш. Это хороший вариант для ресурсов, которые могут содержать конфиденциальные данные или ресурсы, которые почти наверняка будут меняться от посещения к посещению. Взаимно эксклюзивно с без кеширования .
общедоступный : указывает, что контент может быть кэширован браузером и любым промежуточным тайники. Переопределяет значение по умолчанию private для запросов, использующих HTTP-аутентификацию. Взаимоисключающий с , частный .
частный : обозначает контент, который может храниться в браузере пользователя, но не может быть кэшируется любыми промежуточными кешами. Часто используется для конкретных пользователей, но не особенно конфиденциальные данные.Взаимоисключающий с публичный .
max-age : определяет максимальное время, в течение которого контент может быть кэширован, прежде чем он должен быть перепроверена или повторно загружена с исходного сервера. Эта опция обычно заменяет истекает заголовок (см. ниже) и принимает значение в секундах с максимальным допустимым возрастом один год (31536000 секунд).

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

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

Вот пример того, как вы можете настроить кэширование в файле .htaccess на сервере Apache.

  ## СРОК КЭШИНГА ##
ExpiresActive On
ExpiresByType image / jpg «доступ плюс 1 год»
ExpiresByType image / jpeg "доступ плюс 1 год"
ExpiresByType image / gif "доступ плюс 1 год"
ExpiresByType image / png "доступ плюс 1 год"
ExpiresByType text / css "доступ плюс 1 месяц"
Приложение ExpiresByType / pdf "доступ плюс 1 месяц"
ExpiresByType text / x-javascript "доступ плюс 1 месяц"
Приложение ExpiresByType / x-shockwave-flash "доступ плюс 1 месяц"
ExpiresByType изображение / значок x "доступ плюс 1 год"
ExpiresDefault "доступ плюс 2 дня"
## СРОК КЭШИНГА ##

(источник: GTmetrix)

Как видите, в этом примере разные типы файлов имеют разные даты истечения срока годности: images не истекают в течение года после доступа / кеширования, в то время как скрипты, PDF-файлы и стили CSS истекают через в месяц, а любой тип файла, не указанный явно, истекает через два дня.Сроки хранения на ваше усмотрение, и их следует выбирать в зависимости от типов файлов и частоты их обновления. За Например, если вы регулярно меняете свой CSS, вы можете захотеть использовать более короткий срок действия или даже вообще нет, и пусть по умолчанию используется двухдневный минимум. И наоборот, если вы сделаете ссылку на какой-то статические формы PDF, которые почти никогда не меняются, вы можете использовать для них более длительный срок действия.

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

Сводка

Кэширование

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

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

Обратная связь

Была ли эта страница полезной?

Есть

Что было самым лучшим на этой странице?

Это помогло мне выполнить мои цели

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

Там была информация, которая мне была нужна

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

Имеет точную информацию

Легко читалось

Что-то еще

№

Что было самым плохим на этой странице?

Это не помогло мне выполнить мои цели

Отсутствовала необходимая мне информация

Он имел неточную информацию

Было трудно прочитать

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

Что-то еще

Повышение производительности приложений с помощью заголовков кэша HTTP

Последнее обновление 27 мая 2020 г.

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

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

Обзор

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

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

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

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

Имеется два основных заголовка кеша: Cache-Control и Expires .

Кэш-контроль

Без набора заголовков cache-control никакие другие заголовки кэширования не дадут никаких результатов.

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

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

  Cache-Control: общедоступный

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

  Cache-Control: частный

Значение заголовка Cache-Control является составным, указывающим, является ли ресурс общедоступным или частным, а также указывается максимальное количество времени, в течение которого он может быть кэширован, прежде чем он будет считаться устаревшим.Значение max-age устанавливает интервал времени для кэширования ресурса (в секундах).

  Cache-Control: общедоступный, max-age = 31536000

В то время как заголовок Cache-Control включает кэширование на стороне клиента и устанавливает max-age ресурса, заголовок Expires используется для указания определенного момента времени, когда ресурс больше не действителен.

Срок действия истекает

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

Если оба Expires и max-age установлены, приоритет будет иметь max-age .

  Cache-Control: общедоступный
Истекает: Mon, 25 Jun 2012 21:31:12 GMT

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

Условные запросы

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

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

По времени

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

Чтобы включить условные запросы, приложение указывает время последнего изменения ресурса через заголовок ответа Last-Modified .

  Cache-Control: общедоступный, max-age = 31536000
Последнее изменение: пн, 3 января 2011 г., 17:45:57 GMT

В следующий раз, когда браузер запросит этот ресурс, он запросит содержимое ресурса только в том случае, если оно не изменилось с этой даты, используя If-Modified-Since request header

  If-Modified-Since: 3 января 2011 г., понедельник, 17:45:57 GMT

Если ресурс не менялся с понедельника , 3 января 2011 г., 17:45:57 GMT , сервер вернется с пустым телом с кодом ответа 304 .

На основе содержимого

ETag (или Entity Tag) работает аналогично заголовку Last-Modified , за исключением того, что его значение представляет собой дайджест содержимого ресурсов (например, хэш MD5). Это позволяет серверу определять, отличается ли кэшированное содержимое ресурса от самой последней версии.

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

  Cache-Control: общедоступный, max-age = 31536000
ETag: "15f0fff99ed5aae4edffdd6496d7131f"

При последующих запросах браузера отправляется If-None-Match request Заголовок со значением ETag последней запрошенной версии ресурса.

  Если-None-Match: "15f0fff99ed5aae4edffdd6496d7131f"

Как и в случае заголовка If-Modified-Since , если текущая версия имеет то же значение ETag, что указывает на то, что ее значение совпадает с кэшированной копией браузера, то возвращается статус HTTP 304.

Видимость

Большинство современных браузеров включают надежные инструменты визуализации запросов / ответов и самоанализа. Веб-инспектор, доступный как в Chrome, так и в Safari, показывает заголовки ответа и запроса на вкладке Network .

Первоначальный запрос к http://http-caching-demo.herokuapp.com/ показывает набор заголовков по умолчанию, возвращаемых приложением (без директив кеширования).

Добавив параметр запроса cached , http://http-caching-demo.herokuapp.com/?cache=true, приложение включает кэширование с заголовками Cache-Control и Expires (оба из которых установлены на 30 секунд в будущем).

Добавление в запрос параметра etag http: // http-caching-demo.herokuapp.com/?etag=true, заставляет пример приложения указывать дайджест ETag содержимого JSON.

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

Однако при последующих запросах вы можете увидеть, как сервер отвечает на проверку ETag браузеров с HTTP-статусом 304 (не изменен), что заставляет браузер использовать свою собственную кэшированную копию:

Примеры использования

Статические активы

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

В этих случаях вы должны установить заголовок Cache-Control со значением max-age, равным году в будущем с момента запроса. Рекомендуется установить для Expires аналогичное значение.

1 год — 31536000 секунд

  Cache-Control: общедоступный; макс-возраст = 31536000
Истекает: Mon, 25 Jun 2013 21:31:12 GMT

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

Динамический контент

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

Частное содержание

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

Если кэширование конечного клиента все еще желательно, вы можете запросить кэширование ресурсов только в частном порядке (т.е.e только в кеше браузера конечного пользователя):

  Cache-Control: частный, max-age = 31536000

Предотвращение кеширования

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

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

Требуются оба значения, поскольку IE использует без кеширования , а Firefox использует без хранения .

  Cache-Control: без кеширования, без хранения

Реализация

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

Временные антипаттерны для кэширования данных временных рядов

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

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

Как запросить срезы времени?

Рассмотрим следующую схему таблицы

Это классическая и простая модель для всего, что связано с IoT и / или таймсериями: существует UUID, связанный с некоторым компонентом системы (датчик, биржевой тикер и т. Д.), И мы хотим отслеживать события. это происходит в определенный период времени.

Один из наиболее распространенных шаблонов — запрос событий с определенного момента в прошлом до текущего времени. Есть два способа указать такой запрос:

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

Тайник Сциллы

Кэш Scylla может отслеживать два типа объектов:

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

Строки всегда являются отдельными записями: кэш либо знает значение, связанное с ключом, либо не знает.Однако отрицательные записи могут быть единичными или диапазонными. Это нетрудно понять: мы можем знать, что ключа «5» не существует, но мы можем так же легко знать, что «ничего не существует между 5 и 50»

На рисунке 1 показаны два кэшированных раздела. Первый раздел состоит из трех рядов. Мы знаем значение строки 1 и знаем, что строки 2 не существует. Но мы ничего не знаем о строке 3. Во втором разделе нам известно значение строки 1, и мы также знаем, что ничего не существует между строками со 2 по 10.

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

База данных возвращает запрос, как и ожидалось, и данные трассировки расскажут нам, как Scylla выполнил это:

Как видно из трассировки выше, в какой-то момент нам нужно войти в систему хранения, чтобы прочитать желаемый ключ из определенного файла (в данном случае mc-6-big-Data.дб). Но что произойдет, если мы снова попробуем тот же запрос? Как и ожидалось, этой строки больше нет, что указывает на то, что Scylla удалось кэшировать эту запись.

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

И повторяя тот же запрос:

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

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

На рисунке 2 показано состояние кэша после выполнения поиска.

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

Антипаттерн

Теперь, когда мы понимаем, как работает кеш, должно быть тривиально понять, почему два запроса, которые мы анализируем, ведут себя так по-разному. Рассмотрим первый запрос и для примера предположим, что «сейчас» — это «2019-08-22 01:00:00»

После того, как этот запрос будет выполнен, Scylla будет кэшировать все, что ему известно (пока оно помещается в кеш) о данных между точками ‘2019-08-22 00:00:00’ и ‘2019-08-22 01 : 00: 00 ‘.Если в этом интервале есть строки, Scylla сохранит эти строки, а если есть пробелы, Scylla сохранит тот факт, что эти пробелы пусты. Но что произойдет, если тот же запрос будет отправлен на час позже, когда «сейчас» будет «2019-08-22 02:00:00»? Сцилла не может знать, какие данные существуют между 01:00:00 и 02:00:00, и должен прочитать их из хранилища! Это происходит независимо от того, вставлена ли новая строка в интервал, поэтому Scylla будет вынуждена проверить. Подтверждают ли это следы CQL? Посмотрим, что они делают:

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

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

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

Заключение

Запросы данных по временным диапазонам — это стабильные данные, подобные временным рядам, что является обычным вариантом использования Scylla. Часто приложениям требуется запросить открытый диапазон от фиксированного времени в прошлом до «настоящего». В этой статье мы рассмотрели два способа выполнения таких запросов: один — всегда явно указывать текущее время, а другой — использовать открытый диапазон, определяющий только начало интервала.Мы обсудили, как эти два, казалось бы, похожих подхода приведут к совершенно разным шаблонам доступа в кеш-памяти Scylla, и продемонстрировали, что использование открытых диапазонов даст превосходные результаты.

Чтобы узнать больше о Scylla Cache и о том, как он работает, ознакомьтесь с этой статьей Томаша Грабца.

Кэширование

просмотров — документация по продукту Acquia

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

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

Настройка кеширования представлений

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

Чтобы настроить кеширование для представления, выполните следующие действия:

Войдите на свой веб-сайт и перейдите в раздел Структура> Представления (Drupal 7 и 8).
Найдите представление, которое вы хотите настроить, и щелкните его ссылку Изменить .
В разделе Расширенные настройки щелкните Нет рядом с Кэширование .
Выберите На основе времени , что дает вам возможность кэшировать запрос результаты или визуализированный вывод.
Щелкните Применить , чтобы сохранить новое значение кэширования.
Щелкните Сохранить , чтобы сохранить изменения в вашем представлении.

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

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

Дополнительная информация о кешировании

Для получения дополнительной информации о кэшировании на вашем веб-сайте Drupal см. Обзор кеширования.

документов NGINX | Кэширование содержимого NGINX

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

Обзор

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

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

Включение кеширования ответов

Чтобы включить кэширование, включите директиву proxy_cache_path в контекст верхнего уровня http {} . Обязательный первый параметр — это путь локальной файловой системы для кэшированного содержимого, а обязательный параметр keys_zone определяет имя и размер зоны общей памяти, которая используется для хранения метаданных о кэшированных элементах:

 http {
    ...
    proxy_cache_path / data / nginx / cache keys_zone = one: 10m;
}

Затем включите директиву proxy_cache в контекст (тип протокола, виртуальный сервер или местоположение), для которого вы хотите кэшировать ответы сервера, указав имя зоны, определяемое параметром keys_zone , в директиве proxy_cache_path (в этом корпус, один ):

 http {
    ...
    proxy_cache_path / data / nginx / cache keys_zone = one: 10m;
    server {
        proxy_cache mycache;
        место расположения / {
            proxy_pass http: // localhost: 8000;
        }
    }
}

Обратите внимание, что размер, определенный параметром keys_zone , не ограничивает общий объем кэшированных данных ответа.Сами кешированные ответы хранятся с копией метаданных в определенных файлах файловой системы. Чтобы ограничить объем кэшированных данных ответа, включите параметр max_size в директиву proxy_cache_path . (Но обратите внимание, что объем кэшированных данных может временно превышать этот предел, как описано в следующем разделе.)

Процессы NGINX, участвующие в кэшировании

В кэшировании участвуют два дополнительных процесса NGINX:

Диспетчер кеша , периодически активируется для проверки состояния кеша.Если размер кэша превышает предел, установленный параметром max_size для директивы proxy_cache_path , диспетчер кеша удаляет данные, к которым осуществлялся последний доступ. Как упоминалось ранее, объем кэшированных данных может временно превышать лимит в течение времени между активациями диспетчера кеша.
Загрузчик кеша запускается только один раз, сразу после запуска NGINX. Он загружает метаданные о ранее кэшированных данных в зону общей памяти. Одновременная загрузка всего кеша может потреблять достаточно ресурсов, чтобы снизить производительность NGINX в течение первых нескольких минут после запуска.Чтобы этого избежать, настройте итеративную загрузку кеша, включив в директиву proxy_cache_path следующие параметры:
- loader_threshold — Продолжительность итерации в миллисекундах (по умолчанию 200 )
- loader_files — Максимальное количество элементов, загружаемых за одну итерацию (по умолчанию 100 )
- loader_sleeps — Задержка между итерациями в миллисекундах (по умолчанию 50 )

В следующем примере итерации длятся 300 миллисекунд или до тех пор, пока не будет загружено 200 элементов:

 proxy_cache_path / data / nginx / cache keys_zone = one: 10m loader_threshold = 300 loader_files = 200;

Указание запросов к кэшированию

По умолчанию NGINX Plus кэширует все ответы на запросы, сделанные с помощью методов HTTP GET и HEAD при первом получении таких ответов от прокси-сервера.В качестве ключа (идентификатора) запроса NGINX Plus использует строку запроса. Если запрос имеет тот же ключ, что и кэшированный ответ, NGINX Plus отправляет кэшированный ответ клиенту. Вы можете включить различные директивы в контекст http {} , server {} или location {} для управления тем, какие ответы кэшируются.

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

 proxy_cache_key "$ host $ request_uri $ cookie_user";

Чтобы определить минимальное количество раз, которое должен быть выполнен запрос с тем же ключом, прежде чем ответ будет кэширован, включите директиву proxy_cache_min_uses :

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

 proxy_cache_methods ПОЛУЧИТЬ ЗАПИСЬ ГОЛОВКИ;

Ограничение или отключение кеширования

По умолчанию ответы остаются в кэше на неопределенный срок.Они удаляются только тогда, когда размер кэша превышает максимальный настроенный размер, а затем в порядке времени с момента последнего запроса. Вы можете указать, как долго кэшированные ответы будут считаться действительными или даже будут ли они использоваться вообще, включив директивы в http {} , server {} или location {} context:

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

 proxy_cache_valid 200 302 10м;
proxy_cache_valid 404 1 мес .;

В этом примере ответы с кодом 200 или 302 считаются действительными в течение 10 минут, а ответы с кодом 404 действительны в течение 1 минуты.Чтобы определить срок действия ответов со всеми кодами состояния, укажите любой в качестве первого параметра:

 proxy_cache_valid любые 5м;

Чтобы определить условия, при которых NGINX Plus не отправляет кэшированные ответы клиентам, включите директиву proxy_cache_bypass . Каждый параметр определяет условие и состоит из ряда переменных. Если хотя бы один параметр не пуст и не равен «0» (нулю), NGINX Plus не ищет ответ в кэше, а вместо этого немедленно пересылает запрос на внутренний сервер.

 proxy_cache_bypass $ cookie_nocache $ arg_nocache $ arg_comment;

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

 proxy_no_cache $ http_pragma $ http_authorization;

Удаление содержимого из кеша

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

Настройка очистки кэша

Давайте настроим конфигурацию, которая идентифицирует запросы, использующие метод HTTP PURGE , и удаляет совпадающие URL-адреса.

В контексте http {} создайте новую переменную, например $ purge_method , которая зависит от переменной $ request_method :
```
 http {
    ...
    map $ request_method $ purge_method {
        ПРОДУВКА 1;
        по умолчанию 0;
    }
}
 
```
В блоке расположения {} , где настроено кэширование, включите директиву proxy_cache_purge , чтобы указать условие для запросов на очистку кеша. В нашем примере это $ purge_method , настроенный на предыдущем шаге:
```
 сервер {
    слушать 80;
    имя_сервера www.example.com;

    место расположения / {
        proxy_pass https: // localhost: 8002;
        proxy_cache mycache;

        proxy_cache_purge $ purge_method;
    }
}
 
```

Отправка команды очистки

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

 $ curl -X PURGE -D - "https://www.example.com/*"
HTTP / 1.1 204 Нет содержимого
Сервер: nginx / 1.15.0
Дата: сб, 19 мая 2018 г. 16:33:04 GMT
Подключение: keep-alive

В этом примере очищаются ресурсы, которые имеют общую часть URL (указанную подстановочным знаком звездочки). Однако такие записи кэша не удаляются полностью из кеша: они остаются на диске до тех пор, пока не будут удалены либо из-за неактивности (как определено параметром inactive в директиве proxy_cache_path ), либо из-за очистки кеша (включено с purger на proxy_cache_path ), или клиент пытается получить к ним доступ.

Ограничение доступа к команде очистки

Мы рекомендуем ограничить количество IP-адресов, с которых разрешено отправлять запросы на очистку кеша:

 geo $ purge_allowed {
   по умолчанию 0; # запретить другим
   10.0.0.1 1; # разрешить с localhost
   192.168.0.0/24 1; # разрешить с 10.0.0.0/24
}

map $ request_method $ purge_method {
   ОЧИСТКА $ purge_allowed;
   по умолчанию 0;
}

В этом примере NGINX проверяет, используется ли метод PURGE в запросе, и, если да, анализирует IP-адрес клиента.Если IP-адрес внесен в белый список, то для $ purge_method устанавливается значение $ purge_allowed : 1 разрешает очистку, а 0 запрещает.

Полное удаление файлов из кеша

Чтобы полностью удалить файлы кэша, соответствующие звездочке, активируйте специальный процесс очистки кеша , который постоянно перебирает все записи кэша и удаляет записи, соответствующие подстановочному ключу. Включите параметр purger в директиву proxy_cache_path в контексте http {} :

 proxy_cache_path / data / nginx / cache levels = 1: 2 keys_zone = mycache: 10m purger = on;

Пример конфигурации очистки кэша

 http {
    ...
    proxy_cache_path / data / nginx / cache levels = 1: 2 keys_zone = mycache: 10m purger = on;

    map $ request_method $ purge_method {
        ПРОДУВКА 1;
        по умолчанию 0;
    }

    server {
        слушать 80;
        имя_сервера www.example.com;

        место расположения / {
            proxy_pass https: // localhost: 8002;
            proxy_cache mycache;
            proxy_cache_purge $ purge_method;
        }
    }

    geo $ purge_allowed {
       по умолчанию 0;
       10.0.0.1 1;
       192.168.0.0 / 24 1;
    }

    map $ request_method $ purge_method {
       ОЧИСТКА $ purge_allowed;
       по умолчанию 0;
    }
}

Кэширование диапазона байтов

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

NGINX позволяет кэшировать такие запросы диапазона и постепенно заполнять кеш модулем Cache Slice, который разделяет файлы на более мелкие «фрагменты».Каждый запрос диапазона выбирает определенные фрагменты, которые покрывают запрошенный диапазон, и, если этот диапазон все еще не кэширован, помещает его в кеш. Все остальные запросы для этих срезов берут данные из кеша.

Для включения кэширования диапазона байтов:

Убедитесь, что NGINX скомпилирован с модулем Cache Slice.
Укажите размер среза с помощью директивы slice :

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

Включить переменную $ slice_range в ключ кеша:
```
 proxy_cache_key $ uri $ is_args $ args $ slice_range;
 
```
Включить кеширование ответов с кодом состояния 206 :
```
 proxy_cache_valid 200 206 1 ч;
 
```
Включите передачу запросов диапазона на прокси-сервер, установив переменную $ slice_range в поле заголовка Range :
```
 proxy_set_header Диапазон $ slice_range;
 
```

Вот полная конфигурация:

 место / {
    ломтик 1м;
    proxy_cache cache;
    proxy_cache_key $ uri $ is_args $ args $ slice_range;
    proxy_set_header Диапазон $ slice_range;
    proxy_cache_valid 200 206 1 ч;
    proxy_pass http: // localhost: 8000;
}

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

Время кэширования: Что такое кэширование и как оно работает | AWS

Что такое кэширование и как оно работает | AWS

Мобильные технологии

Интернет вещей (IoT)

Рекламные технологии

Игровые технологии

Мультимедиа

Интернет-коммерция

Социальные сети

Здравоохранение и здоровый образ жизни

Финансы и финансовые технологии

Что такое кэширование?—Документация | ArcGIS Enterprise

Что происходит во время процесса кэширования?

Можно ли кэшировать все карты?

Насколько актуальной должна быть моя карта?

Насколько велик кэш и насколько широко распространены изменения данных?

Будут ли исходные ГИС-данные доступны после создания пакета листов?

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

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

Закладка Кэширование

Инструмент Создать схему листов кэша картографического сервиса

Инструмент Управление листами кэша картографического сервера

Директория кэша

клиентский, сетевой, серверный и уровень приложения

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

Кэш на сетевом уровне

Кэш на серверном уровне

Кэш на уровне приложения

Мемоизация

Интеллектуальное кэширование в памяти

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

Заключение

Highload.today — медиа для разработчиков

Как автоматизировать копирование файлов

Тестирование фронтенда на примере React-приложения

NPM CLI v7 — пять самых важных фич

Tailwind CSS: за и против

На каком ПО летают на Марсе?

Как сделать из веб-сайта веб-приложение (а главное — зачем?)

Кэширование — Документация Flask (русский перевод) 0.10.1

Настройка кэша

Использование кэша

Руководство по HTTP. Кэширование. – PROSELYTE

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

Веб-кэширование

Сколько времени жить (TTL) | Лучшие практики TTL | Руководство CDN

Сколько времени жить

Рекомендации по настройке политики TTL

Как сети CDN упрощают конфигурацию «Время жизни»

HTTP-кеширование | Основы Интернета | Разработчики Google

Включение кэширования

Кэш-контроль

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

Сводка

Обратная связь

Повышение производительности приложений с помощью заголовков кэша HTTP

Обзор

Кэш-контроль

Срок действия истекает

Условные запросы

По времени

На основе содержимого

Видимость

Примеры использования

Статические активы

Динамический контент

Частное содержание

Предотвращение кеширования

Реализация

Временные антипаттерны для кэширования данных временных рядов

Как запросить срезы времени?

Тайник Сциллы

Антипаттерн

Заключение

просмотров — документация по продукту Acquia

Настройка кеширования представлений

Дополнительная информация о кешировании

документов NGINX | Кэширование содержимого NGINX

Обзор

Включение кеширования ответов