Как правильно кеш или кэш: Кеш или кэш? 13 иностранных слов, в которых надо писать «е» вместо «э» | Образование | Общество

Содержание

Кеш или кэш? 13 иностранных слов, в которых надо писать «е» вместо «э» | Образование | Общество

«Московские новости» публикуют топ-13 иностранных слов, в которых надо писать «е» вместо «э», и одно русское слово, где все как раз наоборот. 

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

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

3. Кеш. Да-да, как ни странно, это слово, обозначающее наличность, мы можем найти в орфографическом словаре В.В. Лопатина именно в таком виде — похоже на орешки кешью. А вот компьютерный термин («пользователь удалил запись, но кэш «Яндекса» помнит все») пишется через «э»: по крайней мере такой вариант есть в словаре трудностей русского языка.

4. Хеллоуин. В орфографическом словаре В.В. Лопатина название этого праздника есть, и зафиксирована в нем именно буква «е», хотя через «э» это слово пишут очень часто. Но тут срабатывает общее правило: после согласного «е», а не «э».

В рубрике «Вспомнить все» объясняем правила русского языка так, чтобы стало понятно

5. Кашне и портмоне. В конце этих слов явно слышится «э», но пишутся они через «е» — это надо запомнить. А вот до революции все было по-другому: писали кашнэ, портмонэ. Это делалось для того, чтобы согласная «н» в этих словах не произносилась мягко, как в местоимении «мне».

6. Коттедж. Подчиняется общему правилу, пишется исключительно через «е». 

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

8. Мейл/имейл. Казалось бы, уж мейл-то точно должен писаться через «э»! Но и тут правило непоколебимо. Оба слова есть в орфографическом словаре.

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

10. Карате. Здесь ситуация как с кашне и портмоне. Раньше писалось «э», потом «е».

Владимир Пахомов, главный редактор Грамоты.ру: 

— Когда в 2009 году возник скандал со словарями и журналисты стали писать о том, что в них появились «йогУрт» и «черное кофе», под горячую руку попало и карате. «Теперь можно писать «карате»!» — писали журналисты как о какой-то новой норме. А на самом деле «э» в этом слове сменилось на «е» еще в конце 1990-х и официально закрепилось в таком виде в словарях.

Одно русское слово. Может возникнуть вопрос: почему же через «э» пишется слово «зэк» (а именно такой, единственный, вариант дает новый орфографический словарь). По правилам через «э» пишутся названия букв: бэ, вэ, гэ, дэ и т. д. Это же правило распространяется и на аббревиатуры, которые состоят из названий букв. Слово «зэк», как известно, представляет собой именно аббревиатуру з/к, что означает «заключенный контингент». Аналогичные примеры — кавээнщик, кагэбэшник, эсэмэска.

Интересный факт 

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

Элегантная коляска в электрическом биеньи

Эластично шелестела по прибрежному песку…

Я в электрической коляске на эллиптических рессорах…

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

‘Кэш’ или ‘кеш’? Самые распространенные ошибки в деловой переписке

По данным рекрутингового портала Superjob.ru, почти четверть (23%) компаний откажут соискателю в работе, если увидят в его резюме грамматические и пунктуационные ошибки. Причем неважно, на какую позицию претендует кандидат.

Грамотность — это такая же «одежка», по которой встречают, как опрятный внешний вид на собеседовании, считают специалисты Capable people. Эксперты рассказали, с какими наиболее частыми  ошибками сталкиваются современные офисные работники.

ИнциНдент

 

Лишний согласный звук «Н» в слове инцидент — яркий признак просторечия говорящего. От этого следует избавляться как можно быстрее. Слово инцидент подарено нам французами (от французского incident — «событие») на самом деле восходит своими корнями к латинскому icidere — «приключаться».

 

ПрецеНдент

 

В этом слове тоже часто пишут и произносят лишнюю букву — «н». «Прецендент» — это неправильно. Вероятно, многие проводят аналогию со словом «претендент», хотя общего у них нет. Просто запомните французское слово précédent, что значит «предшествующий».

 

ЮрисТконсульт

 

Латинское слово «jus» или «juris» означает — право. Буква «т» пишется только в названии лица с юридическим образованием и работой в области права — юрист. Во всех остальных случаях: юрисконсульт, юриспруденция, юрисдикция — буквы Т нет.

 

КомпромеНтировать

 

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

Запомните как мантру и не ошибайтесь: компрометирует, компрометируете, компрометируют.

 

КонкурентНоспособность

 

Слово образовалось сложением двух основ: конкурент (от латинского conceurriens — «соперничающий») и способность с помощью соединительной гласной О. Запомнить просто: конкурент + о + способность. Никакой согласной «н», как видно, нет.

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

 

Канцеляриты

 

Из других современных языковых проблем эксперты Capable people выделяют все большее проникновение канцелярита в разговорную речь, в языки науки и литературы, что ведет к обеднению и даже к порче этих языков. Вот такой смешной пример использования бюрократического языка в быту приводит Корней Чуковский: «В самом деле, представьте себе, что ваша жена, беседуя с вами о домашних делах, заговорит вот таким языком: «Я ускоренными темпами, — скажет она, — обеспечила восстановление надлежащего порядка на жилой площади, а также в предназначенном для приготовления пищи подсобном помещении общего пользования (то есть на кухне. — К. Ч.). В последующий период времени мною было организовано посещение торговой точки с целью приобретения необходимых продовольственных товаров».

 

Чуковский диагностировал главную речевую болезнь двадцатого века — канцелярит, которому посвящена глава в темпераментной книге «Живой как жизнь». В качестве примера, Чуковский описывал реальный случай. У калитки детского сада плакал ребенок. Некий мужчина подошел поинтересоваться и спросил: «По какому вопросу плачешь, девочка?» Этот пример стал хрестоматийным.

 

Из современных реальных примеров часто встречается оборот — «Доброго времени суток!»

Также эксперты Capable people отмечают, что в деловой переписке офисные сотрудники злоупотребляют смайликами и восклицательными знаками. А также путаницей в расстановке запятых в приветствии и подписи  к письмам, с точностью до наоборот. Ошибочно: «Уважаемый, Алексей» наравне с аналогичной ошибкой: «С уважением Алексей».

 

Парные ошибки

 

Это еще одна обширная группа — здесь значение слова зависит от написания.

 

Кампания/компания. В этой паре используются оба варианта, остается только определить, в каких случаях нужна буква О, а в каких — А. Если речь идет о фирме, то выбираем О: компания. Или, например, о друзьях: веселая компания. О на А меняется только в одном случае: если речь идет о сумме каких-то мероприятий. Например, об избирательной или рекламной кампании. 

 

«Растаможивать/растамаживать». Из этой же серии глаголы типа «сосредотачивать/сосредоточивать», «обусловливать/обуславливать» и другие подобные. Таких пар много, но единого правила для них, к сожалению, не существует. Есть абсолютно равноправные варианты типа «обусловливать/обуславливать». Но есть и другие пары, в которых один глагол — литературный, общепринятый, а другой — допустимый. 

 

«Сосредоточивать» — правильно. «Сосредотачивать» — допустимо, но лучше выбрать вариант с О. Есть и совсем недопустимые глаголы с А, например «отсрачивать». Причина недопустимости тут, в общем, ясна. 

 

Что касается самой пары «растаможивать/растамаживать», то правильно — «растаможивать». Вариант с А — это профессиональный жаргон.  

 

«Эффективный/эффектный». Эффективный — это такой, который дает эффект. А эффектный — тот/то, кто/что производит впечатление. Если мы говорим, что очередной законопроект Думы будет эффективным, это означает, что он будет хорошо работать. Но если мы называем его эффектным, это значит, что он просто рассчитан на то, чтобы произвести эффект, кого-то поразить. Выбирайте, что больше подходит.

 

«Экономический/экономичный». «Экономический» — значит имеющий отношение к экономике. А «экономичный» — такой, который дает возможность сэкономить. Интересно, что в прошлом эти слова могли выступать в качестве синонимов. Толковые словари дают одно из толкований с пометкой «устар.»: «экономический = экономичный».

 

«Кеш». Да-да, как ни странно, это слово, обозначающее наличность, мы можем найти в орфографическом словаре В. В. Лопатина именно в таком виде — похоже на орешки кешью. А вот компьютерный термин («пользователь удалил запись, но кэш «Яндекса» помнит все») пишется через «э»: по крайней мере, такой вариант есть в словаре трудностей русского языка.

 

«Мейл/имейл». Казалось бы, уж мейл-то точно должен писаться через «э»! Но и тут правило непоколебимо. Оба слова есть в орфографическом словаре.

 

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

кэш или кеш? — Говорим и пишем правильно — ЖЖ

 

кэш или кеш? 6 дек, 2010 @ 15:45

Здравствуйте! Подскажите, как сейчас ситуация с кешем. На Грамоте.ру (с опорой на словарь РАН) — Е. В Интернете — почти повсюду э. Правильно писать всё равно е или что-то успело поменяться?
From:laweless
Date:Декабрь, 6, 2010 12:46 (UTC)

в сторону

(Link)
по ощущениям — кэш-мелочь, кеш-область памяти.

Re: в сторону

(Link)
про мелочь понятно-понятно. пр ообласть памяти тоже. в обоих случаях произносите как кЭш?
From:laweless
Date:Декабрь, 6, 2010 12:59 (UTC)

Re: в сторону

(Link)
Да. Но на письме бы вот так сделал, как сказал.
From:umklaidet
Date:Декабрь, 6, 2010 14:11 (UTC)

Re: в сторону

(Link)
не мелочь, а наличные в принципе. Если я покупаю билет на самолет наличными, в билете написано в графе стоимость и вид оплаты — cash 20.000 — не думаю, что это такая уж мелочь))
From:laweless
Date:Декабрь, 6, 2010 14:15 (UTC)

Re: в сторону

(Link)
это та самая «мелочь,» которая: «а приятно» 🙂(Удалённый комментарий)
ага, уже и это увидела. спасибо
From:l1nks
Date:Декабрь, 6, 2010 14:22 (UTC)
(Link)
А вот тут — через «е» — http://gramota.ru/spravka/buro/search_answer/?s=%EA%E5%F8
У переводчиков условно принято [æ] транслитерировать как , а [e] — (не в начале слов). Поэтому скорее кэш.

Но лично я выступаю всегда за <е> после согласных (кроме случаев омонимии типа мэр/мер), ибо мягкий согласный + [э] — нормальное природное свойство русского языка, в отличие от твёрдый + [э]. Но только кто меня послушает. 🙂 Узус и традиция уже важнее.

From:true_kaa
Date:Декабрь, 6, 2010 17:34 (UTC)

Кэш

(Link)
Top of Page Разработано LiveJournal.com

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

Установить игру с кэшем или приложение на андроид, достаточно легко, нужно лишь знать базовые принципы, которые мы опишем вам в статье. Возможно вам даже не придется прошивать или патчить свой телефон, планшет на базе андроид. Что бы вам было проще разобраться, мы покажем наглядный пример установки игры Stay Alight с картинками, что бы легче было понять куда разместить кеш. Также предоставим краткую инструкцию: «Как установить на андроид игру с кэшем»

Инструкция: «Как установить игру и программу с кэшем на Андроид».

1 . Главное с чего нужно начать прежде чем устанавливать кеш:

Заходим на гаджете в папку «Настройки» , переходим в «Личное» , нажимаем на «Безопасность» , далее в категории «Администрирование устройства» проставляем плюсик напротив «Неизвестный источник».

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

2 . Загружаем нужные файлы:

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

Для некоторых игр с кеш есть строгие требования по параметрам устройства.

Модель процессора ARM7 или ARM6, означает какой тип процессора подходит к данному файлу «apk».

Некоторые приложения требуют получения ROOT прав. Чтобы узнать подробнее как их получить пройдите по .

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

3 .

Рассмотрим процесс установки игры с кэшем:

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

Распаковываем файл с помощью известных программ. Для ПК это WinRAR, для Android это ES File Explorer.

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

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

После того как мы скопировали исходный файл возвращаемся в корень нашей SD карты открываем папку «Андроид», затем папку «obb»

Все кеш файл мы разместили в нужном месте, переходим к установке «апк».

Установка apk на андроид:

Запускаем менеджер файлов. Если его нет, необходимо установить к примеру, «Trashbox.ru». У Samsung он является стандартным приложением с именем «Мои файлы».

Ищем загруженный файл, кликаем на него. После запуска установки, следуем указаниям установщика.

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

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

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

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

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

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

  • тип процессора;
  • рабочее разрешение дисплея;
  • дополнительные данные об аппаратной части мобильного девайса.

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

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

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

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

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

Установка игр с кэшем на Андроид возможна и с помощью компьютера. В отличие от предыдущего метода, пользователю не потребуется инсталлировать дополнительный софт на Android. Единственным условием успешного завершения всего процесса является наличие кабеля USB. Впрочем, соединить мобильный девайс с ПК можно с помощью беспроводных протоколов передачи данных Wi-Fi либо Bluetooth.

С помощью файлового менеджера

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

Алгоритм дальнейших действий:

  • Требуется открыть файловый менеджер и запустить файл apk. Когда процесс инсталляции завершится, запускать игровое приложение не нужно.
  • Разархивировать файлы кэша в нужную директорию.
  • Можно запустить игру.

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

Если игра от Gameloft была скачана с Google Play, то распаковать кэш на Андроид следует в ту же директорию, что и для приложений Electronic Arts.

Используя компьютер

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

  • Открыть опцию «Настройки» и перейти в раздел «Безопасность».
  • Пункт «Неизвестные источники» нужно отметить галочкой.

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

Затем предстоит выполнить ряд действий:

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

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

Отдельный файл

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

Сначала необходимо определить идентификатор (ID) игры, а затем создать соответствующую папку в директории /Android/obb. Именно туда и нужно будет закидывать файл кэша. Для решения поставленной задачи следует зайти на страницу приложения в магазине Гугла. Искомый идентификатор содержится в URL-адресе странички после символов «id =». Например, идентификатор игры Warhammer 40,000: Space Wolf — com. herocraft. spacewolf.

Следует скопировать нужную информацию, а в менеджере файлов перейти в директорию /Android/obb/. Создав там новую папку, в поле с ее именем вставляют скопированный ID. Завершающим этапом станет перенос в нее файла кэша. Приложение можно запустить и наслаждаться игровым процессом.

Возможные проблемы

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

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

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

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

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

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

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

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

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

Установка кэша на Андроид начинается со скачивания игры или приложения. Но поскольку Вы наверняка уже всё скачали, то можно приступить к установке:

  1. Скачать кеш с Android Market, после оплаты самого приложения или игры.
  2. Установить cache после установки самой игры или приложения.
  3. Также возможна установка кэша на Андроид через карту памяти.

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

Куда кидать кеш на андроид

Итак, если Вы решили действовать по третьему пути и раздобыли нужный кэш, то давайте найдём куда его кинуть. Многие разработчики пишут путь, куда устанавливается кеш, при его скачивании. То есть почти универсальным способом будет посмотреть путь установки кэша после того, как его начали качать. Обычно путь помечается словами «Распаковать в» или «Извлечь в» (Extract to). Нужно запомнить данный путь и потом туда установить файл.

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

  • Путь для игр от GameLoft: Карта памяти > Gameloft > games > Папка с кешем
  • Путь для игр от Electronic Arts: Карта памяти > Android > Data > Папка с файлом cache
  • Путь для игр от Glu: Карта памяти > Glu > Папка с кеш
  • Путь для игры GTA 3 Vice City: Карта памяти > Android > Data > Папка с кешем
  • Путь для игры Asphalt 7: Heat: Карта памяти > Android > Obb > Папка с файлом
  • Путь для игры Nova 3: Карта памяти > Android > Obb > Папка с кэшем

Установка игровых приложений на устройствах с операционной системой Android не представляет собой ничего сложного – заходим в Play Market, находим нужную игру, нажимаем на кнопку установки и дожидаемся окончания инсталляции. Если же нужно установить явно «пиратскую» игрушку (читай, взломанную) с мощной графикой, то процесс инсталляции будет другим. Как установить игру с кэшем на Андроид и что представляет собой кэш?

Что такое кэш

Все приложения для Android поставляются в виде файлов с расширением *.apk. Каких-то исключений из этого правила нет, поэтому искать приложения в других форматах не стоит – вы их не найдете. Установка программы из магазина Play Market представляет собой скачивание и последующую установку APK-файла . Как только инсталляция завершится, можно приступить к запуску приложения.

То же самое относится и к играм для Android – это стандартные APK-файлы, скачанные из Play Market или добытые из других источников. Самые простые игровые приложения запакованы в единый файл и выложены на тех или иных ресурсах. Графика здесь чаще всего двухмерная, поэтому объем инсталляционных файлов небольшой.

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

  • Снижение нагрузки на Play Market;
  • Более легкое и быстрое обновление приложений;
  • Быстрый ввод изменений в игры (это плюс для разработчиков).

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

Как устанавливать игры с кэшем на Андроид и для чего это вообще нужно? Если мы устанавливаем игры из Play Market, то заботиться ни о чем не надо – после запуска игра самостоятельно скачает то, что ей нужно. Необходимо поставить пиратскую, взломанную или модернизированную игрушку? Тогда нужно скачать APK-файл со стороннего источника и слить оттуда же кэш. После этого распаковываем кэш и закачиваем его в нужную папку.

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

Как устанавливать игры на Андроид с кэшем

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

  • APK-файл – это запускающий файл игрового приложения;
  • Файл с кэшем – это архив с файлами, необходимыми для запуска игры.

Для того чтобы установить APK-файл игрового приложения, необходимо зайти в «Настройки – Безопасность» и установить галочку напротив пункта «Неизвестные источники». Тем самым мы разрешаем установку сторонних APK-файлов (именно так и распространяются пиратские и модифицированные игры).

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

  • Скачиваем кэш прямо на Android-устройство через Wi-Fi или мобильный интернет;
  • Заливаем кэш с помощью data-кабеля;
  • Копируем кэш с карты памяти, установленной в устройство.

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

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

Возникающие проблемы и их решения

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

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

Перемещаясь по файловой системе с правами root проявляйте осторожность и не допускайте случайного удаления каких-либо файлов и папок – это может привести к потере работоспособности операционной системы Андроид.

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

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

Шаг № 1. Скачиваем APK файл и кеш на свой компьютер.

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

Шаг № 2. Скопируйте кеш с компьютера на Андроид устройство.

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

Обычно кеш от Андроид игр нужно переносить в папку sdcard/Android/data/ или в папку sdcard/Android/obb . Хотя некоторые разработчики создают собственные папки для кеша своих игр. Например, кеш для игр от Gameloft нужно переносить в папку sdcard/gameloft/games/, а кеш для игр от GLu в папку sdcard/glu/.

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

Перенос файлов можно выполнять, при помощи USB кабеля. Но, вы можете снять карту памяти, подключить ее к компьютеру и скопировать файлы напрямую.

Шаг № 3. Скопируйте APK файл в любую папку на вашем Андроид устройстве.

Теперь нам нужно перенести APK файл на Андроид устройство. Сам APK файл можно копировать в любую папку, в которую вам удобно. Вы можете поместить APK файл на карту памяти SD или во внутреннюю память, то не важно. Главное, чтобы вы знали, где искать этот файл, поскольку его нужно будет открыть на устройстве.

Шаг № 4. Установите игру с помощью APK файла.

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

Узнаем как правильно установить кэш на «Андроид» – инструкция для новичков

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

Описание

Определение «кэш», применимое к смартфонам, обозначает специальное хранилище, где содержится информация, необходимая для нормальной работы того или иного приложения. Когда вы устанавливаете программу к себе на телефон, чаще всего вам предлагается произвести автоматизированную загрузку. Если у вас есть доступное и, самое главное, стабильное подключение к Интернету, то рекомендуется не отказываться. Особенно важно, чтобы связь с Всемирной паутиной была высокоскоростной, так как кэш в некоторых приложениях достигает огромных размеров. Чаще всего программа заранее информирует вас о размере загружаемого контента. Если у вас нет стабильного подключения, а под этим понимается Wi-Fi или 3G (4G), то есть альтернативный вариант. На специализированных порталах пользователи выкладывают уже скаченный кэш. Вы можете его переместить на свой смартфон с использованием USB-кабеля. Во внутренней (или внешней) памяти телефона вам нужно найти нужную директорию, которая специально создана для этого приложения, и поместить туда кэш.

Программы

Другим популярным вопросом является: «Как установить программы на «Андроид?» Кэш не имеет смысла без основного приложения, с помощью которого происходит запуск всех необходимых служб. Поэтому нужно в первую очередь знать, как происходит установка программ. Для этого можно воспользоваться очень удобным и надежным средством под названием Google Play. На данном портале находятся практически все приложения, которые когда-либо создавались разработчиками. Для полной работоспособности и синхронизации телефона и компьютера необходимо завести почтовый аккаунт в системе «gmail». Все происходит бесплатно и быстро. Помимо способа с сервисом Google Play, программы можно устанавливать вручную. Для этого скачайте приложение на свой ПК, далее поместите его на флеш-карту телефона, а уже с нее установите программу, выбрав ее в диспетчере файлов. Все приложения для платформы «Андроид» имеют расширение «.apk».

Темы

Чтобы узнать, как установить тему на «Андроид», достаточно ознакомиться с предшествующим абзацем, в котором описывается установка приложений. Ведь темы для оформления смартфона имеют одинаковое расширение файлов, которое указывается в обычных программах. Можно также воспользоваться сервисом Google Play или ручной установкой. Для удобного интерфейса компания «Гугл» сделала специальную мобильную версию своего портала. Поэтому вы можете прямо со своего телефона производить установку.

Заключение

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

Как установить кеш на андроид, инструкция по установке apk

 

Установить игру с кэшем или приложение на андроид, достаточно легко, нужно лишь знать базовые принципы, которые мы опишем вам в статье. Возможно вам даже не придется прошивать или патчить свой телефон, планшет на базе андроид. Что бы вам было проще разобраться, мы покажем наглядный пример установки игры Stay Alight с картинками, что бы легче было понять куда разместить кеш. Также предоставим краткую инструкцию: «Как установить на андроид игру с кэшем»

Инструкция: «Как установить игру и программу с кэшем на Андроид».

 1. Главное с чего нужно начать прежде чем устанавливать кеш:

Заходим на гаджете в папку «Настройки», переходим в «Личное», нажимаем на «Безопасность», далее в категории «Администрирование устройства» проставляем плюсик напротив «Неизвестный источник».

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

 2. Загружаем нужные файлы:

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

Для некоторых игр с кеш есть строгие требования по параметрам устройства.

— Модель процессора ARM7 или ARM6, означает какой тип процессора подходит к данному файлу «apk».

Возможно данный параметр не указан, значит ограничений нет. Для определения типа процессора на вашем устройстве рекомендуем использовать программу CPU-Z.

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

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

 3.

Рассмотрим процесс установки игры с кэшем:

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

— Распаковываем файл с помощью известных программ. Для ПК это WinRAR, для Android это ES File Explorer.

 

 

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

 

  

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

 

  

 

После того как мы скопировали исходный файл возвращаемся в корень нашей SD карты открываем папку «Андроид», затем папку «obb»

  

  

 

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

 

 

Все кеш файл мы разместили в нужном месте, переходим к установке «апк».

Установка apk на андроид:

— Запускаем менеджер файлов. Если его нет, необходимо установить к примеру, «Trashbox.ru». У Samsung он является стандартным приложением с именем «Мои файлы».

— Ищем загруженный файл, кликаем на него. После запуска установки, следуем указаниям установщика.

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

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

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

Как установить игру с кешем

С ростом количества пользователей Android устройств многие разработчики озабочены созданием контента для этой платформы, и чтобы привлечь конечного пользователя они стараются делать проекты зрелищными и многофункциональными. А добиться этого без увеличения общего размера финального продукта просто нереально, именно поэтому современные игры имеют солидный «вес», порой превосходя в объеме несколько сот мегабайтов и даже гигабайтов. А что вы хотели? Графику консольного уровня в пару мегабайт не уложить! Именно по этой причине стало принципиально важно грамотно организовать процесс хранения массивных данных на мобильном девайсе. Для этого в тандеме с установочным файлом APK формата поставляется так называемый кэш, являющийся файлом со специальными игровыми ресурсами (звуки, графика, скрипты и прочее).

Если контент устанавливается исключительно с площадки Google Play, то «колдовать» с кэшем нет необходимости, так как вся эта процедура исполняется в автоматическом формате, без какого-либо участия пользователя. Ему необходимо лишь выбрать подходящий игровой проект, тапнуть по иконке «скачать», да просмотреть список разрешений, требуемых для функционирования скачиваемого программного обеспечения. Другое дело, когда игра устанавливается со стороннего ресурса – пользователю уже придется самостоятельно переносить установочный файл и кэш в соответствующую директорию на мобильном устройстве. Все эти шаги можно выполнить или непосредственно на Android аппарате (потребуется файловый менеджер с возможностью разархивации, например, ES Проводник) или с помощью ПК, что на наш взгляд намного удобнее. Предлагаем рассмотреть оба эти варианта по шагам на примере инсталляции приложения Battle Bay от студии Rovio.

Установка дополнительных игровых файлов на мобильном устройстве:

  • Находим и скачиваем файл APK формата и кэш.
  • Выполняем процесс установки APK файла без последующего запуска.
  • С помощью ES Проводника находим кэш, который традиционно лежит в Download папке в виде RAR или ZIP архива – com.rovio.battlebay.zip. В пакете уже имеется папка под названием com.rovio.battlebay, где и расположен наш кэш формата OBB. Нам предстоит перенести это «добро» в директорию Android → obb.

  • Удерживаем палец на архиве некоторое время, после чего появляется вкладка «Распаковать в» → выбираем папку /Android/obb (на некоторых мобильных устройствах этот каталог имеет название /sdcard/Android/obb).

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

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

Проекты от Gameloft перемещаем в sdcard/gameloft/games/[кэш].
Проекты от Electronic Arts (EA) — sdcard/Android/data/[кэш].
Проекты от Glu — sdcard/glu/[кэш].

Установка кэша с компьютера:

  • Подсоедините с помощью USB-кабеля мобильное Android устройств к ПК.
  • Распакуйте архив с помощью любого целевого программного обеспечения (WinRAR, 7-Zip, WinZip и прочие).
  • Перенесите папку с OBB файлом в соответствующую директорию – /Android/obb.

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

Кэш против Кэш

Английский язык сложный. В английском языке есть слова, которые звучат одинаково, но имеют разное написание и значение. Эти слова называются омофонами, и они вызывают путаницу у многих молодых людей, изучающих язык, и у носителей языка. Cash и cache — пример пары омофонов, которые звучат одинаково. Многие люди произносят кеш как кайше или качай, но правильное произношение кеш точно такое же, как кеш.

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

Происхождение:

Денежные средства возникли в конце 16 века (обозначая ящик для денег): от старофранцузского casse или итальянского cassa «коробка», от латинского capsa (см. дело 2).

Наличные как существительное:

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

Сотрудникам заплатили наличными.

Кэш как существительное:

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

Мы подошли к тайнику с оружием.

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

Типичный размер кэша составляет от 64 до 256 КБ.

Примеры :

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

Тайник с десятью минометными снарядами, двумя автоматами Калашникова и значительным количеством боеприпасов был обнаружен в пятницу в Тин-Зауатине отрядом Национальной народной армии (АНП), говорится в сообщении Министерства национальной обороны (МДН).(Алжирская пресс-служба)

Силы безопасности Йемена захватили большой тайник с оружием в районе Аль-Тавахи города Адена, где утвердились незаконные вооруженные формирования. (Национальный)

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

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

Философия программы денежных переводов Project Issara проста: никто не знает потребности жертв торговли людьми лучше, чем сами жертвы. (Христианский научный монитор)

Наличные или кэш:

Тайник — тайник, особенно в земле, для боеприпасов, еды, сокровищ и т. д.; область компьютерной памяти, предназначенная для высокоскоростного поиска часто используемых или запрашиваемых данных. Наличные — это деньги в виде монет или банкнот, особенно выпущенные государством.Cache и cash произносятся одинаково, но имеют разное написание и значение. Распространенной ошибкой при написании является написание «cache» как «cash».

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

Понял? Мы не виним вас!

 

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

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

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

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

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

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

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

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

Почему кэширование важно

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

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

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

Другим важным аспектом кэширования является то, что оно позволяет избежать каждый раз новых запросов или повторной обработки данных. Так что мы можем избежать накладных расходов, таких как сетевые накладные расходы, и уменьшить использование ЦП, особенно если запросы связаны со сложными разработками.Это может продлить срок службы наших машин или серверов. Кроме того, отказ от новых запросов снижает общее количество необходимых запросов, что может снизить стоимость вашей инфраструктуры. Фактически, при работе с облачными платформами или поставщиками общедоступных API, например, обычно выставляются счета за любое сетевое взаимодействие между их службами. Отличные побочные эффекты, не так ли?

Проблемы

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

Проблема когерентности

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

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

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

Работа с промахами кэша

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

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

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

Кэширование в памяти

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

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

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

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

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

Его можно разделить на две дополнительные подкатегории:

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

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

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

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

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

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

Заключение

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

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

Контроллер кэш-памяти — обзор

Системная память

Термин память относится к микросхеме, на которой хранятся данные. Некоторые начинающие пользователи компьютеров могут спутать термины место на диске и память ; таким образом, вы слышите вопрос: «Сколько памяти осталось на моем жестком диске?» В каком-то смысле диск действительно «помнит» данные.Однако термин память более точно используется для описания микросхемы, которая временно хранит данные, и чаще всего используется для обозначения системной памяти или оперативной памяти (ОЗУ) , в которой хранятся инструкции, с которыми работает процессор. в настоящее время работает, и данные в настоящее время обрабатываются. Микросхемы памяти различных типов используются в других частях компьютера; есть кэш-память, видеопамять и так далее. Она называется памятью с произвольным доступом , потому что данные можно считывать из любого места в памяти в любом порядке.

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

Каждая микросхема ОЗУ имеет большое количество памяти адресов или ячеек , организованных в строки и столбцы. Один чип может иметь миллионы ячеек. Динамическая память с произвольным доступом (DRAM) объединяет транзистор и конденсатор для создания ячейки памяти, которая представляет один бит данных. Каждый адрес содержит определенное количество битов данных. Несколько микросхем объединены в модуль памяти , который представляет собой небольшую печатную плату, вставляемую в слот памяти на материнской плате компьютера.Контроллер памяти, входящий в состав чипсета материнской платы, является «гаишником», который контролирует, в какой именно чип памяти производится запись или чтение в данный момент времени. Как данные попадают из памяти в процессор? Он использует шину — шину памяти (или шину данных). Как упоминалось ранее, шина представляет собой канал, по которому передаются электронные сигналы, представляющие данные внутри ПК, от одного компонента к другому.

ОЗУ может быть как для чтения, так и для записи. Компьютеры используют другой тип памяти, постоянное запоминающее устройство (ПЗУ) , для хранения важных программ, которые должны быть постоянно доступны.Специальный тип ПЗУ, упомянутый ранее, стираемое программируемое ПЗУ (СППЗУ), используется в ситуациях, когда вам может потребоваться время от времени, но не часто, изменять данные. Обычная функция EPROM (или EEPROM, которая представляет собой электрически стираемое PROM ) заключается в хранении «перезаписываемых» программ BIOS, которые обычно остаются неизменными, но могут нуждаться в периодическом обновлении. Технически СППЗУ не является «только для чтения» в 100% случаев, потому что его можно стирать и перезаписывать, но в большинстве случаев оно только читается, а не записывается.Данные, хранящиеся в ПЗУ (включая СППЗУ), , а не , теряются при выключении системы.

Еще одним типом памяти, используемой в ПК, является кэш-память . Кэш-память намного быстрее оперативной, но и намного дороже, поэтому ее меньше. Кэш-память содержит недавно использованные данные. Кэш расположен слоями между оперативной памятью и процессором. Первичный или уровень 1 (L1) кэш-памяти самый быстрый; когда процессору нужна определенная часть данных, контроллер кеша сначала ищет ее в кеше L1.Если его там нет, контроллер переходит к вторичному кешу или кешу L2. Если контроллер по-прежнему не находит данные, он ищет их в оперативной памяти. На момент написания этой статьи кэш-память L1 стоит примерно в 100 раз больше, чем обычная RAM или SDRAM, тогда как кэш-память L2 стоит в четыре-восемь раз дороже, чем самая дорогая доступная RAM. Кэш значительно ускоряет обработку, поскольку статистически данные, которые использовались последними, скорее всего, потребуются снова. Получение его из более быстрой кэш-памяти вместо более медленной оперативной памяти повышает общую производительность.

Примечание

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

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

Управление кэшем — HTTP | MDN

Поле HTTP-заголовка Cache-Control содержит директивы (инструкции) — как в запросах, так и в ответах — которые управляют кэшированием в браузерах и общими кэшами (т.г. прокси, CDN).

Директивы кэширования следуют приведенным ниже правилам проверки:

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

Директивы кэша

Стандартные директивы Cache-Control определяются следующим образом.

Запрос Ответ
максимальный возраст максимальный возраст
максимальная устаревшая
мин-фреш
s-maxage
без кэша без кэша
нет в магазине нет в магазине
без трансформации без трансформации
только при кэшировании
необходимо подтвердить
повторная проверка прокси
необходимо понять
частный
общественный
неизменяемый
устаревшие при повторной проверке
устаревание-если-ошибка устаревшая-если-ошибка

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

В этом документе используются следующие термины; многие, но не все из спецификации.

(HTTP) кэш

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

Общий кэш

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

Частный кэш

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

Ответ магазина

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

Повторное использование ответа

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

Подтвердить ответ

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

Свежий ответ

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

Устаревший ответ

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

Возраст

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

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

Директивы реагирования

максимальный возраст

Директива ответа max-age=N указывает, что ответ остается свежим до N секунд после создания ответа.

 Управление кэшем: max-age=604800
 

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

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

 Управление кэшем: max-age=604800
Возраст: 100 лет
 
s-maxage

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

 Кэш-Контроль: s-maxage=604800
 
без кэша

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

 Cache-Control: нет кэша
 

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

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

необходимо подтвердить

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

Как правило, must-revalidate используется с max-age .

 Cache-Control: max-age=604800, необходимо перепроверить
 

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

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

Директива ответа proxy-revalidate эквивалентна директиве must-revalidate , но только для общих кэшей.

нет в магазине

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

 Cache-Control: нет хранения
 
частный

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

 Cache-Control: частный
 

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

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

общественный

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

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

Как правило, когда страницы находятся в режиме Basic Auth или Digest Auth, браузер отправляет запросы с заголовком Authorization . Это означает, что доступ к ответу контролируется для пользователей с ограниченным доступом (у которых есть учетные записи), и он принципиально не подлежит совместному кэшированию, даже если он имеет max-age .

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

 Cache-Control: public, max-age=604800
 

Обратите внимание, что s-maxage или must-revalidate также разблокируют это ограничение.

Если в запросе нет заголовка Authorization или вы уже используете в ответе s-maxage или must-revalidate , то вам не нужно использовать public .

необходимо понять

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

необходимо понимать следует сочетать с no-store для резервного поведения.

 Cache-Control: необходимо понимать, не хранить
 

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

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

без трансформации

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

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

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

неизменяемый

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

 Cache-Control: public, max-age=604800, неизменяемый
 

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

 <скрипт src=https://example.com/react.0.0.0.js>
 

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

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

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

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

 Cache-Control: max-age=604800, stale-while-revalidate=86400
 

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

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

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

устаревшая-если-ошибка

Директива ответа stale-if-error указывает, что кэш может повторно использовать устаревший ответ, когда исходный сервер отвечает с ошибкой (500, 502, 503 или 504).

 Cache-Control: max-age=604800, stale-if-error=86400
 

В примере выше ответ актуален в течение 7 дней (604800 с).Через 7 дней он устаревает, но его можно использовать еще 1 день (86400 с), если сервер отвечает с ошибкой.

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

no-cache

Директива запроса no-cache просит кэши проверить ответ на исходном сервере перед повторным использованием.

 Cache-Control: нет кэша
 

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

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

no-store

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

 Cache-Control: нет хранения
 

Обратите внимание, что основные браузеры не поддерживают запросы с no-store .

max-age

Директива запроса max-age=N указывает, что клиент разрешает сохраненный ответ, который генерируется на исходном сервере в течение N секунд.

 Кэш-Контроль: max-age=3600
 

В приведенном выше случае, если ответ с Cache-Control: max-age=604800 был сохранен в кэшах 3 часа назад, кэш не мог повторно использовать этот ответ.

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

 Кэш-контроль: max-age=0
 

max-age=0 — это обходной путь для без кэша , потому что многие старые (HTTP/1.0) реализации кэша не поддерживают без кэша . В последнее время браузеры все еще используют max-age=0 в «перезагрузке» — для обратной совместимости — и альтернативно используют без кэша , чтобы вызвать «принудительную перезагрузку».

max-stale

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

 Cache-Control: max-stale=3600
 

В приведенном выше случае, если ответ с Cache-Control: max-age=604800 был сохранен в кэшах 3 часа назад, кэш не мог повторно использовать этот ответ.

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

Обратите внимание, что основные браузеры не поддерживают запросы с max-stale .

min-fresh

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

 Cache-Control: min-fresh=600
 

В приведенном выше случае, если ответ с Cache-Control: max-age=3600 был сохранен в кэшах 51 минуту назад, кэш не мог повторно использовать этот ответ.

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

Обратите внимание, что основные браузеры не поддерживают запросы с min-fresh .

без преобразования

То же значение, что и без преобразования для ответа, но вместо этого для запроса.

only-if-cached

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

Предотвращение сохранения

Если вы не хотите, чтобы ответ сохранялся в кеше, используйте директиву no-store .

 Cache-Control: нет хранения
 

Обратите внимание, что no-cache означает, что «его можно сохранить, но не использовать повторно перед проверкой» — так что это не для предотвращения сохранения ответа.

Теоретически, если директивы противоречат друг другу, должна соблюдаться самая ограничительная директива. Таким образом, приведенный ниже пример в основном бессмыслен, потому что private , no-cache , max-age=0 и must-revalidate конфликтуют с no-store .

 # конфликтует
Cache-Control: частный, без кеша, без хранилища, max-age=0, обязательная повторная проверка

# эквивалентно
Cache-Control: без хранения
 

Кэширование статических ресурсов с помощью «очистки кэша»

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

Например:

 


  

Версия библиотеки React изменится при обновлении библиотеки, и hero.png также изменится при редактировании картинки. Так что их трудно хранить в кеше с max-age .

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

 


  

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

 # /активы/*
Cache-Control: max-age=31536000, неизменяемый
 

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

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

 # /index.html
Кэш-контроль: без кеша
 

Примечание. Если index.html управляется базовой аутентификацией или дайджест-аутентификацией, файлы под /assets не сохраняются в общем кэше. Если файлы /assets/ подходят для хранения в общем кэше, вам также понадобится один из public , s-maxage или must-revalidate .

Всегда актуальное содержимое

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

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

Добавление no-cache к ответу вызывает повторную проверку на сервере, поэтому вы можете каждый раз предоставлять новый ответ — или, если у клиента уже есть новый, просто ответьте 304 Not Modified .

 Cache-Control: нет кэша
 

Большинство кэшей HTTP/1.0 не поддерживают директивы no-cache , поэтому исторически max-age=0 использовалось в качестве обходного пути. Но только max-age=0 может привести к повторному использованию устаревшего ответа при отключении кэшей от исходного сервера. необходимо перепроверить адреса. Вот почему приведенный ниже пример эквивалентен без кэша .

 Cache-Control: max-age=0, необходимо перепроверить
 

Но сейчас вы можете просто использовать без кэша .

Очистка уже сохраненного кэша

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

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

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

Таблицы BCD загружаются только в браузере

Обзор кэширования  | Облачная CDN  | Облако Google

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

Режимы кэша

С помощью режимов кэширования можно управлять факторами, определяющими Cloud CDN кэширует ваш контент.

Cloud CDN предлагает три режима кэширования, которые определяют, как ответы кэшируются, независимо от того, соблюдает ли Cloud CDN директивы кэширования, отправленные происхождения и как применяются TTL кэша.

Доступные режимы кэша показаны в следующей таблице:

Режим кэширования Поведение
КЭШ_ВСЕ_СТАТИЧЕСКИЕ Автоматически кэширует статическое содержимое, не имеет директивы no-store или private .Ответы источника, которые устанавливают действительные директивы кэширования, также кэшируются.

Это поведение по умолчанию для Cloud CDN с поддержкой серверные части, созданные с помощью инструмента командной строки gcloud или REST API.

USE_ORIGIN_HEADERS Требуются ответы источника для установки действительных директив кэша и действительных кэширование заголовков. Ответы без этих директив пересылаются из источника.
FORCE_CACHE_ALL Безоговорочно кэширует успешные ответы, переопределяя любой кэш директивы, установленные источником.Этот режим не подходит, если серверная часть обслуживает частный контент для каждого пользователя, такой как динамический HTML или API ответы.
Предостережение: Когда вы устанавливаете режим кэширования FORCE_CACHE_ALL , время по умолчанию live (TTL) для кэширования контента составляет 3600 секунд (1 час), если вы явно не установите другой TTL. Принятие нового TTL по умолчанию, равного 1 часу, может привести к некоторым записи, которые ранее считались свежими (из-за более длинных TTL от заголовки origin) теперь считаются устаревшими. Внимание: Режим FORCE_CACHE_ALL переопределяет директивы кэша ( Cache-Control и Expires ), но не переопределяет другие заголовки ответа источника. В в частности, заголовок Vary по-прежнему учитывается и может подавлять кэширование даже при наличии FORCE_CACHE_ALL . Для получения дополнительной информации см. Варьировать заголовки. Примечание: Режим FORCE_CACHE_ALL переопределяет максимальный возраст, указанный для любого подписанные URL-адреса или подписанные файлы cookie через настройка максимального возраста записи кэша в Google Cloud Console или gcloud Опция --signed-url-cache-max-age .

Инструкции по настройке см. в разделе Настройка кэша. режим.

Статическое содержимое

Статическое содержимое — это содержимое, которое всегда остается одним и тем же, даже при доступе к нему разные пользователи. CSS, который вы используете для оформления своего сайта, JavaScript для предоставления интерактивность, видео и изображения обычно не меняются для каждого пользователя в течение заданный URL-адрес (кэш-ключ ) и, таким образом, выигрывает от кэширования через Глобальная пограничная сеть Cloud CDN.

Если для режима кэширования установлено значение CACHE_ALL_STATIC , Cloud CDN автоматически кэширует ответы для следующего:

  • Веб-активы, включая CSS ( text/css ), JavaScript ( application/javascript ) и все веб-шрифты, включая WOFF2 ( font/woff2 )
  • Изображения, включая JPEG ( image/jpg ) и PNG ( image/png )
  • видео, в том числе H.264, H.265 и MP4 ( видео/mp4 ) +. Аудиофайлы, в том числе MP3 ( image/mpeg ) и MP4 ( audio/mp4 )
  • Форматированные документы, включая PDF ( приложение/pdf )
Важно: Описанные здесь правила статического содержимого применяются только к успешным ответы (например, ответы HTTP 200 OK ). Напротив, ответы на ошибки кэшируются на основе отрицательного кэширования настройки независимо от типа контента.

В следующей таблице приведены сводные данные.

Категория MIME-типы
Веб-ресурсы текст/текст css/текст ecmascript/приложение javascript/javascript
Шрифты Любой Content-Type соответствующий шрифт/*
Изображения Любой Content-Type соответствующий image/*
Видео Любой Content-Type соответствующий video/*
Аудио Любой Content-Type соответствующий audio/*
Форматированные типы документов заявка/pdf и заявка/постскриптум

Cloud CDN проверяет заголовок HTTP-ответа Content-Type , который отражает MIME тип обслуживаемого контента.

Обратите внимание на следующее:

  • Программное обеспечение веб-сервера вашего источника должно установить Content-Type для каждого отклик. Многие веб-серверы автоматически устанавливают заголовок Content-Type , включая NGINX, Varnish и Apache.

  • Cloud Storage автоматически устанавливает заголовок Content-Type на загружать, когда вы используете Облачная консоль или инструмент gsutil для загрузки контента.

  • Если ответ кэшируется на основе его типа MIME, но имеет Cache-Control заголовок ответа private или no-store или Set-Cookie header (см. полный список правил), он не кэшируется.

Важно: Другие типы контента, такие как HTML ( text/html ) и JSON ( application/json ), по умолчанию не кэшируются для успешных ответов. Эти типы ответов обычно динамические (для каждого пользователя). Примеры включают покупки корзины, страницы продуктов с пользовательской персонализацией и аутентифицированный API ответы. Негативное кэширование, если оно включено, может однако по-прежнему заставляют их кэшироваться для определенных кодов состояния.

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

Если вы хотите кэшировать типы контента text/html и application/json , вы должны установить явные заголовки Cache-Control в ответе, будучи будьте осторожны, чтобы случайно не кэшировать данные одного пользователя и не передать их всем пользователям.

Кэшируемое содержимое

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

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

Cloud CDN сохраняет ответы в кеше, если выполняются все следующие условия.

Атрибут Требование
Обслуживается Серверная служба, серверная корзина или внешний сервер с Облачный CDN включен
В ответ на ПОЛУЧИТЬ запрос
Код состояния

200 , 203 , 204 , 206 , 300 , 301 , 302 , 307 , 308 , 404 , 405 , 410 , 421 , 451 или 501 .

Свежесть

Ответ имеет заголовок Cache-Control с максимальным возрастом или директива s-maxage или заголовок Expires с отметка времени в будущем.

Для кешируемых ответов без возраста (например, с no-cache ), директива public должна быть явно при условии.

С режимом кеша CACHE_ALL_STATIC , если нет свежести директивы присутствуют, успешный ответ со статическим типом контента по-прежнему подходит для кэширования.

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

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

Содержание

Содержит действительный Content-Length , Content-Range или Transfer-Encoding: разделенный заголовок .

Например, заголовок Content-Length , который правильно соответствует размер ответа.

Размер Меньше или равно максимальному размеру.

Для ответов размером от 10 МБ до 5 ТБ см. ограничения кэшируемости, описанные в запросы диапазона байтов.

Для серверных сегментов Cloud Storage существует несколько способов эти требования:

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

  • Изготовление индивидуального общедоступные для чтения объекты.Мы не рекомендуем этот подход.

По умолчанию, когда вся корзина общедоступна или отдельные объекты общедоступные и отдельные объекты не указывают метаданные Cache-Control , Cloud Storage назначает заголовок Cache-Control: public, max-age=3600 для объект. Вы можете установить различные значения, используя Метаданные Cache-Control .

Для примера, показывающего, как настроить внешний балансировщик нагрузки HTTP(S) с серверной частью ведро, см. раздел Настройка Cloud CDN с серверной частью ведро.

Примечание: Альтернативой общедоступному содержимому является его конфиденциальность и вместо этого используйте подписанные URL-адреса.

Максимальный размер

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

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

Исходный сервер поддерживает запросы диапазона байтов Исходный сервер не поддерживает запросы диапазона байтов
5 ТБ (5 497 558 138 880 байт) 10 МБ (10 485 760 байт)

Почти все современные веб-серверы (включая NGINX, Apache и Varnish) поддерживают запросы диапазона байтов.

Некэшируемое содержимое на основе заголовков источника

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

Cloud CDN не кэширует ответ, если он не соответствует требованиям для кэшируемого содержимого или если верно любое из следующих условий.

Атрибут Требование
Обслуживается Серверная служба или внешняя серверная часть, не имеющая Облачный CDN включен
Печенье Имеет заголовок Set-Cookie
Вари Заголовок Имеет значение, отличное от Принять , Accept-Encoding или Origin
Ответная директива Ответ имеет заголовок Cache-Control с нет в магазине или частный директива (если не используется режим кэширования FORCE_CACHE_ALL , в в этом случае заголовок Cache-Control игнорируется)
Директива запроса Запрос имеет директиву Cache-Control: no-store
Запрос авторизации Запрос имеет заголовок Authorization , если только перекрывается ответом Кэш-Контроль.
Размер Больше максимального размера

Если Cache-Control: no-store или private присутствует, но содержимое все еще кэшируется, это связано с одной из следующих причин:

  • Подписание URL настроено.
  • Режим кэширования Cloud CDN настроен на принудительное кэширование всех ответов.

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

Чтобы предотвратить кэширование частной информации в Cloud CDN кеши, сделайте следующее:

  1. Убедитесь, что режим кэширования Cloud CDN не установлен на FORCE_CACHE_ALL режим, который безоговорочно кэширует все успешные ответы.
  2. Включить заголовок Cache-Control: private в ответы, которые не должны хранится в кэшах Cloud CDN или Cache-Control: no-store заголовок в ответах, который не должен храниться ни в каком кеше, даже в веб- кеш браузера.
  3. Не подписывайте URL-адреса, предоставляющие доступ к закрытым Информация. Когда доступ к контенту осуществляется с использованием подписанного URL-адреса, он потенциально подходящим для кэширования независимо от каких-либо директив Cache-Control в отклик.
  4. Для запросов происхождения (заполнения кэша), которые включают запрос авторизации заголовок, Cloud CDN кэширует только ответы, включающие общедоступный , must-revalidate или директивы управления кешем s-maxage , когда режим кеша установлено значение USE_ORIGIN_HEADERS или CACHE_ALL_STATIC .Это предотвращает случайное кэширование контента для каждого пользователя и/или контента, требующего аутентификация. Режим кэширования FORCE_CACHE_ALL не имеет этого ограничение.

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

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

Инструкции см. в разделе Работа с пользовательским ответом. заголовки.

Пользовательские заголовки ответов не поддерживаются для Cloud CDN развертывания на глобальных внешних балансировщиках нагрузки HTTP(S).

Ключи кэша

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

Для серверных служб Cloud CDN по умолчанию использует полный URI запроса в качестве ключа кэша. Например, https://example.com/images/cat.jpg — это полный URI для конкретный запрос на объект cat.jpg . Эта строка используется по умолчанию кеш-ключ. Только запросы с точно такой строкой совпадают. Запросы на http://example.com/images/cat.jpg или https://example.com/images/cat.jpg?user=user1 не совпадают.

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

Таким образом, для данного внутреннего сегмента следующие URI разрешаются в один и тот же кэшированный объект:

  • http://example.com/images/cat.jpg
  • https://example.com/images/cat.jpg
  • https://example.com/images/cat.jpg?user=user1
  • http://example.com/images/cat.jpg?user=user1
  • https://пример.com/images/cat.jpg?user=user2
  • https://media.example.com/images/cat.jpg
  • https://www.example.com/images/cat.jpg

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

URI часть Настройка Примеры URL-адресов с одинаковым ключом кэша
Протокол Пропустить протокол из ключа кэша.
  • https://example.com/images/cat.jpg
  • http://example.com/images/cat.jpg
Хост Исключить хост из ключа кэша.
  • https://example.com/images/cat.jpg
  • https://example2.com/images/cat.jpg
Строка запроса

Пропустить строку запроса из ключа кэша.

Выборочно опускать или включать части строки запроса.

  • https://example.com/images/cat.jpg?user=user1
  • https://example.com/images/cat.jpg?user=user2

Помимо включения или исключения всей строки запроса, вы можете использовать части строки запроса с помощью списков включения и списков исключения.

Строка запроса включает список

Вы можете выборочно контролировать, какие параметры строки запроса Cloud CDN включает в себя ключи кеша.Например, если вы создаете список включения пользователь , затем https://example.com/images/cat.jpg?user=user1&color=blue создает кеш-ключ https://example.com/images/cat.jpg?user=user1 , который также соответствует https://example.com/images/cat.jpg?user=user1&color=red .

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

Строка запроса включает список ключей кэша Cloud Storage

Предварительный просмотр

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

Примечание. Убедитесь, что вы используете gcloud SDK версии 358.0.0 или более поздней версии.

Включение параметров URL-запроса в ключи кеша для корзин Cloud Storage помогает поддерживать очистку кеша . Очистка кеша — это процесс, позволяющий пользователю найти новую версию загруженного файла, даже если старая версия по-прежнему корректно кэшируется по TTL.

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

Например, вы можете добавить параметр запроса ?version=VERSION или ?hash=HASH . который основан на основном содержании. Это ограничивает необходимость активного делает контент недействительным и согласуется с современными рабочими процессами веб-разработки, где веб- фреймворки и URL-адреса используют хэш содержимого, чтобы избежать обслуживания устаревших объектов. через развертывания.

Поскольку включение параметров запроса в ключ кеша возможно только по желанию, Cloud CDN не поддерживает исключение параметров запроса из ключа кеша. в бэкэнд-ковш.

Строка запроса исключить список

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

С настроенным списком исключений и вводом https://пример.com/images/cat.jpg?user=user1&color=blue , Облачная CDN создает кеш-ключ https://example.com/images/cat.jpg?color=blue , который также соответствует https://example.com/images/cat.jpg?user=user2&color=blue , но не https://example.com/images/cat.jpg?user=user1&color=red .

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

Порядок параметров запроса

Сгенерированный ключ кэша не зависит от порядка параметров запроса.

Например, следующие параметры запроса генерируют один и тот же ключ кэша:

  • info=123&variant=13e&geography=США
  • география=США&вариант=13e&info=123

Предварительный просмотр

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

Примечание. Убедитесь, что вы используете gcloud SDK версии 358.0.0 или более поздней версии.

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

  • Для серверных служб и сегментов: Использовать заголовки HTTP как часть кеша ключей путем включения именованных заголовков в конфигурацию ключа кэша.
  • Только для внутренних служб: Использовать именованные файлы cookie HTTP в качестве ключей кэша, например для A/B (многовариантного) тестирования, канареек и подобных сценариев.
Примечание: Увеличение количества уникальных ключей кэша может снизить частоту попаданий в кэш, особенно если существует большое количество возможных значений.

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

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

Некоторые заголовки не разрешены в ключах кэша, поскольку они обычно очень высокая кардинальность. В большинстве случаев значения этих заголовков либо уникальны для каждого пользователя ( Cookie , Авторизация ), либо имеют тысячи вероятных значения ( Referer , User-Agent , Accept ). Например, заголовок User-Agent может иметь более 5000 уникальных значений, учитывая большое разнообразие браузеров, пользовательские устройства и операционные системы.Эти типы заголовков будут иметь серьезное негативное влияние на частоту попаданий в кэш.

Cloud CDN не позволяет включать следующие заголовки в список заголовков:

  • Принять
  • Принять-кодирование
  • Полномочия , так как это контролируется конфигурацией ( cdnPolicy.includeHost )
  • Авторизация , обычно для каждого пользователя, как в OAuth Bearer токены
  • CDN-петля
  • Соединение
  • Контент-MD5
  • Тип контента
  • Печенье
  • Дата
  • Перенаправлено , часто на клиента или на прокси-сервер
  • Из
  • Хост , так как это контролируется конфигурацией ( cdnPolicy.включитьHost )
  • Если-совпадение , Если-изменено-с , или Если-нет-совпадения
  • Происхождение
  • Прокси-авторизация
  • Ассортимент
  • Реферер (или Реферер )
  • Агент пользователя
  • Обзор потребностей
  • X-CSRFToken и X-CSRF-Token , используемые Django и Ruby on Rails
  • X-Forwarded-For , часто для каждого клиента или прокси-сервера
  • X-User-IP
  • Любой заголовок, начинающийся со следующего:
    • Контроль доступа-, например Access-Control-Request-Headers и Access-Control-Request-Method
    • Sec-Fetch-
    • Секунд-GFE-
    • Секунда-Google-
    • Х-Амз-
    • X-GFE-
    • X-Goog-
    • X-Google-

Примечания:

  • Значения заголовка запроса используются для создания ключа кэша перед любым дополнения или модификации, выполненные по заказу заголовки.
  • Принимаются только допустимые имена полей заголовка HTTP. RFC 7230.
  • Имена полей заголовков нечувствительны к регистру, дубликаты отклоняются.

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

  Мой заголовок: Значение1
Мой заголовок: Value2
  

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

  Мой заголовок: Значение1, Значение2
  

Включая именованные файлы cookie

Предварительный просмотр

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

Примечание. Убедитесь, что вы используете gcloud SDK версии 358.0.0 или более поздней версии.

Файл cookie HTTP представляет собой пару имя=значение , и запрос может включать несколько файлов cookie HTTP, разделенных точкой с запятой в одной строке, или как дискретные заголовки запроса Cookie с одним файлом cookie на заголовок.

Вы можете предоставить список имен файлов cookie (до 3).

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

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

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

Директивы управления кэшем

Директивы управления кешем HTTP влияют на поведение Cloud CDN, как указано выше. в следующей таблице.

Н/Д означает, что директива неприменима к запросу или ответу.

Директива Запрос Ответ
нет в магазине При наличии в запросе Cloud CDN учитывает это и не сохраняет ответ в кеше.

Ответ с no-store не кэшируется.

Это можно переопределить для каждого бэкэнда с помощью FORCE_CACHE_ALL режим кэширования.

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

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

Это можно переопределить для каждого бэкэнда с помощью FORCE_CACHE_ALL режим кэширования.

общественный н/д

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

частный н/д

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

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

максимальный возраст = СЕКУНДЫ Директива запроса max-age игнорируется. Кэшированный ответ возвращается, как если бы этот заголовок не был включен в запрос. Ответ с директивой max-age кэшируется до определенного СЕК .
s-maxage= СЕКУНД н/д

Ответ с директивой s-maxage кэшируется до определенное СЕКУНД .

Если присутствуют как max-age , так и s-maxage , s‑maxage используется Cloud CDN.

Ответы с этой директивой не обслуживаются устаревшими.

s-max-age (два дефиса) недействителен для целей кэширование.

мин-свежий= СЕКУНД Директива запроса min-fresh игнорируется. Кэшированный ответ возвращается, как если бы этот заголовок не был включен в запрос. н/д
max-stale= СЕКУНД

Директива запроса max-stale диктует максимальное устаревание (в секундах), которое клиент готов принять.

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

н/д
stale-while-revalidate= СЕКУНД н/д

Ответ с кодом stale-while-revalidate отправляется клиент до СЕКУНД при этом повторная проверка происходит асинхронно.

Это поведение можно включить для всех ответов, установив cdnPolicy.serveWhileStale на серверной части.

stale-if-error= СЕКУНД Директива запроса stale-if-error игнорируется. Кэшированный ответ возвращается, как если бы этот заголовок не был включен в запрос.

Этот заголовок ответа не имеет никакого эффекта.

необходимо подтвердить н/д

Ответ с must-revalidate повторно проверяется с помощью исходный сервер после истечения срока его действия.

Ответы с этой директивой не обслуживаются устаревшими.

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

Ответ с proxy-revalidate перепроверен с источником сервер после истечения срока его действия.

Ответы с этой директивой не обслуживаются устаревшими.

неизменяемый н/д Нет эффекта. Это передается клиенту в ответе.
без трансформации н/д Cloud CDN не применяет никаких преобразований.
только при кэшировании Директива запроса only-if-cached игнорируется.Кэшированный ответ возвращается, как если бы этот заголовок не был включен в запрос. н/д

Там, где это возможно, Cloud CDN стремится соответствовать требованиям RFC (HTTP RFC). 7234), но предпочитает оптимизировать разгрузку кэша и свести к минимуму влияние, которое клиенты могут иметь по частоте попаданий и/или общей загрузке источника.

Для ответов, использующих заголовок HTTP/1.1 Expires :

  • Значение заголовка Expires должно быть допустимой датой HTTP, поскольку определено в RFC 7231.
  • Значение даты в прошлом, недопустимая дата или значение 0 указывает, что срок действия контента уже истек и требует повторной проверки.
  • Если в ответе присутствует заголовок Cache-Control , Cloud CDN игнорирует заголовок Expires .

Наличие в ответе действительного будущего заголовка Expires позволяет ответ кэшируется и не требует указания других директив кэша.

HTTP/1.0 Заголовок Pragma , если он присутствует в ответе, игнорируется и передается клиенту как есть. Клиентские запросы с этим заголовком передается в источник и не влияет на то, как ответ обслуживается Облачный CDN.

Вари заголовок указывает, что ответ варьируется в зависимости от заголовки запросов. Помимо URI запроса, Cloud CDN учитывает Варьируйте заголовки, которые исходные серверы включают в ответы. Например, если ответ указывает Варьировать: принять , Cloud CDN использует одну запись кэша для запросы с указанием Accept: image/webp,image/*,*/*;q=0.8 и еще один для запросы с указанием Accept: */* .

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

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

Заголовки Vary иногда используются при обслуживании сжатого содержимого. Cloud CDN не сжимает и не распаковывает ответы, но может обслуживать ответы, сжатые исходным сервером. Если ваш исходный сервер выбирает следует ли обслуживать сжатый или несжатый контент в зависимости от значения Accept-Encoding заголовок запроса, убедитесь, что ответ указывает Варьировать: Accept-Encoding .

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

Срок действия записи в кэше определяет, как долго запись в кэше остается действительной. Значение, предоставленное значением s-maxage (или max-age или expires ), позволяет для автоматической повторной проверки устаревшего, созданного пользователями кэшированного контента.

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

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

Режим кэширования влияет на определение свежести.

Режим кэширования Поведение проверки
КЭШ_ВСЕ_СТАТИЧЕСКИЕ Заголовки источника ( Cache-Control: s-maxage , Cache-Control: max-age или Expires заголовки) консультировались, чтобы определить свежесть.Для статического контента, если исходные заголовки нет, настроенный default_ttl определяет свежесть. После того, как статическое содержимое старше default_ttl , Cloud CDN повторно проверяет его.
USE_ORIGIN_HEADERS Каждая запись кэша в кэше Cloud CDN имеет срок действия. определяется Cache-Control: s-maxage , Cache-Control: max-age или Expires заголовки в в соответствии с RFC 7234.
FORCE_CACHE_ALL Вместо заголовков источника настроенный default_ttl определяет свежесть. После того, как содержимое старше default_ttl , Cloud CDN повторно проверяет его.

Если присутствует более одного, Cache-Control: s-maxage принимает приоритет над Cache-Control: max-age и Cache-Control: max-age имеет приоритет над Expires .

По умолчанию, когда значение срока действия превышает 30 дней (2 592 000 секунд), Cloud CDN обрабатывает значение истечения срока действия, как если бы оно составляло 2 592 000 секунды. Нижестоящие клиенты по-прежнему видят точные значения max-age и s-maxage , даже если они превышают 30 дней.

Выселение

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

Для получения дополнительной информации см. Выселение и истечение срока.

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

  • Ранее кэшированный ответ имеет заголовок Last-Modified или ETag .
  • Клиентский запрос является запросом GET , который не содержит Заголовки If-Modified-Since или If-None-Match .

Cloud CDN выполняет эту проверку немного по-разному в зависимости от был ли ответ кэширован с использованием диапазона байтов запросы:

  • Если ответ был кэширован с использованием запросов диапазона байтов, Cloud CDN инициирует отдельный запрос проверки, который включает If-Modified-Since и/или заголовки If-None-Match .
  • В противном случае Cloud CDN добавляет If-Modified-Since и/или Заголовки If-None-Match к запросу клиента и пересылают измененный запрос к бэкенду.

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

Если ранее кэшированный ответ не имеет Last-Modified или ETag заголовок, Cloud CDN игнорирует запись кэша с истекшим сроком действия и пересылает клиентский запрос к серверной части без изменений.

Поддержка запросов диапазона байтов

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

  • Код состояния: 200 OK или 206 Частичное содержимое
  • Заголовок: Допустимые диапазоны: байты
  • Заголовок: Content-Length и/или Content-Range
  • Заголовок: Last-Modified и/или ETag с надежным средством проверки

Облачное хранилище поддерживает запросы диапазона байтов для большинства объектов.Тем не мение, Облачное хранилище не поддерживает запросы диапазона байтов для объектов с Content-Encoding: метаданные gzip , если запрос клиента не включает Accept- Кодировка: заголовок gzip . Если у вас есть объекты Cloud Storage размером более 10 МБ, убедитесь, что в них нет Content-Encoding: gzip метаданные. Сведения о том, как редактировать метаданные объекта, см. в разделе Просмотр и редактирование метаданных объекта.

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

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

  • Тело ответа неполное, так как клиент запросил только часть содержание.
  • Размер тела ответа превышает 1 МБ (1 048 576 байт).

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

При промахе кэш проверяет, поддерживает ли исходный сервер запросы диапазона байтов. Если известно, что запросы диапазона байтов поддерживаются для cache, кэш не перенаправляет запрос клиента на внешний балансировщик нагрузки HTTP(S).Вместо этого кеш инициирует собственное заполнение кеша диапазона байтов. запросы на недостающие части контента. Если ваш исходный сервер возвращается запрошенный диапазон байтов в ответе 206 Partial Content , кэш может сохранить этот диапазон для будущих запросов.

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

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

Свертывание запроса (объединение)

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

Свертывание запроса включено по умолчанию.

Свернутые запросы ведут себя следующим образом:

  • Свернутые запросы регистрируют как клиентский запрос, так и (свернутый) запрос на заполнение кеша.
  • Лидер свернутого сеанса используется для создания запрос заполнения происхождения.
  • Атрибуты запроса, которые не являются частью ключа кэша, например заголовок User-Agent или Accept-Encoding , отражают только лидер свернутой сессии.
  • Запросы, которые не имеют одного и того же ключа кэша, не могут быть свернуты.

На следующей диаграмме показано, как объединяются запросы:

Cloud CDN с включенным свертыванием запросов (нажмите, чтобы увеличить)

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

Cloud CDN без включения свертывания запросов (нажмите, чтобы увеличить)

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

В следующей таблице представлены поведение по умолчанию и возможности настройки для различные типы запросов.

Тип запроса Поведение по умолчанию Конфигурируемый Преимущества разрушения
Запросы блоков Включено Может значительно уменьшить пропускную способность источника
Запросы товаров Включено Да Можно уменьшить объем запроса источника

Для отключить свертывание запроса элемента с помощью Cloud SDK для внутреннего сегмента который ссылается на корзину облачного хранилища:

Примечание. Cloud SDK поддерживает флаг --request-coalescing . в Cloud SDK версии 330.0.0.

gcloud

Используйте команду gcloud computing backend-services или backend-buckets :

Обновление серверных служб вычислений gcloud  BACKEND_SERVICE_NAME  \
    --no-запрос-объединения
 

Чтобы включить свертывание запроса элемента в бэкэнд-базе с помощью Cloud SDK:

gcloud

Используйте команду gcloud computing backend-buckets :

Обновление вычислительных серверных блоков gcloud  BACKEND_BUCKET_NAME  \
    --request-объединение
 

Чтобы включить свертывание запроса элемента с помощью Cloud SDK для серверной службы, включая группы ВМ и внешние серверные части:

gcloud

Используйте команду gcloud computing backend-services :

Обновление серверных служб вычислений gcloud  BACKEND_SERVICE_NAME  \
    --request-объединение
 

запросов, инициированных Cloud CDN

Если исходный сервер поддерживает запросы диапазона байтов, Cloud CDN может отправлять несколько запросов на исходный сервер в ответ на один запрос клиента.Cloud CDN может инициировать два типа запросы: запросы проверки и запросы диапазона байтов.

Если ответ, указывающий, что исходный сервер поддерживает запросы диапазона байтов для определенного ключа кэша истек, Cloud CDN инициирует запрос проверки, чтобы подтвердить, что содержимое не изменилось и что ваш Исходный сервер по-прежнему поддерживает запросы диапазона для содержимого. Если ваше происхождение сервер отвечает ответом 304 Not Modified , Cloud CDN продолжает обслуживать контент, используя диапазоны байтов.В противном случае, Cloud CDN перенаправляет ответ исходного сервера на клиент. Вы контролируете время истечения срока действия с помощью Cache-Control и Expires . заголовки ответов.

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

Каждый запрос диапазона байтов, инициированный Cloud CDN, указывает диапазон который начинается со смещения, кратного 2 097 136 байтам. С возможным за исключением последнего диапазона, каждый диапазон также составляет 2 097 136 байт. Если содержимое не кратно этому размеру, конечный диапазон меньше. То размер и смещения, используемые в запросах диапазона байтов, могут измениться в будущем.

В качестве примера рассмотрим запрос клиента на байты от 1 000 000 до 3 999 999. содержимого, которого нет в кеше.В этом примере Cloud CDN может инициировать два запроса GET, один для первого 2 097 136 байт содержимого и еще один для вторых 2 097 136 байт. Этот приводит к 4 194 272 байтам заполнения кеша, хотя клиент запросил только 3 000 000 байт.

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

Когда Cloud CDN инициирует запрос проверки или диапазон байтов запроса, он не включает заголовки, специфичные для клиента, такие как Cookie или Агент пользователя .

В облаке поле httpRequest.userAgent , Cloud-CDN-Google означает, что Cloud CDN инициировал запрос.

Обход кэша

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

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

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

Прежде чем начать

  • Убедитесь, что Cloud CDN включен; инструкции см. Использование облачного CDN.

  • При необходимости обновите Cloud SDK до последней версии:

    обновление компонентов gcloud
     
    Примечание. Убедитесь, что вы используете gcloud SDK версии 324.0.0 или более поздней версии.

Настройка обхода кэша

Можно указать до пяти имен заголовков HTTP.Значения нечувствительны к регистру. Имя заголовка должно быть допустимым полем заголовка HTTP. токен. Имя заголовка не должно появляться более одного раза в списке добавленных заголовков. За правила допустимых имен заголовков см. в разделе Как использовать настраиваемые заголовки Работа.

Консоль

  1. В Google Cloud Console перейдите на страницу Балансировка нагрузки .

    Перейти на страницу балансировки нагрузки

  2. Щелкните имя вашего внешнего балансировщика нагрузки HTTP(S).
  3. Нажмите Редактировать Редактировать.
  4. В конфигурации серверной части выберите серверную часть и нажмите Изменить редактировать.
  5. Убедитесь, что выбран параметр Включить Cloud CDN .
  6. В нижней части окна нажмите Расширенные настройки .
  7. В разделе Обход кеша в заголовке запроса щелкните Добавить заголовок .
  8. Введите имя заголовка, например Pragma или Authorization .
  9. Щелкните Обновить .
  10. Щелкните Обновить еще раз.

gcloud

Для серверных сегментов используйте серверные сегменты вычислений gcloud. создать или Gcloud вычисляет бэкэнд-сегменты команда обновления с флагом --bypass-cache-on-request-headers .

Для серверных служб используйте серверные службы вычислений gcloud. создать или серверные службы вычислений gcloud команда обновления с флагом --bypass-cache-on-request-headers .

бэкэнд-бакеты вычислений gcloud (создать | обновить)  BACKEND_BUCKET_NAME 
    --bypass-cache-on-request-headers=  BYPASS_REQUEST_HEADER 
 
серверные службы вычислений gcloud (создать | обновить)  BACKEND_SERVICE_NAME 
    --bypass-cache-on-request-headers=  BYPASS_REQUEST_HEADER 
 

Например:

бэкэнд-сервисы вычислений gcloud обновить мою бэкэнд-службу
    --bypass-cache-on-request-headers=Прагма
    --bypass-cache-on-request-headers=Авторизация
 

API

Для внутренних сегментов используйте Метод: backendBuckets.вставлять, Метод: backendBuckets.update, или метод: backendBuckets.patch вызов API.

Для серверных служб используйте Метод: backendServices.insert, Метод: backendServices.update, или Метод: backendServices.patch вызов API.

Например:

ИСПРАВЛЕНИЕ https://compute.googleapis.com/compute/v1/projects/  PROJECT_ID  /global/backendBuckets
 

Добавьте следующий фрагмент в тело запроса JSON:

"cdnPolicy": {
  "обойти заголовкиCacheOnRequestHeaders": [
    {
      "имя_заголовка": строка
    }
  ]
}
 

Отключение обхода кэша

Что дальше

Кэширование в Swift | Swift by Sundell

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

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

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

Essential Developer: Если вы iOS-разработчик среднего и старшего звена и хотите повысить как свои навыки, так и уровень своей зарплаты, присоединяйтесь к ускоренному курсу iOS Architect, который начнется 31 января. Это на 100% бесплатно и проводится полностью онлайн. Нажмите, чтобы узнать больше.

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

К счастью, Apple уже решила многие из этих проблем для нас с помощью встроенного класса NSCache . Тем не менее, его использование связано с несколькими оговорками, так как это все еще класс Objective-C на собственных платформах Apple — это означает, что он может хранить только экземпляры класса и совместим только с ключами на основе NSObject :

 
let cache = NSCache()  

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

Первое, что мы сделаем, это объявим наш новый тип кэша. Давайте назовем его Cache и сделаем его универсальным для любого типа ключа Hashable и любого типа значения. Затем мы дадим ему свойство NSCache , в котором будут храниться экземпляры Entry с ключом WrappedKey type:

  final class Cache {
    частный пусть завернутый = NSCache()
}  

Наш тип WrappedKey , как следует из его названия, будет обертывать наши общедоступные значения Key , чтобы сделать их NSCache совместимыми.Для этого создадим подкласс NSObject и реализуем hash и isEqual — так как это то, что использует Objective-C для определения равенства двух экземпляров:

  private extension Cache {
    конечный класс WrappedKey: NSObject {
        пусть ключ: ключ

        инициализация (_ ключ: ключ) { self.key = ключ }

        переопределить var hash: Int { return key.hashValue }

        переопределить func isEqual(_ object: Any?) -> Bool {
            охранять пусть значение = объект как? WrappedKey еще {
                вернуть ложь
            }

            возвращаемое значение.ключ == ключ
        }
    }
}  

Когда дело доходит до нашего типа Entry , единственным требованием является то, что он должен быть классом (он не должен быть подклассом NSObject ), что означает, что мы можем просто заставить его хранить значение Экземпляр :

  Кэш частного расширения {
    окончательная запись класса {
        пусть значение: Значение

        инициализация (значение: значение) {
            самостоятельная ценность = ценность
        }
    }
}  

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

  final class Cache {
    частный пусть завернутый = NSCache()

    функция вставки (_ значение: значение, ключ forKey: ключ) {
        пусть запись = запись (значение: значение)
        wrapped.setObject (запись, forKey: WrappedKey (ключ))
    }

    значение функции (ключ forKey: ключ) -> значение? {
        пусть запись = завернута.объект (forKey: WrappedKey (ключ))
        вернуть запись?.значение
    }

    func removeValue (ключ forKey: ключ) {
        завернутый.removeObject (forKey: WrappedKey (ключ))
    }
}  

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

  extension Cache {
    индекс (ключ: ключ) -> значение? {
        получить {возвращаемое значение (forKey: ключ)}
        набор {
            охранять пусть значение = новое значение еще {
                
                удалить значение (для ключа: ключ)
                возвращение
            }

            вставить (значение, forKey: ключ)
        }
    }
}  

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

  class Загрузчик статей {
    typealias Handler = (Result) -> Void

    private let cache = Cache()

    func loadArticle(withID id: Article.ID,
                     затем обработчик: @escaping Handler) {
        если пусть кешируется = cache[id] {
            обработчик возврата (.успех (кэш))
        }

        PerformLoading {[weak self] приводит к
            пусть статья = попробовать? результат.получить()
            article.map { сам?.cache[id] = $0}
            обработчик (результат)
        }
    }
}  

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

Может показаться, что приведенное выше не сильно повлияет на производительность нашего приложения, но оно действительно может сделать наше приложение более быстрым, например, когда пользователь вернется к уже загруженной статье — оно теперь немедленно быть там.Если мы также объединим вышеуказанное с предварительной загрузкой статей, которые пользователь может открыть (например, последней статьи в любимой категории пользователя), то мы могли бы сделать наше приложение намного более приятным в использовании.

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

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

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

  final class Entry {
    пусть значение: Значение
    пусть expireDate: Дата

    инициализация (значение: значение, expireDate: дата) {
        себя.значение = значение
        self.expirationDate = Дата истечения
    }
}  

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

  final class Cache {
    частный пусть завернутый = NSCache()
    частный пусть dateProvider: () -> Дата
    частное разрешение entryLifetime: TimeInterval

    init(dateProvider: @escaping() -> Date = Date.в этом,
         entryLifetime: TimeInterval = 12 * 60 * 60) {
        self.dateProvider = dateProvider
        self.entryLifetime = время жизни записи
    }
    
    ...
}  

Чтобы узнать больше о вышеупомянутом виде внедрения зависимостей, ознакомьтесь с «Простое внедрение зависимостей Swift с функциями».

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

  func insert(_ value: Value, forKey key: Key) {
    пусть дата = dateProvider().добавлениеTimeInterval (entryLifetime)
    пусть запись = запись (значение: значение, expireDate: дата)
    wrapped.setObject (запись, forKey: WrappedKey (ключ))
}

значение функции (ключ forKey: ключ) -> значение? {
    охранять пусть запись = завернутый.object(forKey: WrappedKey(key)) else {
        вернуть ноль
    }

    Guard dateProvider() < entry.expirationDate else {
        
        удалить значение (для ключа: ключ)
        вернуть ноль
    }

    вернуть запись.значение
}  

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

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

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

  final Запись класса {
    пусть ключ: ключ
    пусть значение: Значение
    пусть expireDate: Дата

    инициализация (ключ: ключ, значение: значение, expireDate: дата) {
        self.key = ключ
        самостоятельная ценность = ценность
        self.expirationDate = Дата истечения
    }
}  

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

  private extension Cache {
    конечный класс KeyTracker: NSObject, NSCacheDelegate {
        var keys = Установить<Ключ>()

        func cache(_ cache: NSCache,
                   Объект willEvictObject: Любой) {
            охранять пусть запись = объект как? Введите еще {
                возвращение
            }

            ключи.удалить (вход.ключ)
        }
    }
}  

Мы настроим наш KeyTracker при инициализации Cache — и мы также установим максимальное количество записей, что поможет нам избежать записи слишком большого количества данных на диск — например:

  final class Cache {
    частный пусть завернутый = NSCache()
    частный пусть dateProvider: () -> Дата
    частное разрешение entryLifetime: TimeInterval
    частный пусть keyTracker = KeyTracker()

    init(dateProvider: @escaping() -> Date = Date.в этом,
         entryLifetime: TimeInterval = 12*60*60,
         максимальное количество записей: Int = 50) {
        self.dateProvider = dateProvider
        self.entryLifetime = время жизни записи
        wrapper.countLimit = максимальное количество записей
        wrapper.delegate = keyTracker
    }
    
    ...
}  

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

  функция вставки (_ значение: значение, ключ forKey: ключ) {
    ...
    keyTracker.keys.insert(ключ)
}  

Чтобы действительно сохранить содержимое нашего кеша, нам сначала нужно его сериализовать. Точно так же, как мы использовали NSCache для создания нашего собственного API кэширования прямо поверх системы, давайте используем Codable , чтобы наш кеш можно было кодировать и декодировать с использованием любого совместимого формата (например, JSON).

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

  extension Cache.Запись: Codable, где Key: Codable, Value: Codable {}  

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

  private extension Cache {
    func entry(forKey key: Key) -> Entry? {
        охранять вход = завернутый.объект (forKey: WrappedKey (ключ)) еще {
            вернуть ноль
        }

        Guard dateProvider() < entry.expirationDate else {
            удалить значение (для ключа: ключ)
            вернуть ноль
        }

        обратная запись
    }

    функция вставки (_ запись: запись) {
        wrapped.setObject(запись, forKey: WrappedKey(entry.key))
        keyTracker.keys.insert(entry.key)
    }
}  

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

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

        пусть контейнер = попробуйте decoder.singleValueContainer()
        пусть записи = попробуйте container.decode([Entry].self)
        записи.forEach(вставить)
    }

    func encode (для кодировщика: кодировщик) выдает {
        контейнер var = encoder.singleValueContainer()
        попробуйте container.encode(keyTracker.keys.compactMap(entry))
    }
}  

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

  Кэш расширения, где Ключ: Кодируемый, Значение: Кодируемый {
    функция saveToDisk(
        Имя withName: Строка,
        используя файловый менеджер: FileManager = .дефолт
    ) бросает {
        пусть folderURLs = fileManager.urls(
            для: .cachesDirectory,
            в: .userDomainMask
        )

        let fileURL = folderURLs[0].appendingPathComponent(имя + ".cache")
        пусть данные = попробуйте JSONEncoder (). кодировать (сам)
        попробуйте data.write(в: fileURL)
    }
}  

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

Essential Developer: Если вы iOS-разработчик среднего и старшего звена и хотите повысить как свои навыки, так и уровень своей зарплаты, присоединяйтесь к ускоренному курсу iOS Architect, который начнется 31 января. Это на 100% бесплатно и проводится полностью онлайн. Нажмите, чтобы узнать больше.

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

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

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

Что вы думаете? Как вы обычно используете кеширование в Swift и предпочитаете ли вы NSCache , URLCache или полностью кастомное решение? Дайте мне знать — вместе с вашими вопросами, комментариями и отзывами — либо в Твиттере, либо по электронной почте.

Спасибо за внимание! 🚀

Создать кэш карты—ArcGIS Server

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

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

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

Прежде чем начать

Если вы только что установили ArcGIS Server, вам необходимо выполнить некоторые подготовительные шаги, прежде чем вы сможете подключиться к серверу в ArcMap и услуги публикации:

Автор карты

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

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

Укажите систему координат

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

  1. Запустите ArcMap и откройте новый пустой документ карты.
  2. В таблице содержания ArcMap щелкните правой кнопкой мыши имя фрейма данных (по умолчанию — Слои) и выберите Свойства.
  3. Перейдите на вкладку Система координат и выберите систему координат, которую вы хотите использовать для своей карты.
  4. Нажмите OK.

Дизайн карты

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

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

  1. Оставаясь в ArcMap, добавьте свои наборы данных и уменьшите масштаб до самого дальнего (наименьшего) масштаба.При необходимости исправьте любые проблемы с проекцией. Все ваши наборы данных должны использовать одну и ту же проекцию для правильного кэширования.
  2. Установите символы и маркировку слоев для этого масштаба.
    Совет:

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

  3. Увеличьте масштаб до следующего ближайшего масштаба и установите символы и маркировку слоев для этого масштаба.
    Совет:

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

  4. Создавайте групповые слои, чтобы отслеживать копии ваших слоев. Проще всего создать один групповой слой для каждого масштаба. Таким образом, вам нужно установить зависимость масштаба только от группы, а не от каждого отдельного слоя.Вы можете даже включить шкалу в название.
  5. Задайте диапазон масштаба для каждого составного слоя, чтобы на каждом кэшированном масштабе отображался только один слой. Настройте диапазон масштаба с допуском вокруг каждого масштаба кэша. Например, если один из групповых слоев будет кэширован с масштабом 1:577 791, вы можете сделать слой видимым только при уменьшении масштаба более 1:866 686 и увеличении масштаба более 1:433 343.
  6. Продолжайте приближаться к каждому последующему масштабу и использовать соответствующие символы, пока не проработаете все масштабы в списке масштабов.
  7. Сохраните карту. Вы готовы опубликовать карту.

Опубликуйте карту и создайте кэш

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

  1. Откройте документ карты в ArcMap и выберите в главном меню Файл > Опубликовать как > Сервис.
  2. В окне «Поделиться как сервис» выберите «Опубликовать сервис».Нажмите "Далее.
  3. В диалоговом окне «Публикация сервиса» щелкните Подключиться к ArcGIS Server, чтобы создать новое подключение к серверу.
  4. В окне Добавить ArcGIS Server выберите Опубликовать ГИС-сервисы. Нажмите "Далее.
  5. В поле URL-адрес сервера введите URL-адрес сайта ArcGIS Server, к которому вы хотите подключиться. URL-адрес будет иметь формат http://gisserver.domain.com:6443/arcgis.
  6. В раскрывающемся списке Тип сервера выберите ArcGIS Server.
  7. Введите имя пользователя и пароль с правами как минимум издателя на ArcGIS Server.Если вы не настроили пользователей и роли для обеспечения безопасности, один из вариантов — использовать учетную запись основного администратора сайта, которую вы определили при создании сайта. Оставьте флажок установленным, чтобы сохранить имя пользователя и пароль. Затем нажмите Готово.
  8. При необходимости в окне «Публикация службы» введите новое имя для службы. Нажмите "Далее.
  9. По умолчанию сервисы публикуются в корневую папку (root) ArcGIS Server. Службы могут быть организованы в подпапки в корневой папке. Выберите папку, в которой вы хотите опубликовать службу, или создайте новую папку для службы.Нажмите «Продолжить».
  10. Отображается Редактор служб. Вы будете использовать Редактор сервисов, чтобы выбрать, что пользователи могут делать с вашим кэшированным картографическим сервисом, определить схему кэширования и детально контролировать то, как сервер будет отображать ваш сервис. Щелкните вкладку Кэширование.
  11. На вкладке Кэширование выберите отрисовку картографического сервиса с использованием плиток из кэша.
  12. В раскрывающемся списке Схема листов выберите схему листов для кэша. Схема листов определяет масштабы, в которых будут создаваться листы, и границы ваших листов.Он содержит информацию о системе координат кэша и некоторых других свойствах. Существует несколько способов выбора схемы листов:
    • Если вы хотите использовать ту же схему листов, что и кэши ArcGIS Online, Bing Maps и Google Maps, выберите ArcGIS Online / Bing Maps / Google Maps. Данные на вашей карте будут перепроецированы на лету в требуемую систему координат этой схемы листов, которой является WGS 1984 Web Mercator (Auxiliary Sphere).
    • Если вы хотите использовать ту же схему листов, что и кэши WGS84 Geographic версии 2, выберите Файл схемы листов и перейдите в папку C:\Program Files (x86)\ArcGIS\Desktop10.5\TilingSchemes\WGS84_Geographic_Coordinate_System_V2.xml. Данные на вашей карте будут перепроецированы на лету в требуемую систему координат этой схемы листов, которой является WGS 1984.
    • Если вы хотите использовать собственную схему листов, выберите Файл схемы листов и перейдите к XML-схеме листов. файл, созданный с помощью инструмента Создать схему листов кэша картографического сервера.
    • Если вы хотите использовать ту же схему листов, что и другой существующий картографический сервис, выберите Существующий кэшированный сервис карт/изображений и перейдите к сервису.
    • Если вы хотите, чтобы ArcGIS предложил вам несколько масштабов, щелкните Предложить и введите необходимое количество масштабов. Этот вариант рекомендуется только для экспериментальных или тестовых целей. В большинстве случаев вы уже разработали карту с учетом определенного набора уровней масштаба.
  13. С помощью ползунков установите свойство «Уровни детализации».

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

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

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

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

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

  16. При необходимости настройте другие свойства на вкладке «Дополнительные параметры».Эти настройки описаны в разделе Доступные свойства кэша карт и изображений. Вы также сможете редактировать свойства кэширования сервиса в ArcGIS Server Manager после публикации.
  17. Щелкните Анализ . Это проверяет ваш документ карты, чтобы увидеть, можно ли его опубликовать на сервере.
    Совет:

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

  18. Исправление любых ошибок в окне «Подготовка»; это необходимо сделать, прежде чем вы сможете опубликовать свою карту как услугу.При желании вы можете исправить предупреждения и информационные сообщения, чтобы еще больше улучшить производительность и внешний вид вашего сервиса. Дополнительные сведения об устранении этих проблем см. в разделе Анализ вашего ГИС-ресурса.

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

  19. При необходимости в Редакторе служб щелкните Предварительный просмотр. Это может дать вам представление о том, как ваша карта будет выглядеть при просмотре в Интернете. Дополнительные сведения см. в разделе Предварительный просмотр карты.
  20. Если вы создаете новую службу, нажмите «Опубликовать», когда будете готовы к публикации.Если вы редактируете существующую службу, нажмите «ОК», чтобы сохранить изменения.

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

  21. Если вы выбрали создание кэша вручную, щелкните правой кнопкой мыши свой сервис в окне Каталог и выберите Управление кэшем > Управление листами.Отобразится инструмент «Управление листами кэша картографического сервера», который можно запустить с использованием выбранных масштабов и областей интереса. Вы можете выполнить асинхронное кэширование, сняв флажок с параметра Дождаться завершения задания в инструменте Управление листами кэша картографического сервера.

Проверка кэша

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

Веб-приложение, которое вы используете для тестирования, может быть простым. Хороший способ проверить кеш карты — использовать приложение просмотра JavaScript, доступное в ArcGIS Server Services Directory.

  1. В веб-браузере перейдите в каталог служб. URL-адрес будет иметь формат http://gisserver.domain.com:6080/arcgis/rest/services.
  2. В списке сервисов выберите свой картографический сервис. Все картографические сервисы добавляются (MapServer). Если ваша служба находится в папке, перейдите в эту папку и найдите службу.
  3. Отображается страница с названием службы, описанием службы и списком слоев. Щелкните Просмотреть в: ArcGIS JavaScript. Появится окно с простым веб-приложением JavaScript.
  4. Перемещайтесь по карте и увеличивайте масштаб до различных уровней. При панорамировании и масштабировании карты вы должны увидеть, что фрагменты карты появляются очень быстро.

Устранение неполадок

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

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

  1. Щелкните правой кнопкой мыши внутри веб-приложения и выберите «Просмотр информации о странице».

    Leave a comment