Планирование мощности для Microsoft SharePoint 2010 Компоненты «Мои сайты» и «Социальные сети» (стр. 4 )

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

Как следует из диаграммы выше,

количество запросов в секунду увеличивалось при добавлении компьютеров в топологию. Очевидно, что вплоть до конфигурации 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	24,31	23,35	38,29
Операций записи в секунду (база данных социального контента)	4,12	9,47	10,63	19,45

Таблица 9. Операции ввода-вывода

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

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

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

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

Таблица 10. Сравнение показателей производительности

Как следует из таблицы выше,

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

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

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

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

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

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

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

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

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

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