Лабораторное исследование социальной среды Microsoft SharePoint Server 2010

 

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

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

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

• Характеристики тестовой среды, такие как оборудование, топология фермы и конфигурация.

• Тестовый набор данных фермы.

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

Общая сводка

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

• Среда масштабировалась до восьми интерфейсных веб-серверов с одним сервером приложений и одним сервером базы данных (8×1×1). Повышение пропускной способности оказалось практически линейным. Дополнительного выигрыша в пропускной способности при добавлении более восьми интерфейсных веб-серверов не было, поскольку узким местом в этой конфигурации оказался ЦП сервера баз данных.

• Дальнейшее масштабирования было достигнуто за счет размещения базы данных контента и базы данных служб на разных серверах баз данных (8×1×2).

• Максимальная пропускная способность была достигнута в топологии 8x1x2. В ней узкими местами оказались ЦП интерфейсного веб-сервера и сервера приложений. Таким образом, с использованием этого оборудования, набора данных и тестовой рабочей нагрузки максимально возможное число запросов в секунду представлено значением Максимальной зоны для конфигурации 8x1x2, которое составляет примерно 1877 запросов в секунду.

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

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

• Если включена фильтрация по ролям безопасности, один интерфейсный веб-сервер может поддерживать от 8 до 10 запросов в секунду в трафике Outlook Social Connector. Это означает, что один интерфейсный веб-сервер способен поддерживать работу 28 000-36 000 сотрудников, использующих Outlook Social Connector целый день. Таким образом, при развертывании Outlook Social Connector для 100 000 сотрудников, для поддержки трафика Outlook Social Connector потребуется три интерфейсных веб-сервера. Эти значения зависят от использования социальных тегов в компании. Если в компании планируется менее активное использование социальных тегов, чем в нашем тестовом наборе данных, то пропускная способность каждого интерфейсного веб-сервера может превышать 8-10 запросов в секунду.

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

Общие сведения о среде

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

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

Данная статья научит выполнять следующие действия.

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

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

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

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

• Capacity management and sizing for SharePoint Server 2010

• Управление мощностью SharePoint Server 2010 Ограничения, связанные с программным обеспечением

• Social environment technical case study (SharePoint Server 2010)

Руководство по планированию емкости для типовых сценариев совместной работы можно найти в статье Enterprise intranet collaboration environment technical case study (SharePoint Server 2010)

Глоссарий

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

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

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

• Зеленая зона. Состояние, при котором сервер соответствует следующему набору критериев.

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

  • Загрузка ЦП на всех серверах не превышает 50%.

  Примечание

  Поскольку в этой лабораторной среде не проводился обход контента при поиске, на сервере базы данных загрузка ЦП сохранялась на уровне 40% и ниже с резервированием 10% для нагрузки обхода контента при поиске. При этом предполагается, что в производственной среде будет использоваться регулятор ресурсов Microsoft SQL Server для ограничения нагрузки обхода контента при поиске значением в 10% от загрузки ЦП.

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

• Красная (максимальная) зона. Состояние, при котором сервер соответствует следующему набору критериев.

  • Включена функция регулирования HTTP-запросов, но возвращаются ошибки 503 (Сервер занят).

  • Процент сбоев для HTTP-запросов составляет менее 0,1%.

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

  • Загрузка ЦП сервера базы данных составляет менее 80%. Это ограничение позволяет зарезервировать 10% мощности процессора для нагрузки обхода контента при поиске и реализуется с помощью регулятора ресурсов SQL Server.

• AxBxC. Число интерфейсных веб-серверов, серверов приложений и серверов баз данных в ферме. Например, 8x1x2 означает, что в данной среде имеется восемь интерфейсных веб-серверов, один сервер приложений и два сервера баз данных.

• Нагрузка VSTS. Это потоки, которые используются внутри Visual Studio Team System (VSTS) для имитации виртуальных пользователей. Мы увеличили нагрузку VSTS для порождения большего числа запросов в секунду в топологии.

• MDF и LDF. Физические файлы SQL Server. Дополнительные сведения см. в статье, посвященной архитектуре файлов и файловых групп.

Обзор

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

Подход к масштабированию

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

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

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

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

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

Сопоставление лабораторной и производственной среды

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

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

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

Подробное исследование портала личных сайтов и социальных вычислений в производственной среде в Microsoft см. в статье Social environment technical case study (SharePoint Server 2010).

Методика и заметки о тестировании

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

• Между тестами изменялась только одна переменная за раз для простоты сравнения результатов.

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

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

Спецификации

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

Аппаратное обеспечение

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

	Интерфейсный веб-сервер	Сервер приложений	Сервер базы данных
Процессор	2 четырехъядерных процессора с тактовой частотой 2,33 ГГц	2 четырехъядерных процессора с тактовой частотой 2,33 ГГц	4 четырехъядерных процессора с тактовой частотой 3,10 ГГц
ОЗУ	8 ГБ	8 ГБ	32 ГБ
Число сетевых адаптеров	2	2	1
Скорость сетевого адаптера	1 гигабит	1 гигабит	1 гигабит
Тип службы балансировки нагрузки	F5 - Аппаратная балансировка нагрузки	Неприменимо	Неприменимо
Уровень ведения журнала ULS	Средний	Средний	Неприменимо

Программное обеспечение

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

	Интерфейсный веб-сервер	Сервер приложений	Сервер базы данных
Операционная система	Windows Server 2008 R2 x64	Windows Server 2008 R2 x64	Windows Server 2008 x64
Версия программного обеспечения	Microsoft SharePoint 4763.1000 (RTM), Office Web Applications 4763.1000 (RTM)	Microsoft SharePoint 4763.1000 (RTM), WAC 4763.1000 (RTM)	SQL Server 2008 R2 CTP3
Тип службы балансировки нагрузки	F5 - Аппаратная балансировка нагрузки	Неприменимо	Неприменимо
Уровень ведения журнала ULS	Средний	Средний	Неприменимо
Параметры антивируса	Отключено	Отключено	Отключено
Запущенные службы	Входящая почта SharePoint Foundation Веб-приложение SharePoint Foundation Служба таймера рабочих процессов SharePoint Foundation	Центр администрирования Службы вычислений Excel Веб-служба управляемых метаданных Входящая почта SharePoint Foundation Веб-приложение SharePoint Foundation Служба таймера рабочих процессов SharePoint Foundation Служба PowerPoint Служба профилей пользователей Служба синхронизации профилей пользователей Служба просмотра Word

Топология

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

Архитектура набора данных и диска

Тестовая ферма включала следующие компоненты:

• 166,5 ГБ контента личных сайтов, равномерно распределенных по 10 базам данных контента

• 27,7 ГБ контента базы данных профилей

• 3,7 ГБ контента базы данных социальных вычислений (идентификаторы GUID для социальных тегов, заметки и рейтинги)

• 0,14 ГБ контента базы данных управляемых метаданных (текст для социальных тегов и соответствующие идентификаторы GUID)

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

Число профилей пользователей	~150 000
Среднее число отношений участия на пользователя	74
Среднее число прямых отчетов на пользователя	6
Среднее число коллег на пользователя	28
Число всех свойств профиля	101
Число свойств с несколькими значениями	21
Число аудиторий	130
Число личных сайтов	~10 000
Число сайтов блогов	Около 600
Общее число событий в веб-канале активности	798 000*
Число социальных тегов и рейтингов	5,04 млн**

* Исследование социальных тегов, проведенное на портале del.icio.us, говорит, что активный пользователь создает 4,2 тега в месяц. Под созданием тегов в данном исследовании подразумевается любое назначение метаданных URL-адресам. Сюда относятся теги ключевых слов, рейтинги и заметки. Это означает, что активный пользователь создает 4,2 тега/30 дней = 0,14 тегов/день. Если предположить, что теги создает одна треть пользователей социального портала, в день происходит 150 000/3 × 0,14 событий связанных с тегами. Таблицы веб-каналов активности хранят действия в течении 14 дней. Поэтому общее число событий, связанных с тегами, в таблице веб-каналов активности составляет 150 000/3 × 0,14 × 14. Помимо событий, связанных с тегами, если предположить, что активные пользователи создают одно дополнительное событие в день, обновление свойства профиля или состояния, получается 150 000/3 × 1 × 14 событий, которые добавляются в таблицы веб-каналов активности. Таким образом, общее число событий в таблицах веб-каналов активности равно 150 000/3 × 1,14 × 14 = 798 000. Из этих событий 98 000 составляют действия, связанные с тегами, которые могут запускать фильтрацию по ролям безопасности. Остальные события будут произвольно распределены между обновлениями состояния и изменениями свойств профиля.

** Предполагается, что одна треть населения является активными пользователями, каждый из которых создает 4,2 тега в месяц, где "тег" может означать тег ключевого слова, заметку или рейтинг. Если предположить, что ферма существует два года, общее число тегов составит 150 000/3 × 4,2 × 12 × 2 = 5,04 млн.

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

База данных	БД контента 1, 2, 3, 4	БД контента 5, 6	БД контента 7, 8	БД контента 9, 10	Профиль	Социальные вычисления	Метаданные
Размер базы данных	61,4 ГБ	39 ГБ	32,3 ГБ	33,7 ГБ	27,7 ГБ	3,7 ГБ	0,14 ГБ
Конфигурация RAID	0	0	0	0	0	0	0
Число шпинделей для MDF-файлов	1	1	1	1	6	1	1
Число шпинделей для LDF-файлов	один физический шпиндель общий для всех баз данных

Тестовый набор

Важные замечания

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

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

• Тестовый набор не включает трафик, связанный с обходом контента при поиске. Однако он учитывался в тестах, поскольку в определении Зеленой зоны для загрузки ЦП на сервере SQL Server было установлено значение 40%, вместо обычных 50%, которое позволяет использовать 10% ресурсов ЦП для обхода контента при поиске. Аналогично, для значения "Максимальное число запросов в секунду" использовалась 80-процентная загрузка ЦП сервера SQL Server.

• В дополнение к тестовому набору, указанному в следующей таблице, для каждого интерфейсного веб-сервера мы также добавили восемь запросов в секунду со стороны трафика Outlook Social Connector. Фильтрация по ролям безопасности была включена. Служба маркеров безопасности показывала признаки серьезной нагрузки, когда мы достигли примерно 8 запросов в секунду из трафика Outlook Social Connector на одном интерфейсном веб-сервере при получении действий коллег. Такое поведение было характерно для набора данных, тестовой рабочей нагрузки и оборудования, которые использовались для тестирования. В вашем случае ситуация может оказаться совершенно другой. Во избежание дополнительной нагрузки на службу маркеров безопасности мы решили добавлять трафик Outlook Social Connector в соответствии с числом интерфейсных веб-серверов при каждой итерации. Таким образом, в топологии 1x1x1 имелось 8 запросов в секунду для трафика Outlook Social Connector, а в топологии 2x1x1 было 16 запросов в секунду и т. д.

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

Тестирование	Чтение/запись	Процент набора
Добавление коллеги.	Запись	2,11
Создание рейтинга для URL-адреса, запись замечания или создание тега для URL-адреса.	Запись	3,22
Вывод списка рабочих документов.	Чтение/Запись	2,36
Публикация ссылок на вызовы клиента модели к службе PublishedLinksService.asmx.	Чтение	6,92
Получение RSS-каналов из списков.	Чтение	3,72
Просмотр всех элементов в библиотеках документов и списках на личном сайте.	Чтение	1,07
Просмотр публикации в блоге.	Чтение	0,04
Просмотр различных страниц личного сайта (свой контент, коллеги, канал новостей, свой профиль, чужой профиль, браузер организации, членство, теги и заметки).	Чтение	3,87
Синхронизация общих файлов OneNote.	Чтение	10,0
Редактирование страницы профиля или сообщения состояния, обновление рисунка.	Запись	2,31
Office Web Apps: открытие и прокрутка файлов (PowerPoint, Word и Excel).	Чтение	0,13
Синхронизация списков с Outlook.	Чтение	48,16
Передача документа	Запись	0,09
Загрузка страниц, библиотек документов и папок из базы данных контента.	Чтение	15,93
Совместное редактирование документов.	Чтение/Запись	0,17

В следующей таблице описывается дополнительный тестовый набор для сценария Outlook Social Connector, который порождает 8 запросов в секунду на каждом интерфейсном веб-сервере.

Автоматическая синхронизация с коллегами.	Чтение	4%
Автоматическая синхронизация каналов новостей коллег.	Чтение	96%

Результаты и выводы

Сравнение всех итераций

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

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

Результаты для Зеленой зоны

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

Топология	1x1x1	2x1x1	3x1x1	5x1x1	8x1x1	8x1x2
Зеленая зона: запросов в секунду	137,25	278,08	440,72	683,07	793,67	873,4
Зеленая зона: задержка для 75-го процентиля	0,12	0,16	0,14	0,16	0,31	0,32
Зеленая зона: загрузка ЦП интерфейсного веб-сервера	47,84	46,88	48,68	46,13	31,79	36,90
Зеленая зона: загрузка ЦП сервера приложений	9,45	18,88	26,91	35,58	48,73	47,20
Зеленая зона: загрузка ЦП сервера SQL Server	5,45	10,61	16,46	24,73	30,03	32,40 (17,9 для базы данных контента и 14,5 для базы данных служб)

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

Как показано на предыдущей диаграмме:

• Количество запросов в секунду увеличивалось при добавлении компьютеров в топологию.

• Очевидно, что главным фактором, который приближал топологию к границе Зеленой зоны до конфигурации 5x1x1, была загрузка ЦП интерфейсного веб-сервера. В конфигурации 8x1x1 загрузка ЦП сервера приложений достигла границы Зеленой зоны до того, как этой границы достигли интерфейсные веб-серверы.

• В течение всего тестирования загрузка ЦП сервера SQL Server оставалась в пределах нормы.

Результаты для Максимальной зоны

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

	1x1x1	2x1x1	3x1x1	5x1x1	8x1x1	8x1x2
Максимальная зона: запросов в секунду	203.28	450.75	615.00	971.13	1655	1877
Максимальная зона: задержка	0.22	0.23	0.22	0.22	0.31	0.32
Максимальная зона: загрузка ЦП интерфейсного веб-сервера	75.13	78.17	70.00	67.02	67	71.6
Максимальная зона: загрузка ЦП сервера приложений	12.97	27.07	28.40	48.28	67.1	73.4
Максимальная зона: загрузка ЦП сервера SQL Server	7.64	16.06	21.00	38.38	79.5	74.9 (45,9 для базы данных контента и 29 для базы данных служб)

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

Как показано на предыдущей диаграмме:

• Количество запросов в секунду увеличивалось при добавлении компьютеров в топологию.

• Очевидно, что вплоть до конфигурации 5x1x1 узким местом был ЦП интерфейсного веб-сервера. В конфигурации 8x1x1 узким местом стал ЦП SQL Server.

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

Зеленая зона и Максимальная зона

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

Как показано на предыдущих диаграммах:

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

• Увеличение пропускной способности практически линейно.

Дисковые операции ввода-вывода

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

	1x1x1, Максимальная зона	2x1x1, Максимальная зона	3x1x1, Максимальная зона	5x1x1, Максимальная зона
Операций чтения/с (база данных контента)	21,33	20,80	24,24	22,42
Операций чтения/с (база данных профилей)	14,97	17,20	19,82	13,50
Операций чтения/с (база данных социального контента)	1,81	1,83	2,10	2,01
Операций записи/с (база данных контента)	50,12	76,24	80,02	99,16
Операций записи/с (база данных профилей)	9,01	24,31	23,35	38,29
Операций записи/с (база данных социального контента)	4,12	9,47	10,63	19,45

Влияние обхода контента при поиске людей

Мы хотели измерить влияние обхода контента при поиске людей на пропускную способность, которая обуславливалась конфигурацией и задержками на стороне конечных пользователей. Для этого теста мы использовали результаты, полученные в конфигурации 8x1x1, в качестве базы и запустили добавочный обход контента при поиске людей. В течение 53 минут при добавочном обходе контента было проиндексировано 49 375 элементов.

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

	Базовые результаты для Зеленой зоны в конфигурации 8x1x1	Результаты для Зеленой зоны в конфигурации 8x1x1 с запущенным обходом контента при поиске людей
Пропускная способность (запросов в секунду)	1024,00	1026,00
Загрузка ЦП интерфейсного веб-сервера (%)	39,84	41,6
Загрузка ЦП сервера приложений (%)	41,40	43,1
Загрузка ЦП сервера SQL Server базы данных контента и служб (%)	36,63	39,5
Загрузка ЦП сервера индексирования (%)	0,52	34,6
Загрузка ЦП сервера SQL Server для поиска (%)	3,62	14,8

Как показано в этой таблице:

• Число запросов в секунду осталось практически без изменений. Поскольку узкого места в ресурсах для Зеленой зоны в конфигурации 8x1x1 не было, число запросов в секунду затрагиваться не должно.

• Загрузка ЦП интерфейсного веб-сервера и сервера SQL Server база данных контента и служб стала только немного выше.

• Загрузка ЦП сервера индексирования и SQL Server для поиска увеличилась с 0,5% до 34,6% и с 3,6% до 14,8%.

Выводы

Масштабирование сервера приложений

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

Нагрузка VSTS	416	616	816	1016	1216	1416	1616
Загрузка ЦП сервера приложений (%)	37.6	49.4	57.9	61.9	67.1	65.3	63.10

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

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

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

Трафик Outlook Social Connector и фильтрация по ролям безопасности

Outlook Social Connector — это надстройка, входящая в состав Office 2010, которая показывает действия коллег по SharePoint в Outlook. Надстройка также доступна в качестве бесплатного загружаемого файла для Выпуск 2007 системы Microsoft Office и Microsoft Office 2003.

Outlook Social Connector один раз в час обращается к SharePoint Server, чтобы получить список действий тех пользователей, которые указаны в качестве коллег определенного пользователя. При последующих проверках действий Outlook Social Connector запрашивает только новые действия, произошедшие после последней проверки в SharePoint Server. Таким образом, трафик, порождаемый этой надстройкой, полностью предсказуем. В развертывании Outlook Social Connector и SharePoint Server для 100 000 человек при условии, что все пользователи пользуются надстройкой в течение дня, Outlook Social Connector порождает 100 000 запросов в час, что соответствует 27,77 запросам в секунду.

Отображение действий коллег может привести к потенциальному раскрытию информации. Например, URL-адрес, для которого коллега установил тег, может быть конфиденциальным и не предназначенным для доступа других пользователей. В этом случае пользователь может узнать о существовании такого конфиденциального блока данных в Outlook Social Connector. Для предотвращения раскрытия информации SharePoint Server фильтрует все действия и показывает только те URL-адреса, к которым у пользователя есть доступ в веб-каналах активности. Такая фильтрация называется фильтрацией по ролям безопасности. По умолчанию фильтрация по ролям безопасности включена. Тем не менее, администратор SharePoint Server может ее отключить.

Не для всякого действия требуется фильтрация по ролям безопасности. Из шестнадцати поддерживаемых в SharePoint Server 2010 типов действий только четыре (установка тегов, создание комментариев доски заметок, установка рейтингов и изменения членства в списках рассылки) требуют фильтрации по ролям безопасности. Кроме того, поскольку Outlook Social Connector запрашивает только новые действия, произошедшие с последней синхронизации, число действий на пользователя, которые потребуют фильтрации по ролям безопасности, будет достаточно низким.

Каждый запрос от Outlook Social Connector, для которого требуется фильтрация по ролям безопасности, ведет к созданию прошедшего проверку подлинности вызова Windows Communication Foundation (WCF) к серверу приложений для службы поиска. Чтобы получить маркер проверки подлинности для этого вызова, вызов WCF сначала направляется в службу маркеров безопасности.

Мы обнаружили, что когда число запросов Outlook Social Connector в секунду превышало восемь для каждого интерфейсного веб-сервера, служба маркеров безопасности попадала под сильную нагрузку. Нагрузка на службу маркеров безопасности необязательно будет возникать для каждого пользователя, поскольку она зависит от общего числа пользователей и объема операций с социальными тегами, которые имеются среди действий коллег конкретного пользователя. В наборе данных, который мы подготовили, и с имевшимися пользователями число действий, требующих фильтрации по ролям безопасности, было достаточным, и мы видели этот механизм в действии. Поэтому мы увеличили трафик Outlook Social Connector в соответствии с числом доступных интерфейсных веб-серверов. В конфигурации 1x1x1, мы создали трафик Outlook Social Connector с 8 запросами в секунду. А в конфигурации 2x1x1 был создан трафик Outlook Social Connector с 16 запросами в секунду и т. д.

Это означает, что с имевшимся для тестирования набором данных, тестовым набором и оборудованием мы могли бы обеспечить поддержку 8 × 60 × 60, то есть 28 800 запросов в час. Учитывая особенности работы Outlook Social Connector, это означает, что мы могли бы поддерживать 28 800 сотрудников использующих Outlook Social Connector на одном интерфейсном веб-сервере с включенной фильтрацией по ролям безопасности. Аналогично, мы могли поддерживать 28 800 × 3, то есть 86 400 сотрудников, использующих Outlook Social Connector на трех интерфейсных веб-серверах с включенной фильтрацией по ролям безопасности.

Эти результаты помогут спланировать оборудование, необходимое для поддержки трафика Outlook Social Connector, однако мы понимаем, что они полностью зависят от использовавшихся набора данных, тестового набора и оборудования. Помните также, что фильтрацию по ролям безопасности можно выключить с помощью Windows PowerShell 2,0, либо можно изменить частоту синхронизации Outlook Social Connector с SharePoint Server. Оба этих варианта окажут серьезное влияние на требования к оборудованию.

Результаты по итерациям

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

Топология 1x1x1

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

Сводка по результатам

• В дополнение к тестовому набору, представленному выше в этой статье, в данной ферме имелся трафик интенсивностью 8 запросов в секунду от Outlook Social Connector с запросом событий из веб-канала активности для пользователя.

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

• В этой конфигурации число запросов в секунду для Зеленой зоны составило 137,25 с задержкой 0,12 с для не менее 75% запросов и загрузкой ЦП интерфейсного веб-сервера в районе 47,8%. Это говорит о том, что данная ферма может поддерживать около 137,25 запросов в секунду. Число запросов в секунду для Максимальной зоны в данной ферме составило 203,2 с задержками в 0,22 с и загрузкой ЦП интерфейсного веб-сервера в районе 85%.

• Поскольку узким местом оказался интерфейсный веб-сервер, в следующей итерации мы добавили еще один интерфейсный веб-сервер.

Счетчики производительности и графики

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

Нагрузка VSTS	52	77	102	127	152	177
RPS	99.8	147	188	218	238	243
Загрузка ЦП интерфейсного веб-сервера	33,9	50	71,8	81,1	90,8	89
Загрузка ЦП сервера приложений	7,92	11,7	13,5	14,1	13,9	13,3
Загрузка ЦП сервера SQL Server	4,7	6,48	7,99	8,21	8,41	8,88
75-й процентиль [с]	0,13	0,16	0,17	0,25	0,3	0,45
95-й процентиль [с]	0,29	0,47	0,41	0,55	0,55	0,77

Топология 2x1x1

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

Сводка по результатам

• Помимо тестового набора, представленного выше в этой статье, в данной ферме имелся трафик интенсивностью 64 запроса в секунду от Outlook Social Connector с запросами событий из веб-канала активности для пользователя.

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

• В этой конфигурации число запросов в секунду для Зеленой зоны составило 278 с задержкой 0,16 с для не менее 75% запросов и загрузкой ЦП интерфейсного веб-сервера в районе 47%. Это говорит о том, что данная ферма может поддерживать около 278 запросов в секунду с использованным тестовым набором и оборудованием. Число запросов в секунду для Максимальной зоны в данной ферме составило 450 с задержками в 0,23 с и загрузкой ЦП интерфейсного веб-сервера в районе 78%.

• Поскольку в данной итерации узким местом оказался ЦП интерфейсного веб-сервера, в следующей итерации мы добавили еще один интерфейсный веб-сервер.

Счетчики производительности и графики

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

Нагрузка VSTS	104	154	204	254	304	354
RPS	190	278	390	455	500	520
Загрузка ЦП интерфейсного веб-сервера	36	50,9	71,9	86,9	87,1	89,5
Загрузка ЦП сервера приложений	16	24,9	28,3	26,5	26,5	24,9
Загрузка ЦП сервера SQL Server	8,06	10,6	14,2	16,4	17,9	18,9
75-й процентиль [с]	0,16	0,22	0,22	0,33	0,42	0,53
95-й процентиль [с]	0,42	0,64	0,51	0,69	0,73	0,89

Топология 3x1x1

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

Сводка по результатам

• В дополнение к тестовому набору, представленному раньше в этой статье, в данной ферме имелся трафик интенсивностью 24 запросов в секунду от Outlook Social Connector с запросом событий из веб-канала активности для пользователя.

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

• В этой конфигурации число запросов в секунду для Зеленой зоны составило 440 с задержкой 0,14 с для не менее 75% запросов и загрузкой ЦП интерфейсного веб-сервера в районе 48%. Это говорит о том, что данная ферма может поддерживать около 440 запросов в секунду с использованным тестовым набором и оборудованием. Число запросов в секунду для Максимальной зоны в данной ферме составило 615 с задержками в 0,22 с и загрузкой ЦП интерфейсного веб-сервера в районе 70%.

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

Счетчики производительности и графики

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

Нагрузка VSTS	156	231	306	381	456	531
RPS	264	393	532	624	634	629
Загрузка ЦП интерфейсного веб-сервера	30,5	46,3	62,55	72,95	75,4	76
Загрузка ЦП сервера приложений	22,7	35,6	34,2	32,5	32,5	29,4
Загрузка ЦП сервера SQL Server	10,4	14,8	20,8	22,5	22,8	22,4
75-й процентиль [с]	0,17	0,26	0,27	0,28	0,31	0,40
95-й процентиль [с]	0,63	1,08	0,76	0,68	0,88	0,98

Топология 5x1x1

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

Сводка по результатам

• В дополнение к тестовому набору, представленному раньше в этой статье, в данной ферме имелся трафик интенсивностью 40 запросов в секунду от Outlook Social Connector с запросом событий из веб-канала активности для пользователя.

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

• В этой конфигурации число запросов в секунду для Зеленой зоны составило 683 с задержкой 0,16 с для не менее 75% запросов и загрузкой ЦП интерфейсного веб-сервера в районе 46%. Это говорит о том, что данная ферма может поддерживать около 683 запросов в секунду с использованным тестовым набором и оборудованием. Число запросов в секунду для Максимальной зоны в данной ферме составило 971 с задержками в 0,22 с и загрузкой ЦП интерфейсного веб-сервера в районе 68%.

• Учитывая тренд в данных, мы решили добавить три интерфейсный веб-сервера и протестировать конфигурацию 8x1x1. Мы надеялись, что в ней узким местом будет сервер приложений или сервер SQL Server.

Счетчики производительности и графики

Здесь представлены различные счетчики производительности, которые отслеживались при тестировании фермы 5x1x1 на разных этапах пользовательской нагрузки. Поскольку мы не заметили серьезного влияния нагрузки VSTS или изменений конфигурации на задержку, мы перестали ее отслеживать.

Нагрузка VSTS	260	385	510	635	760	885
RPS	359	560	901	1188	1281	1315
Загрузка ЦП интерфейсного веб-сервера	20,5	34	56,2	77,5	86,1	88
Загрузка ЦП сервера приложений	40,2	50,6	66,9	71,3	66,3	58,7
Загрузка ЦП сервера SQL Server	13,9	20,3	34,9	53,6	58,4	64

Топология 8x1x1

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

Сводка по результатам

• В дополнение к тестовому набору, представленному раньше в этой статье, в данной ферме имелся трафик интенсивностью 64 запросов в секунду от Outlook Social Connector с запросом событий из веб-канала активности для пользователя.

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

• В этой конфигурации число запросов в секунду для Зеленой зоны составило 793 с задержкой 0,31 с для не менее 75% запросов и загрузкой ЦП сервера SQL Server в районе 30%. Однако загрузка ЦП сервера приложений составила около 48%. Это говорит о том, что данная ферма может поддерживать около 793 запросов в секунду с использованным тестовым набором и оборудованием. Число запросов в секунду для Максимальной зоны в данной ферме составило 1655 с задержками в 0,31, а загрузка ЦП сервера SQL Server составила около 80%.

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

Счетчики производительности и графики

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

Нагрузка VSTS	416	616	816	1016	1216	1416	1616
RPS	664	1101	1359	1530	1655	1664	1617.00
Загрузка ЦП интерфейсного веб-сервера	26,7	44,4	54,7	61,5	67	65,9	65,10
Загрузка ЦП сервера приложений	37,6	49,4	57,9	61,9	67,1	65,3	63,10
Загрузка ЦП сервера SQL Server	23,2	42	57,9	69,5	79,5	80,8	77,30

Топология 8x1x2

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

Сводка по результатам

• В дополнение к тестовому набору, представленному раньше в этой статье, в данной ферме имелся трафик интенсивностью 64 запросов в секунду от Outlook Social Connector с запросом событий из веб-канала активности для пользователя.

• В ферме с восемью интерфейсными веб-серверами, одним сервером приложений и двумя компьютерами с SQL Server мы могли довести конфигурацию до предела. Узкими местами оказались как интерфейсные веб-серверы, так и сервер приложений, а совокупная загрузка ЦП сервера SQL Server также была чуть менее 80%. При максимальной нагрузке ферма поддерживала 1817 запросов в секунду..

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

Счетчики производительности и графики

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

Нагрузка VSTS	466	666	866	1066	1266	1416
RPS	466,00	873,40	1431,00	1703,00	1766,00	1817,00
Загрузка ЦП интерфейсного веб-сервера	19,90	36,90	57,60	68,00	71,40	71,60
Загрузка ЦП сервера приложений	29,80	47,20	63,50	71,40	71,90	73,40
Общая загрузка ЦП сервера SQL Server	19,61	32,40	55,20	63,60	68,50	74,90
Загрузка ЦП сервера SQL Server базы данных контента	9,93	17,90	31,90	40,10	42,30	45,90
Загрузка ЦП сервера SQL Server базы данных служб	9,68	14,50	23,30	23,50	26,20	29,00

Об авторах

Горав Доши, руководитель программ в Microsoft

Вен Ю Цай, инженер-разработчик программного обеспечения для тестирования в Microsoft

See Also

Other Resources

Центр ресурсов: управление емкостью в SharePoint Server 2010