Главная SharePoint, Без рубрики, Новое Обзор видов кэша в SharePoint Server (Часть 1)
  • Обзор видов кэша в SharePoint Server (Часть 1)

    LogoПодробная информация о 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 сервера и нагрузку на собственные процессоры.

     

    Pic1

    Pic2

    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.

     

    Pic3

     

    В дополнении к снижению обращений к 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 требуется хранить сотни тысяч файлы файлов, то вопрос о потребности в памяти нужно будет планировать с учетом вышесказанного.

     

    2

     

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

     

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

     

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

     

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

     

    3

     

    Для 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 ”

    v.1.0

Комментарии

  1. Очень хорошая статья.

    Если вы организовали курсы по мониторингу и производительностю SharePoint2010
    я обязательно посещу

  2. Спасибо. Есть вторая часть по кэшу, она уже на сайте. Третья и четвертая появится через дней 10. То, что вы хотите читается в курсе 10231

    Мое расписание: http://www.specialist.ru/trainer/%D1%80%D1%83%D0%B8

  3. Я посмотрел этот курс.
    Вы планируете авторские курсы ?
    В Microsoft -ских курсах учебные материалы на англиском.
    А я не очень дружу с англиским

  4. Пока я читаю только авторизованные курсы. Учебники действительно английские. В данный момент идет русификация инструкций к лабораторным работам по SharePoint и думаю месяца через 1.5 лабы будут на родном языке.

  5. Было бы классно, если бы была продемонистрирована непосредственная настройка BLOB!