Метод альтернативного кэширования для.htaccess. Что такое кэш браузера

Подробная информация о SharePoint BLOB кэше, кэше вывода страниц и кэше объектов.

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

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

Любая установка SharePoint Server состоит из экземпляра Microsoft SQL Server и как минимум одного Web Front-End сервера. Когда пользователи запрашивают с SharePoint Server данные, (например, страницу или документ) WFE сервер получает из SQL все необходимые данные и на основе их обрабатывает пользовательский запрос. И хотя это гарантирует пользователю получение самой актуальной информации, такая ситуация сказывается на повышенном трафике между SQL и WFE серверами, что в свою очередь влияет на скорость работы конечного пользователя.

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

BLOB кэш.

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

Когда вы разрабатываете веб сайты SharePoint, существует несколько мест хранения содержимого страниц. Они могут храниться на файловой системе WFE сервера (обычно в директории _layouts) или в библиотеке SharePoint. Файлы, которые хранятся в каталоге _layouts могут быть считаны с диска достаточно быстро, но если файлы необходимо обновить, администратор должен изменить их на каждом WFE сервере. Хранение в библиотеке SharePoint дает свои преимущества, теперь не только администраторы фермы могу добавлять и обновлять содержимое, но и пользователи. Но поскольку все что хранится в библиотеке находится в SQL , а за счет извлечения данных из SQL скорость получения их будет ниже. Итак, при хранении файла в SharePoint и использовании кэша BLOB, доступ к содержимому предоставляется быстро при этом существует возможность централизованного управления.

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

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

Как уже было сказано BLOB кэш особенно полезен при кэшировании больших мультимедийных файлов. Сам SharePoint оптимизирован для работы с небольшими файлами. Он может обработать файлы меньше FileReadChunkSize (100KB) за одно обращение, а файлы до 5 MB LargeFileChunkSize подаются непосредственно с SQL без дисковой буферизации с низкой задержкой. Файлы больше 5 MB SharePoint буферизирует на диске WFE сервера до возврата пользователю. Это бережет память, но сказывается на задержке возврата. BLOB кэш может уменьшить задержку в этой ситуации. Когда файл закэширован в BLOB он возвращается также быстро, как будто он находится непосредственно на IIS.

Еще одно преимущество BLOB кэша заключается в предоставлении возможности осуществлять HTTP запрос части файла вместо запроса его целиком. Например, если браузеру нужен только 1МВ из 10МВ файла, он может сделать запрос и получить из кэша только 1 МВ. При отключенном BLOB кэше SharePoint Server игнорирует подобные запросы (в англ. документации они называются HTTP range request) и возвращает полный размер запрашиваемого файла. Получается, что BLOB кэша увеличивает производительность сети, за счет минимизации сетевой нагрузки.

Наибольшую пользу от таких частичных HTTP запросов (HTTP range request) получат клиентские медиа плееры. Неважно будет это Windows Media Player или Silverlight встроенный в веб страницу, при переводе ползунка –перемотки видео вперед BLOB кэш будет возвращать требуемую часть файла без полной загрузки его на клиента.

Логическая архитектура и расположение.

BLOB кэш работает на каждом WFE сервере фермы. Точнее каждое веб-приложение и каждый виртуальный сервер имеем собственный BLOB кэш. В данном случае под виртуальным сервером подразумевается IIS Web Site, ну а в SharePoint Server, как правило, каждое веб-приложение связано с одним виртуальным сервером. В один момент времени на одном виртуальном сервере может работать только один экземпляр BLOB кэша. Это значит что BLOB кэш не может быть использован с Веб-садом. (Веб-сад или web garden это пул приложений, который использует для обработки запросов более одного процесса запросов более одного процесса w3wp.exe)

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

Механизм наполнение кэша.

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

Кэш BLOB может обрабатывать несколько запросов к одному файлу через доступность данных в кэше для всех запросов. Это происходит, даже если файл не был еще полностью получен из SQL Server. Например, ссылка на видео доклада (500MB), хранящегося на SharePoint Server, рассылается по электронной почте сотрудникам компании. Если одновременно большое количество пользователей перейдет по ссылке, то при отключенном кэше к SQL Server будет осуществлено множество запросов. (по одному для каждого пользователя) Не трудно догадаться как это скажется на производительности. С включённым кэшем, видео будет получено из SQL единожды каждым WFE сервером и даже если оно не успеет закэшироваться полностью, будет использовано для обслуживания всех запросов. Вывод напрашивается сам собой – BLOB кэш необходимым для обслуживания больших файлов на сервере SharePoint.

Хранение данных и размер кэша на диске.

Т.к вам не следует править какие либо из кэш файлов вручную, понимание структуры хранения данных BLOB кэша на диске полезно как минимум с точки зрения теории. BLOB кэш хранит свои файлы на диске в структуре, которая повторяет структуру вашего портала. Например, файл на портале с URL http://contoso/sites/publishing/documents/somefile.jpg будет храниться на диске приблизительно по такому пути c:\BlobCache\14\11111111\AB25499AF39572\sites\publishing\documents\somefile-1238DEF8097AB.jpg. В данном пути присутствуют случайные части строки, сделано это для предотвращения перезаписи старой версии файла более новой, поскольку старый файл в этот еще момент еще может использоваться. Имя узла, где находится файл, заменяется в ссылке уникальной строкой, что предотвращает конфликты при кэшировании двух файлов с адресами типа http://contoso/images/logo.jpg и http://northwinds/images/logo.jpg.

В операционной системе Windows присутствует ограничение в 260 символов в пути для файла. Поскольку BLOB кэш добавляет дополнительные уникальные строк в пути файлов кэша, то вполне реальна ситуация когда при записи файла на диск этот предел будет превышен. Поэтому нужно постараться избегать чрезмерно длинных URL на портале SharePoint. Если придерживаться рекомендации, то для нормального кэширования файлов не следует делать ссылки на портале длиннее 160 символов.

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

Стойкость BLOB кэша при перезапуске пула приложений.

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

Механизм проверки кэша.

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

Для BLOB кэша также настраивается максимальный размер, дабы избежать излишнего расходования свободного места на диске. Когда суммарные размер файлов в кэше превышает установленные ограничения, BLOB кэш удаляет наименее используемые файлы до тех пор пора вес закэшированных файлов не понизится до 70% от разрешенного объёма. Этот процесс называется уплотнением. Уплотнение достаточно «дорогой» процесс с точки зрения производительности, связано это возможным повторным кэшированием удаленных файлов. Периодический запуск уплотнения позволяет избавиться от «непопулярных» файлов и освободить место для более часто используемых. Если уплотнение происходит часто, о это говорит только о нехватке места под кэш, посмотреть периодичность этой операции можно по счетчику“Total number of cache compactions” в группе SharePoint Disk-Based Cache. Выделение дополнительного места при частом уплотнении является хорошим решением, в идеальных условиях размера кэша должно хватать для помещения всех популярных запросов.

Другой способ удаление закэшированных файлов это сброс кэша. Когда кэш сбрасывается, создается новая папка, но старый кэш остается. Это позволяет завершить существующие запросы к старому кэшу. Старый кэш удаляется позже через определенное время. (конфигурируемый интервал) Кэш может быть сброшен по нескольким причинам: если при запуске индекс не смогу произвести корректную десериализацию, изменилась пользовательская политика для веб-приложения, не может быть прочитана контентная база данных. Так же кэш может быть очищен вручную при вызове из PowerShell функции Microsoft.SharePoint.Publishing.PublishingCache.FlushBlobCache().

Аутентификация и BLOB кэш.

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

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

1. К сайту разрешен анонимный доступ

2. Часто запрашиваемые файлы хранятся в библиотеках, у которых включен параметр AllowEveryoneViewItems.

При создании портала на основе шаблона Publishing Portal создается две библиотеки с установленным параметром AllowEveryoneViewItems. Это библиотеки “Images” и “Site Collection Images”. В любом случае даже если не используется анонимный доступ BLOB кэш будет работать, но WFE серверу придется обращаться на SQL сервер для проверки пользовательских разрешений. (ACL)

Продолжение следует….

MCT/MVP Илья Рудь

Основан на документе “SharePoint Server Caches Overview ”

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

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

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

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

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

Как очистить кэш?

Существуют два основных способа очистки кэша.

1. Запуск базы 1С с использованием параметра «/ClearCache»

Данный метод очень прост. В окне выбора информационной базы выберите ту, чей кэш нужно очистить. Нажмите кнопку «Изменить».

В последнем окне Редактирования информационной базы задайте параметр запуска «/ClearCache». Нажмите «Готово» и запустите информационную базу.

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

2. Очистка кэша 1С вручную

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

• C:\Users\Username\AppData\Roaming\1C и C:\Users\Username\AppData\Local\1C в папках, начинающихся с «1cv8».
• В Windows XP, в папке пользователя по адресу Local Settings\Application Data\1C\.
• Если папка AppData не видна, то нужно настроить видимость скрытых папок.

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

Для очистки кэша нужно удалить эти папки.

Важно! Удалять папки можно только тогда, когда завершены процессы работы с 1С:Предприятие.

3. Очистка кэша в 1С на сервере или пользовательском ПК с помощью готовых скриптов

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

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

4. Дополнительно

Если после использования вышеописанных способов очистки кэша ошибка, например “Не верный формат хранилища данных “, все равно сохраняется, то рекомендуют остановить и вручную чистить папку reg_1541/SNCCNTX. Она расположена на компьютере центрального сервера 1С:Предприятия в каталоге <рабочий каталог кластера> / <идентификатор информационной базы>.

Например:

Будьте внимательны, в этой папке можно чистить не все. Перечислю что чистить можно:

• 1CV8Reg.lst – реестр кластера (в нем хранятся список зарегистрированных информационных баз, рабочие сервера и процессы, соответствие кластера и доп. менеджера, список админов.)
• srvribrg.lst – список кластеров (зарегистрированные кластеры и админы центрального сервера)
• 1cv8ftxt – данные полнотекстового поиска. Они лежат на центральном сервере 1с: рабочий каталог кластера-идентификатор информационной базы
• 1Cv8Log – журнал регистрации базы *.lgp и *.lgf.

Важно иметь ввиду, что после очистки кэша запуск 1С немного замедлится.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

17.04.1999 Фил Кеппелер

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

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

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

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

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

Кэш-серверы IP являются для HTTP тем же, чем было зеркальное копирование для архивных протоколов. Все кэш-серверы базируются, по сути, на одних и тех же принципах: они перехватывают запросы на объекты от браузера к серверу Web и сохраняют полученные от сервера объекты на жестком диске перед передачей их браузеру. Таким образом, при последующих запросах на тот же самый объект от других браузеров кэш-сервер возвращает копию объекта из своей памяти вместо того, чтобы передавать запрос на сервер Web для получения оригинала объекта. В идеале выполнение кэш-сервером запросов на объекты должно экономить и время, и пропускную способность. (Более детальное описание технологии кэширования можно найти в статье "Мал кэш - да дорог" в LAN №3 за этот год.)

Испытывая давление со стороны как потребителей, так и провайдеров информационного наполнения, провайдеры Internet стали основными пользователями IP-кэширования. Более быстрые средства соединения, такие, как цифровая абонентская линия (Digital Subscriber Line, DSL), IDSN и кабельные модемы, дают надежду на то, что когда-то слабейшее звено в цепи передачи данных - стандартный телефонный модем с максимальной скоростью передачи данных 56 Кбит/с - будет устранено. С ускорением соединений c Internet объем копируемых объектов увеличится пропорциональным образом, а это приведет к увеличению трафика по магистрали Internet. Одновременно провайдеры информационного наполнения переходят на более сложные и объемные форматы данных, такие, как потоковое аудио/видео и апплеты Java.

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

Несмотря на то что многие провайдеры Internet признают преимущество IP-кэширования, предприятиям еще предстоит внедрить технологию в широком масштабе. По данным отчета Collaborative Research за февраль 1998 года, около 80% провайдеров Internet в США объявили о планах реализации кэширования в ближайшие полгода. С другой стороны, только 56% компаний собирались начать использовать кэширование в течение того же срока. Однако, как предсказывают эксперты, в 1999 году кэширование будет пользоваться повышенным спросом на корпоративном рынке. Согласно Collaborative Research, объем вложений в технологии кэширования в компаниях должен быстро обогнать соответствующий показатель для провайдеров Internet и вырасти с 85 млн долларов в 1998 году до свыше 1 млрд долларов в 2000 году (см. Таблицу).

Мировой рынок продуктов для кэширования в 1998-2002 гг.
Сегмент рынка	1998	1999	2000	2001	2002
Корпоративные пользователи	85 млн долларов	421 млн долларов	1 113 млн долларов	2 108 млн долларов	3 157 млн долларов
Провайдеры Internet	103 млн долларов	214 млн долларов	376 млн долларов	481 млн долларов	576 млн долларов
Другие	19 млн долларов	63 млн долларов	149 млн долларов	259 млн долларов	373 млн долларов
Всего	207 млн долларов	698 млн долларов	1 638 млн долларов	2 848 млн долларов	4 106 млн долларов
Источник: Collaborative Research, 1998

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

ПОСРЕДНИК КАК КЭШ?

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

Одним из первых посредников с поддержкой кэширования был программный сервер Harvest Cache, появившийся в результате совместного проекта, финансируемого в 1994-1996 годах Агентством по исследовательским проектам в области передовых технологий (Advanced Research Projects Agency, ARPA), Национальным научным фондом (National Science Foundation, NSF) и NASA. С тех пор по крайней мере десяток продуктов был выпущен на рынок под маркой "кэширующих посредников". Примечательно, что и Netscape Communications, и Microsoft, и Novell имеют proxy-серверы с поддержкой кэширования, тесно интегрированные с их другими корпоративными инструментами. Помимо кэширования их продукты предлагают широкий выбор посреднических функций, таких, как идентификация пользователей, фильтрация информационного наполнения, сканирование на наличие вирусов, обеспечение защиты и протоколирование событий. Proxy от Microsoft выполняется на базе Windows NT 4.0; Proxy Server от Netscape - на базе большинства разновидностей UNIX, а также Windows NT; BorderManager FastCache от Novell - на IntranetWare, NetWare 4.11 и NetWare 5.

Другим широко используемым коммерческим посредником с кэшированием является Squid, продолжение Harvest Cache, развитием которого занимается Национальная лаборатория передовых сетевых исследований (National Laboratory for Advanced Network Research, NLANR). Возможно, благодаря тому, что он появился как продукт коллективных усилий в среде, где приветствуется и широко применяется стандартизованное и общепризнанное программное обеспечение, Squid занял твердое место на рынке провайдеров Internet и продолжает иметь относительно прочную инсталлированную базу.

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

Чтобы избежать упомянутых затруднений в конфигурациях с посредником, вы можете реализовать в своей сети прозрачное кэширование посредством установки маршрутизатора с поддержкой заданных правил или коммутатора четвертого уровня для перенаправления трафика на кэш-сервер или группу серверов. Эти устройства перехватывают весь трафик HTTP через порт 80 и перенаправляют его в кэш. Кэш выполняет запросы HTTP и возвращает объекты назад браузеру. Действительно прозрачное решение в области кэширования должно поддерживать масштабирование посредством распределения нагрузки между несколькими кэш-серверами, а также переключение на резервные серверы в случае недоступности одного или всех кэш-серверов. Примерами коммутирующих устройств четвертого уровня могут служить ACEdirector от Alteon Networks и ServerIron от Foundry Networks.

Кэш-сервер Infolibria от DynaCache опирается на иной подход, обеспечивая прозрачность без использования отдельного коммутатора или маршрутизатора. Это достигается с помощью DynaLink Redirector (DLR), выделенного коммутатора четвертого уровня, взаимодействующего с DynaCache. DLR, интегральная составляющая стратегии компании в области кэширования, располагается в сети и переадресует в Internet только "промахи" кэша. По утверждению компании, подобная стратегия позволяет сократить нагрузку на маршрутизатор на две трети.

ПРОГРАММНЫЙ ПРОТИВ АППАРАТНОГО

В 1997 году в отчете под названием "Почему кэширование так важно" Forrester Research опубликовала прогноз, что провайдеры Internet и компании будут переходить с программных кэш-серверов на выделенные устройства кэширования. Аналогично, Dataquest заявила в июльском отчете 1998 года, что выделенные устройства будут доминировать на рынке продуктов для кэширования.

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

Network Appliance одной из первых предложила выделенное устройство кэширования. Для этого она адаптировала программное обеспечение NetCache для аппаратного продукта. Network Appliance приобрела программное обеспечение NetCache (и заполучила в придачу Питера Данцига, одного из главных архитекторов Harvest Project) вместе с небольшой молодой компанией Internet Middleware.

Среди других появившихся в 1998 году устройств кэширования - Cache Engine от Cisco Systems, CacheFlow от CacheFlow и DynaCache от InfoLibria. Не будучи выделенным устройством в строгом смысле слова, Netra Proxy от Sun Microsystems поставляется преконфигурированным на компьютере UltraSPARC II. Он содержит программное обеспечение кэширования от Sun и оптимизирован для осуществления этих функций.

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

Тремя примерами недорогих устройств кэширования могут служить WebSpeed от Packetstorm Technologies, CacheQube и CacheRaQ от Cobalt Networks. WebSpeed продается по цене от 2100 до 7100 долларов в зависимости от размера кэша. WebSpeed использует процессоры Intel и бесплатную операционную систему Linux, а также программное обеспечение кэширования Squid. Компания делает ставку на то, что заказчики оценят недорогое преконфигурированное устройство, которое они могут установить в свои сети с минимальными усилиями. CacheQube и монтируемый в стойку CacheRaQ от Cobalt Network могут наращиваться как за счет увеличения емкости DRAM и дискового пространства, так и посредством создания кластера из нескольких устройств. CacheQube стоит 1899 долларов, а CacheRaQ - 2299 или 2799 долларов в зависимости от конфигурации.

Пытаясь опровергнуть прогнозы экспертов о том, что выделенные устройства кэширования будут доминировать на рынке, Inktomi выпустила Traffic Server, который компания позиционирует как высокопроизводительное решение в области кэширования, предназначенное главным образом для провайдеров Internet и крупных предприятий. В отличие от нее, другие программные кэши ориентированы на функции посредника и защиты в той же мере, что и на функции кэширования. При цене 30 000 долларов в расчете на ЦПУ Traffic Server имеет к тому же цену продукта уровня оператора связи.

СОВМЕСТИМОСТЬ И СТАНДАРТЫ

Ведущий свое начало от первых исследований в области кэширования в рамках проекта Harvest Project, протокол кэширования Internet (Internet Caching Protocol, ICP) определяет, как несколько кэш-серверов IP могут совместно использовать информацию о новизне объектов Web и как они получают объекты из других кэшей (в противовес извлечению объектов с исходного сервера Web). С помощью ICP администраторы серверов могут сконфигурировать кэш на подачу запроса к другим кэш-серверам, также поддерживающим ICP, на предмет наличия у них последней информации об объектах Web. Например, локальный кэш может попросить вышестоящий кэш посмотреть, нет ли у того более новой копии файла, и если такой копии нет, то не проверял ли тот возраст файла на исходном сервере. Даже если вышестоящий сервер не имеет более новой версии файла, то он мог недавно проверять факт изменения файла на исходном сервере. В зависимости от алгоритма обновления, локальный кэш может использовать эту информацию для получения более новой версии объекта с исходного сервера или задействовать вместо этого локальную копию (см. Рисунок).

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

Аналогично ICP, протокол маршрутизации для массива кэш-серверов (Caching Array Routing Protocol, CARP) представляет собой протокол для организации разделения нагрузки по кэшированию в рамках локального парка серверов. Он был разработан Microsoft и представлен в Консорциум World Wide Web (W3C) в качестве предложения по стандарту Internet. Помимо Microsoft около десятка других производителей, включая Packetstorm Technologies и Sun, объявили о своей поддержке CARP.

Чтобы устройство Cache Engine могло взаимодействовать с ее маршрутизаторами, Cisco разработала коммуникационный протокол для кэш-серверов в Web (Web Cache Communication Protocol, WCCP). С помощью WCCP маршрутизатор Cisco с поддержкой IOS перехватывает запросы HTTP, поступающие от браузеров, и перенаправляет их на кэш-сервер или выделенное устройство. WCCP поддерживает масштабируемость за счет распределения запросов между несколькими кэш-серверами в зависимости от их доступности.

В ноябре 1998 года Cisco начала выдавать лицензии на WCCP другим производителям продуктов для кэширования. Inktomi и Network Appliance заявили о намерениях включить поддержку WCCP в следующие редакции своих продуктов.

РЫНОЧНЫЕ ПОКАЗАТЕЛИ

Несмотря на некоторые разногласия относительно цифр, как ожидается, рынок продуктов кэширования Internet значительно вырастет в ближайшие четыре года. Collaborative Research прогнозирует рост рынка с 206 млн долларов США в 1998 году до свыше 4 млрд в 2002 году.

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

Как и Novell, Microsoft и Sun борются за доминирующие позиции на рынке программного обеспечения и серверов Internet. Они обе имеют широкую инсталлированную базу серверов Web и позиционируют свои продукты - с сопутствующим арсеналом посреднических функций - как необходимые компоненты для интегрированной среды поддержки приложений Web. При наличии обширной инсталлированной базы сетевых устройств тесная интеграция Cache Engine с другими сетевыми компонентами Cisco может способствовать его широкому распространению.

ЦЕНА ЧТО НАДО

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

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

Netscape, Microsoft и Novell предлагают мощные программные кэш-серверы с широким набором посреднических функций. Их продукты стоят около 1000 долларов на один ЦПУ. Как и в случае Squid, общую стоимость решения можно уменьшить за счет применения имеющегося оборудования. В противном случае, стоимость покупки оборудования придется включить в расходную часть.

Фил Кеппелер - разработчик Web в дизайнерской и программистской фирме. С ним можно связаться по адресу: [email protected] .

Рассматриваемые продукты

Microsoft Netscape Communications National Laboratory for Advanced Network Research Alteon Networks ACEdirector http://ircache.nlanr.net/Cache/FAQ/ircache-faq-9.html . Брайан Д. Дэвидсон, кандидат наук из Рутгерского университета, ведет информационную страничку по ресурсам кэширования на своем сервере http://www.cs.rutgers.edu/~davison/Web-caching/ . Она содержит новости о кэшировании, перечень и таблицу кэширующих посредников, библиографию и т. п. Если вы хотите больше узнать о Harvest Project, то соответствующие ссылки на результаты исследований, стенограммы заседаний и ответы на часто задаваемые вопросы имеются по адресу: http://www.harvest.transarc.com . CacheNow - это текущая кампания по продвижению широкомасштабного кэширования в целях решения проблемы нехватки пропускной способности и преодоления ограничений инфраструктуры Internet. Сведения о ней имеются на http://vancouver-Webpages.com/CacheNow/ .

• Перевод

Довольно подробное и интересное изложение материала, касающегося кэша и его использования. Часть 2 .

От переводчика: об опечатках и неточностях просьба сообщать в личку. Спасибо.

Веб-кэш располагается между одним или несколькими веб-серверами и клиентом, или множеством клиентов, и следит за входящими запросами, сохраняя при этом копии ответов - HTML-страниц, изображений и файлов (совокупно известных, как представления (representations); прим. переводчика - позвольте я буду употреблять слово “контент” - оно, на мой взгляд, не так режет слух), для собственных нужд. Затем, если поступает другой запрос с аналогичным url-адресом, кэш может использовать сохраненный прежде ответ, вместо повторного запроса к серверу.

Существует две основные причины, по которым используется веб-кэш:

1. Уменьшение времени ожидания - так как данные по запросу берутся из кэша (который располагается “ближе” к клиенту), требуется меньше времени для получения и отображения контента на стороне клиента. Это делает Веб более отзывчивым (прим. переводчика - “отзывчивым” в контексте быстроты реакции на запрос, а не эмоционально).

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

Виды веб-кэшей

Кэш браузера (Browser cache)

Если вы изучите окно настроек любого современного веб-браузера (например, Internet Explorer, Safari или Mozilla), вы, вероятно, заметите параметр настройки «Кэш». Эта опция позволяет выделить область жесткого диска на вашем компьютере для хранения просмотренного ранее контента. Кэш браузера работает согласно довольно простым правилам. Он просто проверяет являются ли данные “свежими”, обычно один раз за сессию (то есть, один раз в текущем сеансе браузера).

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

Прокси-кэш (Proxy cache)

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

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

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

Кэш-шлюз (Gateway Cache)

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

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

Сети доставки контента (content delivery networks, CDN) распространяют шлюзы по всему интернету (или некоторой его части) и отдают кэшированный контент заинтересованным веб-сайтам. Speedera и Akamai являются примерами CDN.

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

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

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

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

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

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

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

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

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

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

Все виды кэшей обладают определенным набором правил, которые они используют, чтобы определить, когда брать контент из кэша, если он доступен. Некоторые из эти правил установлены протоколами (HTTP 1.0/HTTP 1.1), некоторые - администраторами кэша (пользователями браузера или администраторами прокси).

Вообще говоря, это самые общие правила (не волнуйтесь, если вы не понимаете детали, они будут объяснены ниже):

1. Если заголовки ответа сообщают кэшу не сохранять их, он не сохранит.
2. Если запрос авторизованный (authorized) или безопасный (то есть, HTTPS), он не будет закэширован.
3. Кэшированный контент считается “свежим” (то есть, может быть отправлен клиенту без проверки с исходного сервера), если:
   • У него установлено время истечения или другой заголовок, контролирующий время жизни, и он еще не истек.
   • Если кэш недавно проверял контент и тот был модифицирован достаточно давно.
   Свежий контент берется непосредственно из кэша, без проверки с сервера.
4. Если контент является устаревшим, исходному серверу будет предложено провалидировать его или сообщить кэшу, является ли имеющаяся копия по-прежнему актуальной.
5. При определенных обстоятельствах - например, когда он отключен от сети - кэш может сохранять устаревшие ответы без проверки с исходного сервера.

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

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