Оценка требований к производительности и емкости для управления веб-контентом в SharePoint Server 2010

 

Применимо к: SharePoint Server 2010

Последнее изменение раздела: 2016-11-30

В данной статье приводится руководство по управлению емкостью для сайтов Microsoft SharePoint Server 2010, для которых включена инфраструктура публикации. Данный документ предназначен для SharePoint Server 2010, и содержащиеся в нем сведения неприменимы к SharePoint Foundation.

В статье рассматриваются указанные ниже сценарии.

• Сайт, опубликованный в Интернете, — веб-представительство организации.

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

• Сайт, опубликованный в интрасети, — внутренний новостной сайт.

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

• Корпоративный вики-сайт — репозиторий знаний.

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

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

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

• Потенциальные узкие места, связанные с развертыванием средств управления веб-контентом SharePoint Server 2010.

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

• Влияние операций записи на чтение данных конечными пользователями.

Содержание:

• Необходимые сведения

• Сведения о тестах и используемом подходе

• Развертывание средств управления веб-контентом

• Направления оптимизации

• Результаты тестов и рекомендации

• Об авторах

Необходимые сведения

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

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

• Управление емкостью и настройка размеров для SharePoint Server 2010 (Возможно, на английском языке)

• Практические примеры по управлению производительностью и емкостью (SharePoint Server 2010) (Возможно, на английском языке)

Сведения о тестах и используемом подходе

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

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

Набор данных

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

Набор данных

Объект	Сайт публикации
Размер баз данных контента	2,63 ГБ
Число баз данных контента	1
Число семейств веб-сайтов	1
Число веб-приложений	1
Число сайтов	50
Число страниц	20 000 страниц, разбитых на 20 папок по 1000 страниц в каждой
Структура страниц	Страницы статей на языке HTML (только базовые возможности) с двумя ссылками на рисунки
Размер страницы	42 КБ без сжатия; 12 КБ со сжатием
Изображения	3 000 рисунков размером от 30 КБ до 1,3 МБ

Службы IIS (Internet Information Services) рекомендуется настроить на постоянное сжатие файлов, а не использовать настроенное по умолчанию динамическое сжатие. При динамическом сжатии службы IIS сжимают страницы до тех пор, пока загрузка ЦП не превысит определенный порог, после чего службы IIS перестают сжимать страницы, пока загрузка ЦП не упадет ниже этого порога. Тесты в данной статье проводились при постоянно включенном сжатии.

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

Оборудование

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

Характеристики оборудования серверов-приложений и веб-серверов

	Веб-сервер
Процессоры	2 четырехъядерных процессора с тактовой частотой 2,33 ГГц
ОЗУ	8 ГБ
Операционная система	Windows Server 2008, 64-разрядная
Размер диска для SharePoint	300 ГБ
Число сетевых адаптеров	2
Скорость сетевого адаптера	1 гигабит
Проверка подлинности	Базовая проверка подлинности Windows
Тип службы балансировки нагрузки	Аппаратная балансировка нагрузки
Версия программного обеспечения	SharePoint Server 2010 (предварительная версия)
Службы, запущенные локально	Центр администрирования Входящая электронная почта Microsoft SharePoint Foundation Веб-приложение Microsoft SharePoint Foundation Служба таймера рабочих процессов Microsoft SharePoint Foundation

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

Характеристики оборудования для серверов базы данных

	Сервер базы данных
Процессоры	4 четырехъядерных процессора с тактовой частотой 3,19 ГГц
ОЗУ	16 ГБ
Операционная система	Windows Server 2008, 64-разрядная
Хранилище	15 дисков по 300 ГБ со скоростью вращения шпинделя 15 000 об/мин
Число сетевых адаптеров	2
Скорость сетевого адаптера	1 гигабит
Проверка подлинности	NTLM
Версия программного обеспечения	Microsoft SQL Server 2008

Глоссарий

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

• Запросов/сек   Запросов в секунду. Количество запросов, полученных фермой или сервером за одну секунду. Это основной показатель нагрузки на сервер или ферму.

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

• Зеленая зона   Это состояние, в котором сервер удовлетворяет указанным ниже условиям.

  • Задержка на стороне сервера для не менее чем 75% запросов не превышает одной секунды.

  • Уровень использования ЦП на всех серверах не превышает 50%.

  • Процент сбоев не превышает 0,01%.

Развертывание средств управления веб-контентом

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

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

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

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

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

Эти две модели являются взаимоисключающими.

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

Направления оптимизации

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

Содержание:

• Пропускная способность — ключевой показатель

• Узкие места и их устранение

• Рекомендации по кэшированию

Пропускная способность — ключевой показатель

Пропускная способность и время отклика являются основными показателями, которые необходимо оптимизировать при планирования емкости для развернутых средств управления веб-контентом SharePoint Server 2010. Пропускная способность — это количество операций, выполняемых фермой серверов в секунду (измеряется в запросах в секунду).

Узкие места и их устранение

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

Загрузка ЦП на веб-сервере

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

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

На схеме отражены указанные ниже изменения.

1. По мере того как уровень загрузки ЦП на веб-сервере приближается к 100%, время отклика увеличивается.

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

Другие узкие места

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

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

2. ЦП сервера базы данных    Если ЦП сервера базы данных становится узким местом, добавление в ферму серверов дополнительных веб-серверов не приводит к увеличению максимальной пропускной способности фермы. Узкое место, связанное с ЦП сервера базы данных, а не веб-сервера, может указывать на одну из двух описанных ниже ситуаций.

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

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

Рекомендации по кэшированию

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

Три типа кэширования перечислены ниже.

• Кэш вывода   В этом кэше, размещенном в оперативной памяти веб-сервера, хранится контент запрошенной страницы. Дополнительные сведения о кэше вывода см. в статье, посвященной кэшированию вывода и профилям кэша (https://go.microsoft.com/fwlink/?linkid=121543&clcid=0x419).

• Кэш объектов   В этом кэше, размещенном в оперативной памяти веб-сервера, хранятся объекты SharePoint, например метаданные веб-элементов и элементов списков. Дополнительные сведения о кэше объектов см. в статье, посвященной кэшированию объектов (https://go.microsoft.com/fwlink/?linkid=123948&clcid=0x419).

• Дисковый кэш для больших двоичных объектов   В этом кэше, размещенном на диске, хранятся изображения, звуки, видеоролики и другие большие двоичные файлы. Дополнительные сведения о кэше больших двоичных объектов см. в статье, посвященной дисковому кэшированию для больших двоичных объектов (https://go.microsoft.com/fwlink/?linkid=123947&clcid=0x419).

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

Результаты тестов и рекомендации

В данном разделе рассказывается о конкретных протестированных областях и приводятся рекомендации на основе результатов тестов.

Содержание:

• Влияние включения кэша вывода

• Анонимные пользователи и пользователи, прошедшие проверку

• Характеристики масштабирования для операций чтения и записи

• Вопросы, связанные с кэшем вывода

• Влияние объема считанных данных на загрузку ЦП и время отклика

• Влияние операций записи на пропускную способность

• Влияние развертывания контента

• Влияние моментальных снимков базы данных во время экспорта контента

• Характеристики контента

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

Кэш вывода полезно использовать для оптимизации решения SharePoint Server 2010 для обработки большого количества операций чтения.

В этих тестах для определения максимального количества запросов в секунду количество активных пользователей, выполняющих запросы на ферме, увеличивалось до тех пор, пока загрузка ЦП на сервере базы данных или веб-серверах не достигала 100% и ЦП не становился узким местом. Тест проводился в топологиях фермы 1x1 (1 веб-сервер и 1 сервер базы данных), 2x1, 4x1 и 8x1, чтобы продемонстрировать зависимость коэффициента попадания в кэш вывода от масштабирования веб-серверов.

Коэффициент попадания в кэш вывода

Коэффициент попадания в кэш вывода представляет собой отношение количества попаданий в кэш к количеству промахов.

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

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

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

• Страницы, не настроенные на использование кэша вывода.

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

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

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

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

Примечание

Точка данных для максимального количества запросов в секунду в ферме серверов с топологией 4x1 со стопроцентным коэффициентом попадания в кэш была получена путем экстраполяции и фактически не наблюдалась. Объем запросов к ферме серверов достиг предельной пропускной способности сети, т. е. скорость передачи данных приблизилась к 1 гигабиту в секунду. Во всех случаях загрузка ЦП веб-сервера составляла 100%.

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

Влияние коэффициента попадания в кэш вывода в различных топологиях фермы

Коэффициент попадания в кэш вывода	Значение	1x1	2x1	4x1
100%	Макс. кол-во запросов/сек Использование ЦП SQL Server	3 463 0%	7 331 0%	11 032 0%
95%	Макс. кол-во запросов/сек Использование ЦП SQL Server	2 137 5,93%	3 945 12,00%	5 937 21,80%
90%	Макс. кол-во запросов/сек Использование ЦП SQL Server	1 518 7,12%	2 864 14,40%	4 518 28,00%
50%	Макс. кол-во запросов/сек Использование ЦП SQL Server	459 9,86%	913 19,50%	1 596 42,00%
0%	Макс. кол-во запросов/сек Использование ЦП SQL Server	172 9,53%	339 19,00%	638 36,30%

Выводы и рекомендации по использованию кэша вывода

Более высокое значение коэффициента попадания в кэш вывода соответствует существенному увеличению максимального количества запросов в секунду. Таким образом, для оптимизации решения публикации SharePoint Server 2010 рекомендуется включить кэш вывода. Параметры кэша вывода настраиваются на странице "Параметры кэша вывода" семейства сайтов. Дополнительные сведения см. в статье, посвященной улучшению отрисовки страниц путем настройки кэширования вывода (https://go.microsoft.com/fwlink/?linkid=205058&clcid=0x419) на сайте Office.Microsoft.com.

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

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

Анонимные пользователи и пользователи, прошедшие проверку

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

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

Профили кэша

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

• Срок хранения элементов в кэше.

• Политика фильтрации по ролям безопасности.

• Срок действия параметров, например продолжительности и изменений.

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

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

Для анонимных пользователей использовался профиль кэша вывода "Общий доступ через Интернет (анонимный)", а для пользователей, прошедших проверку, — профиль "Экстрасеть (опубликованный сайт)".

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

В качестве модели проверки подлинности использовалась базовая проверка подлинности Windows. Хотя базовую проверку подлинности не рекомендуется использовать для сайтов в Интернете, этот метод проверки подлинности был выбран для демонстрации минимальных накладных расходов, возникающих из-за проверки подлинности. Величина этих накладных расходов варьируется в зависимости от конкретного механизма проверки подлинности. При тестировании своей среды обязательно учитывайте влияние выбранного механизма проверки подлинности. Дополнительные сведения о механизмах проверки подлинности, поддерживаемых в SharePoint Server 2010, см. в статье Планирование способов проверки подлинности (SharePoint Server 2010).

Выводы и рекомендации по работе с анонимными пользователями и пользователями, прошедшими проверку

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

Характеристики масштабирования для операций чтения и записи

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

В последующих тестах в систему добавлялись читатели до тех пор, пока загрузка ЦП веб-сервера не достигала 80-90%, после чего в среде выполнялись операции записи с искусственной задержкой. Общее количество операций записи в час составляло приблизительно 500. Для всех тестов коэффициент попадания в кэш вывода составлял 90%. Один и тот же тест выполнялся для топологий фермы 1x1, 2x1 и 4x1; при этом в дополнение к общей пропускной способности при чтении для каждой конфигурации отслеживалась загрузка ЦП веб-сервера и SQL Server. В качестве базы для сравнения были взяты результаты тестирования конфигурации с анонимным доступом только на чтение; также была протестирована конфигурация с прошедшими проверку пользователями (использовалась базовая проверка подлинности Windows).

Хотя при проведении тестов масштабируемости с доступом только на чтение ЦП веб-сервера использовался на 100%, при проведении тестов масштабируемости с операциями записи загрузка ЦП веб-сервера поддерживалась на уровне 80-90%. Это было сделано для резервирования части ресурсов ЦП на выполнение операций записи.

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

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

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

Необходимо помнить о том, что в типичной среде на нагрузку на сервер базы данных также влияют дополнительные факторы, которые следует учитывать при планировании емкости. Дополнительные сведения о том, как определить зеленую зону для типичной загрузки ЦП сервера базы данных, см. в статье Обзор управления емкостью и изменения размера для SharePoint Server 2010.

Выводы и рекомендации по характеристикам масштабирования для операций чтения и записи

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

На приведенной ниже диаграмме показано влияние пропускной способности на загрузку ЦП сервера базы данных.

Вопросы, связанные с кэшем вывода

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

Актуальность данных

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

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

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

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

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

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

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

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

Выводы и рекомендации по использованию кэша вывода

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

Влияние объема считанных данных на загрузку ЦП и время отклика

Этот тест проводился в ферме с топологией 1x1 с анонимным доступом и включенным кэшированием вывода.

На приведенной ниже диаграмме показано влияние объема считанных данных на загрузку ЦП и время отклика.

Выводы и рекомендации по влиянию объема считанных данных на загрузку ЦП и время отклика

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

Влияние операций записи на пропускную способность

Отношение количества операций создания к количеству операций изменения одинаково на протяжении тестов. При тестировании количество операций записи в час было ограничено 500, поскольку создание или изменение более 500 страниц в час выходит за рамки возможностей, поддерживаемых в большинстве сред SharePoint. Тест не охватывает автоматизированные процессы, например развертывание контента, рассмотренные в разделе Влияние развертывания контента. Операции создания и изменения могут привести к выполнению множества операций SQL Server. Следовательно, необходимо учитывать, что операции записи, количество которых измерено в этих тестах, являются не операциями на уровне SQL Server, а операциями, которые пользователь рассматривает как операции записи. Все тесты на количество запросов в секунду с учетом количества операций записи в час проводились в ферме с топологией 1x1.

Сначала в тест добавлялись операции чтения до достижения загрузки ЦП веб-сервера на уровне 60-80%, чтобы оставить буфер для скачков трафика, после чего такой уровень загрузки ЦП поддерживался на всем протяжении теста. Затем были введены операции записи с искусственной задержкой для контроля их количества. При выполнении операций записи наблюдались скачки загрузки ЦП веб-сервера и SQL Server. Некоторые из этих скачков для определенных значений коэффициента попадания в кэш, как показано на приведенной ниже диаграмме, превышали пороговое значение, характерное для обычной эксплуатации, однако среднее значение оставалось в пределах нормы.

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

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

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

При выполнении операций записи, как и следовало ожидать, наблюдалась дополнительная нагрузка на SQL Server. Однако наибольшее увеличение нагрузки составило 2,06%, что крайне незначительно. Средняя загрузка ЦП сервера базы данных оставалась ниже 10% на протяжении всех тестов. Этот тест выполнялся в ферме с топологией 1x1. Загрузка ЦП сервера базы данных увеличивается с увеличением количества веб-серверов. Эта ситуация подробно рассмотрена в разделе Характеристики масштабирования для операций чтения и записи.

Во время тестирования также была измерена загрузка ЦП веб-сервера. На приведенной ниже диаграмме показано, что средняя загрузка ЦП веб-сервера оставалась в пределах 60-80% на всем протяжении тестирования, даже когда количество операций записи в час достигало 500.

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

Для типичной среды коэффициент попадания в кэш, равный 90%, крайне мал. Для большинства сред SharePoint Server 2010 с большим количеством операций чтения этот коэффициент составляет не менее 95%.

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

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

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

• Увеличивается количество запросов на чтение в секунду, особенно при высоком коэффициенте попадания в кэш вывода.

Влияние развертывания контента

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

В подобной конфигурации в производственной среде практически не выполняются операции записи за исключением случая импорта контента при его развертывании. В данных тестах количество операций чтения увеличивалось до тех пор, пока загрузка ЦП веб-сервера не достигала 70-80%. После этого задание развертывания контента экспортировало 10 сайтов по 500 страниц в каждом из семейства сайтов разработки в виде пакета и импортировало этот пакет в семейство сайтов публикации. Размер развернутого пакета был больше размера пакетов, обычно используемых в реальных средах, чтобы обеспечить достаточную продолжительность выполнения задания для получения результатов теста. Дополнительные сведения о характеристиках развернутого контента см. в разделе Набор данных.

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

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

В приведенных ниже таблицах показано влияние импорта контента на загрузку ЦП веб-сервера и сервера базы данных.

Влияние импорта контента на загрузку ЦП веб-сервера

Попадание в кэш	100%	99%	98%	95%	90%	50%	0%
Базовые показатели	72,32%	73,26%	71,28%	73,53%	71,79%	68,05%	63,97%
С импортом	70,93%	74,45%	69,56%	74,12%	70,95%	67,93%	63,94%

Влияние импорта контента на загрузку ЦП сервера базы данных

Попадание в кэш	100%	99%	98%	95%	90%	50%	0%
Базовые показатели	1,19%	1,64%	2,01%	3,00%	3,73%	5,40%	6,82%
С импортом	6,03%	6,82%	6,97%	7,96%	8,52%	10,29%	10,56%

Выводы и рекомендации по влиянию развертывания контента

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

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

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

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

Влияние моментальных снимков базы данных во время развертывания контента

Метрика	4 операции записи в час, без моментальных снимков	4 операции записи в час, с моментальными снимками
Запросов на запись в секунду	0,2	0,16
Время отклика	0,13	0,15
ЦП веб-сервера, %	0,42%	0,27%
ЦП сервера приложений, %	8,67%	8,98%
ЦП сервера базы данных, %	3,34%	2,41%

Влияние моментальных снимков базы данных во время развертывания контента

Метрика	8 операций записи в час, без моментальных снимков	8 операций записи в час, с моментальными снимками
Запросов на запись в секунду	0,44	0,44
Время отклика	0,13	0,13
ЦП веб-сервера, %	0,61%	0,73%
ЦП сервера приложений, %	14,6%	12%
ЦП сервера базы данных, %	7,04%	7,86%

Выводы и рекомендации по влиянию моментальных снимков базы данных во время экспорта контента

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

Характеристики контента

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

Число страниц

Во время тестирования было измерено максимальное количество запросов в секунду для различных размеров библиотеки страниц. Тест проводился для топологии 4x1 с отключенным кэшированием вывода и включенным анонимным доступом. Размер каждой страницы составлял 42 КБ без сжатия и 12 КБ со сжатием. Результаты теста приведены в таблице ниже.

Влияние числа страниц в библиотеке на количество запросов в секунду

Число страниц	3	1000	20 000
Макс. кол-во запросов/сек	860	801	790

Увеличение числа страниц до 20 000 существенно не повлияло на максимальное количество запросов в секунду.

Многозначные поля подстановки

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

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

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

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

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

Влияние отчетов об использовании

Отчеты об использовании — это служба, с помощью которой администраторы отслеживают статистику об использовании сайтов. Дополнительные сведения об этих отчетах см. в статье Настройка сбора данных использования и работоспособности (SharePoint Server 2010).

Влияние заданий таймера отчетов об использовании на максимальное количество запросов в секунду было протестировано в ферме с топологией 1x1. Результаты приведены в таблице ниже.

Влияние ведения журнала использования на производительность (в запросах в секунду)

	База данных использования включена	База данных использования отключена	Различие
Кэш вывода включен	3 459	3 463	4
Кэш вывода отключен	629	638	9

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

Об авторах

Джошуа Стиклер, руководитель программы SharePoint Server 2010 в корпорации Майкрософт.

Тайлер Батлер, руководитель программы SharePoint Server 2010 в корпорации Майкрософт.

Жи Лю, инженер-испытатель в области разработки программного обеспечения SharePoint Server 2010 в корпорации Майкрософт.

Чок Донг, инженер-испытатель в области разработки программного обеспечения SharePoint Server 2010 в корпорации Майкрософт.

Филипп Фламм, инженер-испытатель в области разработки программного обеспечения SharePoint Server 2010 в корпорации Майкрософт.