Планирование мощности для Microsoft SharePoint Server 2010

Планирование мощности для Microsoft SharePoint Server 2010
Корпорация Майкрософт
Опубликовано: январь 2011 г.
Автор: рабочая группа серверов и системы Microsoft Office ([email protected])
Аннотация
В этом документе представлены сведения о планировании мощности и требованиях к производительности при развертывании
Microsoft SharePoint Server 2010. Рассматриваются вопросы, связанные с изменением размера, проверкой производительности,
ограничениями программного обеспечения и сценариями использования мощности. Этот документ предназначен для
специалистов по работе с бизнес-приложениями, специалистов по работе с бизнес-системами, специалистов по
информационной архитектуре, ИТ-специалистов широкого профиля, руководителей программ и специалистов по обслуживанию
инфраструктуры, ответственных за планирование решения на основе SharePoint Server 2010. Этот документ входит в комплект из
четырех руководств по планированию, содержащих полные сведения об ИТ-планировании для SharePoint Server.
Сведения о планировании архитектуры в среде SharePoint Server 2010 см. в руководстве по планированию серверных ферм и
сред для Microsoft SharePoint Server 2010 (Возможно, на английском языке)
(http://go.microsoft.com/fwlink/?linkid=189513&clcid=0x419) (Возможно, на английском языке).
Сведения о планировании сайтов и решений, созданных при помощи SharePoint Server, см. в руководстве по планированию
сайтов и решений в Microsoft SharePoint Server 2010, часть 1 (Возможно, на английском языке)
(http://go.microsoft.com/fwlink/?linkid=196150&clcid=0x419) (Возможно, на английском языке) и в руководстве по планированию
сайтов и решений в Microsoft SharePoint Server 2010, часть 2 (Возможно, на английском языке)
(http://go.microsoft.com/fwlink/?linkid=208024&clcid=0x419) (Возможно, на английском языке).
Содержимое этого документа является копией избранных материалов технической библиотеки SharePoint Server 2010
(http://go.microsoft.com/fwlink/?linkid=181463&clcid=0x419) на дату публикации. Более новые сведения см. в технической
библиотеке в Интернете.
Этот документ предоставляется на условиях "как есть". Сведения и представления, приведенные в данном документе, включая
URL-адреса и другие ссылки на веб-сайты в Интернете, могут изменяться без уведомления. Риск, связанный с использованием
таких сведений, лежит на пользователе.
Некоторые примеры приведены только в качестве иллюстрации и являются вымышленными. Никакая связь с реально
существующими объектами не предполагается и не подразумевается.
Данный документ не предоставляет никаких юридических прав на интеллектуальную собственность в любых продуктах
Майкрософт. Разрешается копирование и использование данного документа для внутренних справочных целей.
© Корпорация Майкрософт (Microsoft Corporation), 2011. Все права защищены.
Microsoft, Access, Active Directory, Backstage, Excel, Groove, Hotmail, InfoPath, Internet Explorer, Outlook, PerformancePoint,
PowerPoint, SharePoint, Silverlight, Windows, Windows Live, Windows Mobile, Windows PowerShell, Windows Server и Windows Vista
являются охраняемыми товарными знаками корпорации Майкрософт в США и других странах.
Содержание
Планирование мощности для Microsoft SharePoint Server 2010 .............................................................................................................. 1
Получение справки ........................................................................................................................................................................................ 10
Управление производительностью и емкостью (SharePoint Server 2010) ................................................................................................ 11
Capacity management and sizing for SharePoint Server 2010 (на английском языке) ................................................................................ 13
Обзор управления емкостью и изменения размера для SharePoint Server 2010 .................................................................................... 14
Глоссарий .................................................................................................................................................................................................... 15
Кому адресованы статьи об управлении емкостью? .............................................................................................................................. 15
Четыре базовых компонента производительности ................................................................................................................................. 18
Управление емкостью в сравнении с планированием емкости ............................................................................................................. 23
Увеличение номинального размера в сравнении с уменьшением номинального размера ................................................................ 27
Ограничения и границы программного обеспечения .............................................................................................................................. 28
Ключевые различия: сравнение SharePoint Server 2010 с Office SharePoint Server 2007 ................................................................... 30
Ключевые отличительные признаки развертывания SharePoint Server 2010 ...................................................................................... 40
Эталонные архитектуры ............................................................................................................................................................................ 42
См. также ..................................................................................................................................................................................................... 48
Планирование емкости для SharePoint Server 2010 ................................................................................................................................... 49
Шаг 1. Модель ............................................................................................................................................................................................. 49
Шаг 2. Макет................................................................................................................................................................................................ 61
Шаг 3. Пилотный проект, тестирование и оптимизация ......................................................................................................................... 66
Шаг 4. Развертывание................................................................................................................................................................................ 67
Шаг 5. Наблюдение и поддержка .............................................................................................................................................................. 69
См. также ..................................................................................................................................................................................................... 69
Тестирование производительности для SharePoint Server 2010 .............................................................................................................. 70
Создание плана тестирования .................................................................................................................................................................. 71
Создание тестовой среды ......................................................................................................................................................................... 71
Создание тестов и средств тестирования ............................................................................................................................................... 73
См. также ..................................................................................................................................................................................................... 78
Мониторинг и обслуживание SharePoint Server 2010 ................................................................................................................................. 80
Настройка мониторинга ............................................................................................................................................................................. 80
Устранение узких мест ............................................................................................................................................................................... 92
См. также ..................................................................................................................................................................................................... 96
Управление мощностью SharePoint Server 2010: ограничения, связанные с программным обеспечением ........................................ 97
Обзор ограничений, связанных с программным обеспечением ............................................................................................................ 98
Ограничения и границы ........................................................................................................................................................................... 101
Performance and capacity technical case studies (SharePoint Server 2010) (на английском языке) ........................................................ 158
Среда публикации корпоративной интрасети Microsoft SharePoint Server 2010: пример технического внедрения ........................... 160
Необходимые сведения ........................................................................................................................................................................... 160
Общие сведения о среде ......................................................................................................................................................................... 161
Спецификации .......................................................................................................................................................................................... 162
Рабочая нагрузка ...................................................................................................................................................................................... 168
Набор данных ........................................................................................................................................................................................... 169
Данные об исправности и производительности .................................................................................................................................... 170
Enterprise intranet collaboration environment technical case study (SharePoint Server 2010) (на английском языке) ............................ 174
Prerequisite information ............................................................................................................................................................................. 174
Introduction to this environment ................................................................................................................................................................. 175
Specifications ............................................................................................................................................................................................. 176
Health and Performance Data.................................................................................................................................................................... 183
Enterprise intranet collaboration environment lab study (SharePoint Server 2010) (на английском языке)............................................... 187
Introduction to this environment ................................................................................................................................................................. 187
Glossary ..................................................................................................................................................................................................... 188
Overview .................................................................................................................................................................................................... 189
Specifications ............................................................................................................................................................................................. 191
Results and Analysis .................................................................................................................................................................................. 197
Departmental collaboration environment technical case study (SharePoint Server 2010) (на английском языке) .................................... 213
Prerequisite information ............................................................................................................................................................................. 213
Introduction to this environment ................................................................................................................................................................. 214
Specifications ............................................................................................................................................................................................. 215
Workload .................................................................................................................................................................................................... 222
Dataset ....................................................................................................................................................................................................... 223
Health and Performance Data.................................................................................................................................................................... 224
Divisional portal environment lab study (SharePoint Server 2010) (на английском языке) ........................................................................ 228
Introduction to this environment ................................................................................................................................................................. 228
Glossary ..................................................................................................................................................................................................... 229
Overview .................................................................................................................................................................................................... 230
Specifications ............................................................................................................................................................................................. 231
Results and analysis .................................................................................................................................................................................. 239
About the authors ....................................................................................................................................................................................... 259
Social environment technical case study (SharePoint Server 2010) (на английском языке) ...................................................................... 260
Prerequisite information ............................................................................................................................................................................. 260
Introduction to this environment ................................................................................................................................................................. 261
Specifications ............................................................................................................................................................................................. 262
Workload .................................................................................................................................................................................................... 267
Dataset ....................................................................................................................................................................................................... 269
Health and Performance Data.................................................................................................................................................................... 269
Результаты тестирования производительности и емкости и рекомендации (SharePoint Server 2010) ............................................... 274
Estimate performance and capacity requirements for Access Services in SharePoint Server 2010 (на английском языке) ..................... 278
Test farm characteristics ............................................................................................................................................................................ 278
Test results ................................................................................................................................................................................................. 282
Recommendations ..................................................................................................................................................................................... 295
Troubleshooting.......................................................................................................................................................................................... 301
Estimate performance and capacity requirements for Excel Services in SharePoint Server 2010 (на английском языке) ........................ 302
Test farm characteristics ............................................................................................................................................................................ 302
Test Results ............................................................................................................................................................................................... 306
Recommendations ..................................................................................................................................................................................... 322
Оценка требований производительности и емкости для PerformancePoint Services ............................................................................ 328
Тестирование характеристик фермы ..................................................................................................................................................... 328
Сценарии и процессы тестирования ...................................................................................................................................................... 329
Настройки оборудования и топология .................................................................................................................................................... 331
Результаты тестирования........................................................................................................................................................................ 333
Топологии 2M и 3M ................................................................................................................................................................................... 335
Результаты 4M+ для проверки подлинности с помощью автоматической учетной записи службы ................................................ 344
Результаты 4M+ для индивидуальной проверки подлинности пользователей ................................................................................. 344
Рекомендации ........................................................................................................................................................................................... 346
Службы аналитики ................................................................................................................................................................................... 348
Распространенные узкие места и причины их возникновения ............................................................................................................ 349
Мониторинг производительности ........................................................................................................................................................... 352
См. также ................................................................................................................................................................................................... 353
Capacity requirements for Web Analytics Shared Service in SharePoint Server 2010 (на английском языке).......................................... 354
Introduction ................................................................................................................................................................................................. 355
Hardware specifications and topology ....................................................................................................................................................... 357
Capacity requirements ............................................................................................................................................................................... 361
См. также ................................................................................................................................................................................................... 368
Оценка требований к производительности и емкости для управления веб-контентом в SharePoint Server 2010 ............................. 369
Необходимые сведения ........................................................................................................................................................................... 370
Сведения о тестах и используемом подходе ........................................................................................................................................ 370
Развертывание средств управления веб-контентом ............................................................................................................................ 374
Направления оптимизации ...................................................................................................................................................................... 375
Результаты тестов и рекомендации ....................................................................................................................................................... 380
Об авторах ................................................................................................................................................................................................ 414
Estimate performance and capacity planning for workflow in SharePoint Server 2010 (на английском языке) ......................................... 415
Test farm characteristics ............................................................................................................................................................................ 415
Test results ................................................................................................................................................................................................. 420
Recommendations ..................................................................................................................................................................................... 429
Troubleshooting.......................................................................................................................................................................................... 434
См. также ................................................................................................................................................................................................... 436
Планирование и настройка рабочих характеристик хранилища и SQL Server (SharePoint Server 2010) ............................................ 437
Процесс проектирования и настройки уровня хранилища и базы данных для продуктов SharePoint 2010 .................................... 437
Определение требований к дисковому пространству и подсистеме ввода-вывода для хранилища и SQL Server ........................ 438
Выбор версии и выпуска SQL Server ...................................................................................................................................................... 449
Проектирование архитектуры хранилища на основе требований по емкости и вводу-выводу ........................................................ 450
Оценка требований к памяти................................................................................................................................................................... 453
Общие сведения о требованиях к топологии сети ................................................................................................................................ 454
Настройка конфигурации SQL Server ..................................................................................................................................................... 455
Проверка и мониторинг хранилища и производительности SQL Server ............................................................................................. 460
Получение справки
Точность сведений, приведенных в данной книге, тщательно проверялась. Содержимое данного файла соответствует
материалам, доступным в библиотеке Office System на веб-сайте TechNet. В случае возникновения проблем ознакомьтесь с
обновлениями по адресу:
http://technet.microsoft.com/ru-ru/office/bb267342
Если вы не можете найти ответ на веб-сайте, отправьте сообщение электронной почты в рабочую группу серверов и Office
System (Microsoft) по адресу:
[email protected]
Если ваш вопрос касается продуктов Microsoft Office, а не содержимого данной книги, выполните поиск по материалам центра
справки и поддержки и статьям базы знаний Майкрософт, расположенным по адресу:
http://support.microsoft.com/?ln=ru-ru
10
Управление производительностью и емкостью (SharePoint
Server 2010)
Планирование производительности и загрузки — это процесс сопоставления проекта решения Microsoft SharePoint Server 2010 с
размером фермы и набором аппаратного обеспечения для выполнения бизнес-задач.
В Статьи о планировании производительности и емкости для Project Server 2010 можно найти в библиотеке документов
Project Server в разделе Plan for performance and capacity (Project Server 2010).
В этом разделе приведены следующие статьи:
 Обзор управления емкостью и изменения размера для SharePoint Server 2010
В этой статье рассматриваются основные понятия управления емкостью и масштабированием в фермах SharePoint 2010, а
также приводится обзор процесса планирования.
 Планирование емкости для SharePoint Server 2010
В этой статье приводится подробное описание действий и процедур по планированию загрузки для ферм SharePoint 2010.
 Мониторинг и обслуживание SharePoint Server 2010
В этой статье приводятся сведения об обслуживании и мониторинге производительности в фермах SharePoint 2010.
 Тестирование производительности для SharePoint Server 2010
В этой статье приводятся рекомендации по тестированию производительности в фермах SharePoint 2010.
 Управление мощностью SharePoint Server 2010: ограничения, связанные с программным обеспечением
В этой статье приводятся сведения, позволяющие начать планирование производительности и емкости системы. В статью
включены результаты проверки производительности и емкости, а также рекомендации по приемлемой производительности.
 Performance and capacity technical case studies (SharePoint Server 2010) (на английском языке)
В этой статье приводятся ссылки на основные статьи, посвященные примерам технического внедрения и содержащие
сведения о производительности и емкости для конкретных сред, в которых выполняется SharePoint Server 2010.
11

Результаты тестирования производительности и емкости и рекомендации (SharePoint Server 2010)
В этой статье приводятся ссылки на статьи, в которых содержатся результаты тестирования и рекомендации для конкретных
наборов компонентов в SharePoint Server 2010.
 Планирование и настройка рабочих характеристик хранилища и SQL Server (SharePoint Server 2010)
В этой статье описывается процесс планирования емкости хранилища и SQL Server для развертывания SharePoint Server
2010.
При планировании загрузки также могут быть полезны следующие ресурсы:
 Determine hardware and software requirements (SharePoint Server 2010)

Технические графики:

Топологии для SharePoint Server 2010

Архитектура поиска для Microsoft SharePoint Server 2010

Создание архитектуры поиска для Microsoft SharePoint Server 2010

Планирование среды поиска для Microsoft SharePoint Server 2010
Для загрузки этих моделей посетите страницу Technical diagrams (SharePoint Server 2010).
12
Capacity management and sizing for SharePoint Server 2010 (на
английском языке)
The articles in this section help you to make the following decisions regarding the appropriate capacity for your Microsoft SharePoint
Server 2010 environment:
 Understand the concepts behind effective capacity management.

Define performance and capacity targets for your environment.

Select the appropriate data architecture.

Choose hardware to support the number of users and the features you intend to deploy.

Test, validate, and adjust your environment to achieve your performance and capacity targets.
 Monitor and adjust your environment to match demand.
In this section:
 Обзор управления емкостью и изменения размера для SharePoint Server 2010

Планирование емкости для SharePoint Server 2010

Тестирование производительности для SharePoint Server 2010

Мониторинг и обслуживание SharePoint Server 2010
13
Обзор управления емкостью и изменения размера для
SharePoint Server 2010
В этой статье представлен обзор способов эффективного планирования и управления емкостью сред Microsoft SharePoint Server
2010. В этой статье также рассказано о том, как анализ производительности помогает лучше понять потребность в емкости и
оценить возможности планируемого развертывания. Также рассматривается влияние основных приложений на емкость среды,
включая характеристики контента и потребление ресурсов.
Управление емкостью представляет собой непрерывный процесс, поскольку такие аспекты реализованного решения, как
контент и потребление ресурсов, не могут оставаться неизменными. Необходимо планировать емкость с учетом развития и
изменения, чтобы среда на основе SharePoint Server 2010 предоставляла достаточно возможностей для эффективной работы.
Планирование емкости представляет собой лишь один из этапов цикла управления емкостью. Это исходный набор действий,
который позволяет архитектору достичь того уровня исходной архитектуры, который, по его мнению, оптимально обеспечивает
работоспособность среды SharePoint Server 2010. Модель управления емкостью также предусматривает дополнительные этапы,
позволяющие выполнить проверку и настройку исходной архитектуры; а также предоставляет цепь обратной связи для
повторного планирования и оптимизации производственной среды, обеспечивающей выполнение задач разработки для
оптимального выбора оборудования, топологии и конфигурации.
Содержание:
 Глоссарий

Кому адресованы статьи об управлении емкостью?

Четыре базовых компонента производительности

Управление емкостью в сравнении с планированием емкости

Увеличение номинального размера в сравнении с уменьшением номинального размера

Ограничения и границы программного обеспечения

Ключевые различия: сравнение SharePoint Server 2010 с Office SharePoint Server 2007

Ключевые отличительные признаки развертывания SharePoint Server 2010
14

Эталонные архитектуры
Глоссарий
В документации по управлению емкостью SharePoint Server 2010 используются следующие специальные термины.
 RPS Запросов в секунду. Количество запросов, получаемое фермой или сервером за одну секунду. Эта величина является
стандартным показателем измерения нагрузки сервера или фермы. Количество запросов, обрабатываемых фермой,
превышает количество загрузок страницы и действий конечных пользователей. Это обусловлено тем, что каждая страница
содержит несколько компонентов, каждый из которых при загрузке страницы создает один или несколько запросов. Затраты
на транзакцию для одних запросов могут быть меньше, чем для других. В лабораторных тестах и документации по
конкретным примерам в расчет RPS не включены 401 запрос и ответ (связанные с проверкой подлинности), так как они не
оказывают значительного влияния на ресурсы фермы.

Часы пиковой загрузки Время суток (один или несколько раз в сутки), когда загрузка фермы максимальна.

Пиковая загрузка Средняя максимальная загрузка в день, измеряемая в RPS (запросов в секунду).

Скачок загрузки Временные скачки загрузки вне обычных часов пиковой загрузки. Такие скачки могут быть вызваны
незапланированным увеличением пользовательского трафика, снижением пропускной способности фермы из-за
административных операций или сочетанием этих факторов.

Вертикальное масштабирование Вертикальным масштабированием называется добавление для сервера таких ресурсов,
как процессоры или память.

Горизонтальное масштабирование Горизонтальным масштабированием называется добавление дополнительных
серверов в ферму.
Кому адресованы статьи об управлении емкостью?
Чтобы решить, стоит ли вам читать эту статью, рассмотрите следующие вопросы.
Оценка SharePoint Server 2010
Я отвечаю за принятие решений в ИТ-отделе или организации и занимаюсь поиском решения для конкретных задач. Я
рассматриваю SharePoint Server 2010 как возможный вариант решения в рамках существующей среды. Сможет ли этот
продукт обеспечить функции и возможности масштабирования, соответствующие моим требованиям?
15
Сведения о способах масштабирования SharePoint Server 2010 в соответствии с требованиями отдельных решений, а также об
определении оборудования для обеспечения текущих потребностей см. в следующих разделах настоящей статьи:
 Ключевые различия: сравнение SharePoint Server 2010 с Office SharePoint Server 2007
 Ограничения и границы программного обеспечения
Сведения о способах оценки соответствия SharePoint Server 2010 конкретным бизнес-требованиям см. в следующих статьях:
 Product evaluation for SharePoint Server 2010

Управление мощностью SharePoint Server 2010: ограничения, связанные с программным обеспечением
Обновление версии Office SharePoint Server 2007
В настоящее время я использую Office SharePoint Server 2007. Что изменилось в версии SharePoint Server 2010? Что следует
принять во внимание при обновлении версии? Как обновление версии повлияет на производительность и масштабирование
топологии?
Сведения о различиях между коэффициентами емкости и производительности Office SharePoint Server 2007 в сравнении с
SharePoint Server 2010 см. в следующем разделе данной статьи:
 Ключевые различия: сравнение SharePoint Server 2010 с Office SharePoint Server 2007
Сведения об общих параметрах обновления версии и инструкции по планированию и выполнению обновления версии Office
SharePoint Server 2007 см. в следующей статье:
 Upgrading to SharePoint Server 2010
Настройка и оптимизация динамической среды на основе SharePoint
Выполнено развертывание SharePoint Server 2010, и я хочу убедиться в наличии соответствующего оборудования и
топологии. Как проверить архитектуру и правильно ее настроить?
Сведения о счетчике производительности и счетчике системного монитора для ферм Microsoft SharePoint Server 2010 см. в
следующей статье:
 Мониторинг и обслуживание SharePoint Server 2010
Сведения о способах использования инструментов мониторинга исправности, встроенных в интерфейс центра
администрирования, см. в следующей статье:
 Health Monitoring (SharePoint Server 2010)
Выполнено развертывание SharePoint Server 2010, и возникли проблемы с производительностью. Как выполнить диагностику
и устранение неисправностей и оптимизировать среду?
16
Сведения о счетчике производительности и счетчике системного монитора для ферм Microsoft SharePoint Server 2010 см. в
следующей статье:
 Мониторинг и обслуживание SharePoint Server 2010
Сведения о диагностике и устранении неисправностей с помощью инструментов мониторинга исправности, встроенных в
интерфейс центра администрирования, см. в следующей статье:
 Solving Problems and Troubleshooting (SharePoint Server 2010)
Список статей об управлении емкостью, доступной для многих конкретных служб и компонентов SharePoint Server 2010, см. в
следующей статье (дополнительные статьи будут добавляться в этот список по мере их подготовки):
 Результаты тестирования производительности и емкости и рекомендации (SharePoint Server 2010)
Сведения о производительности и изменении размера баз данных см. в следующей статье:
 Планирование и настройка рабочих характеристик хранилища и SQL Server (SharePoint Server 2010)
Сведения об удаленном хранилище больших двоичных объектов см. в следующей статье:
 Plan for remote BLOB storage (RBS) (SharePoint Server 2010)
От начала до конца
Я хочу узнать все об управлении емкостью в SharePoint Server 2010. С чего начать?
Сведения об общих принципах управления емкостью и ссылки на дополнительную документацию и ресурсы см. в следующей
статье:
 Управление производительностью и емкостью (SharePoint Server 2010)
Дополнительные сведения об управлении емкостью см. в следующих дополнительных статьях к этой обзорной статье:
 Планирование емкости для SharePoint Server 2010

Тестирование производительности для SharePoint Server 2010
 Мониторинг и обслуживание SharePoint Server 2010
Теперь, когда вы познакомились с основными понятиями, можно просмотреть сведения об ограничениях и границах SharePoint
Server 2010 в следующей статье:
 Управление мощностью SharePoint Server 2010: ограничения, связанные с программным обеспечением
Чтобы определить начальную точку в топологии своей среды на основе SharePoint Server 2010, можно просмотреть библиотеку
доступных технических примеров для поиска конкретного примера, оптимально соответствующего требованиям организации.
Список конкретных примеров (пополняется по мере появления новых примеров) см. в следующей статье:
17
 Performance and capacity technical case studies (SharePoint Server 2010) (на английском языке)
Список статей об управлении емкостью, доступной для многих конкретных служб и компонентов SharePoint Server 2010, см. в
следующей статье (дополнительные статьи будут добавляться в этот список по мере их подготовки):
 Результаты тестирования производительности и емкости и рекомендации (SharePoint Server 2010)
Сведения о производительности и изменении размера баз данных см. в следующей статье:
 Планирование и настройка рабочих характеристик хранилища и SQL Server (SharePoint Server 2010)
Сведения об удаленном хранилище больших двоичных объектов см. в следующей статье:
 Plan for remote BLOB storage (RBS) (SharePoint Server 2010)
Сведения о мониторинге, диагностике и устранении неисправностей с использованием инструментов мониторинга исправности,
встроенных в интерфейс центра администрирования, см. в следующих статьях:
 Health Monitoring (SharePoint Server 2010)
 Solving Problems and Troubleshooting (SharePoint Server 2010)
Инструкции по общей настройке производительности, а также другие статьи по вопросам производительности и емкости
(дополнительные статьи добавляются по мере их доступности) см. в следующей статье:
 Use search administration reports (SharePoint Server 2010)
Дополнительные сведения о способах виртуализации серверов на основе SharePoint Server 2010 см. в следующей статье:
 Virtualization planning (SharePoint Server 2010)
Четыре базовых компонента производительности
Управление емкостью связано с четырьмя основными аспектами изменения размера решения:
 Задержка В рамках управления емкостью задержка определяется как период между временем запуска действия
пользователем (например, переход по гиперссылке) и временем передачи последнего байта в клиентское приложение или
веб-браузер.

Пропускная способность Пропускная способность определяется как количество параллельных запросов, которые могут
быть обработаны сервером или серверной фермой.
18

Масштаб данных Масштаб данных определяется как размер контента и состав данных, которые могут быть размещены в
системе. Структура и распространение баз данных контента существенно влияют на время обработки запросов системой
(задержка) и на количество обрабатываемых запросов (пропускная способность).

Надежность Надежность представляет собой показатель способности системы достигать заданных целевых значений
задержки и пропускной способности.
Основной целью управления емкостью среды является настройка и обслуживание системы, обеспечивающей достижение
целевых показателей задержки, пропускной способности, масштаба данных и надежности, установленных для организации.
Задержка
Задержка или задержка, распознаваемая конечным пользователем, включает три основных компонента:
 Время, затраченное сервером на получение и обработку запроса.

Время, затраченное на передачу запроса и отклика сервера по сети.
 Время, затраченное на отображение отклика в клиентском приложении.
Для различных организаций определены различные целевые значения задержки в зависимости от бизнес-требований и
ожиданий пользователей. Некоторые организации могут позволить себе задержку в несколько секунд, в то время как другим
требуется максимальная скорость транзакции. Оптимизация скорости транзакций требует наличия более мощных серверов и
клиентов, новейших версий браузера и клиентского приложения, сетевых решений для каналов с высокой пропускной
способностью, а также, возможно, дополнительных инвестиций в разработку и настройку страниц.
Некоторые ключевые факторы, увеличивающие задержку, распознаваемую конечным пользователем, а также примеры
некоторых распространенных проблем описаны в следующем списке. Эти факторы имеют особое значение в сценариях, где
клиенты географически удалены от серверной фермы или осуществляют доступ к ферме посредством сетевого подключения с
использованием канала с низкой пропускной способностью.
 Компоненты, службы или параметры конфигурации, для которых не выполнялась оптимизация, могут вызвать задержку в
обработке запросов и повлиять на значение задержки для удаленных и локальных клиентов. Дополнительные сведения см. в
разделах Пропускная способность и Надежность далее в этой статье.

Веб-страницы, создающие необязательные запросы к серверу при загрузке требуемых данных и ресурсов. Оптимизация
подразумевает загрузку минимального количества ресурсов для отрисовки страницы, то есть сокращение размера
изображений, статическое хранение ресурсов в папках в целях анонимного доступа, кластеризацию запросов и возможность
интерактивной работы со страницей во время асинхронной загрузки ресурсов с сервера. Такие функции оптимизации имеют
существенное значение для создания хорошего впечатления при первом посещении сайта.
19

Избыточный объем данных, передаваемых по сети, способствует увеличению задержки и снижению пропускной способности.
Например, для изображений и других двоичных объектов следует по возможности использовать сжатый формат (PNG или
JPG) вместо растрового (BMP).

Веб-страницы, не оптимизированные для ускорения повторной загрузки страниц. Время загрузки страницы (PLT)
сокращается при ее повторной загрузке, поскольку некоторые ресурсы страницы кэшируются в клиенте и браузеру
приходится загружать лишь динамический некэшируемый контент. Недопустимые задержки при повторной загрузке страницы
зачастую возникают из-за неправильной конфигурации кэша больших двоичных объектов (BLOB) или вследствие отключения
кэширования локального браузера на клиентских компьютерах. Оптимизация подразумевает правильное кэширование
ресурсов на клиенте.

Веб-страницы, содержащие неоптимизированный код JavaScript. Это может замедлить отображение страницы в клиенте. При
оптимизации обработка кода JavaScript в клиенте будет отложена до тех пор, пока не загрузится остальная часть страницы;
также предпочтительно выполнить вызов скриптов вместо добавления встроенного кода JavaScript.
Пропускная способность
Пропускная способность выражается в количестве запросов, которые могут быть обработаны серверной фермой за единицу
времени, а также зачастую используется для оценки масштаба операций, предположительно поддерживаемых системой, в
зависимости от масштабов организации и ее характеристик потребления. Каждая операция характеризуется определенными
затратами ресурсов фермы. Для понимания потребностей и развертывания архитектуры фермы, способной последовательно
удовлетворять потребности, требуется оценка предполагаемой загрузки и проверка архитектуры под нагрузкой для
подтверждения соответствия значения задержки установленному целевому уровню при высоком уровне параллелизма в
условиях значительной рабочей нагрузки на систему.
Далее приведены несколько распространенных причин снижения пропускной способности.
 Недостаточные аппаратные ресурсы Если ферма получает больше запросов, чем она способна обрабатывать
параллельно, некоторые запросы помещаются в очередь, в которой обработка каждого последующего запроса
задерживается в накопительном порядке до тех пор, пока объем спроса не сократится настолько, чтобы можно было
очистить очередь. Далее приведены несколько примеров оптимизации фермы в целях обеспечения более высокой
пропускной способности:

Убедитесь в том, что уровень использования процессоров серверов в ферме не превышен. Например, если
использование ресурсов ЦП в часы пиковой загрузки или уровень скачков загрузки постоянно превышает 80 %,
необходимо добавить дополнительные серверы или перераспределить службы на другие серверы фермы.
20



Убедитесь в том, что для серверов приложений и веб-серверов доступно достаточно памяти, чтобы в ней полностью
содержался кэш. Это позволяет избежать вызовов базы данных для обслуживания запросов некэшированного контента.

Убедитесь в том, что серверы базы данных не содержат узких мест. Если общего доступного объема операций вводавывода в секунду для данного диска недостаточно для обеспечения потребности в пиковые часы загрузки, необходимо
добавить дополнительные диски или перераспределить базы данных на диски с неполной загрузкой. Дополнительные
сведения см. в разделе "Устранение узких мест" в статье "Мониторинг и обслуживание продуктов и технологий SharePoint
Server 2010".

Если добавления ресурсов для существующих компьютеров недостаточно, чтобы разрешить проблему пропускной
способности, следует добавить серверы и перераспределить затронутые функции и службы на новые серверы.
Неоптимизированные пользовательские веб-страницы Добавление пользовательского кода на часто используемые
страницы в производственной среде — распространенная причина возникновения проблем с пропускной способностью.
Добавление пользовательского кода может создавать дополнительные полные обходы серверов базы данных или веб-служб
для запросов служебных данных. Настройка редко используемых страниц может не оказывать существенного влияния на
пропускную способность, однако даже оптимизированный код способен снизить пропускную способность фермы, если
запросы к нему отправляются несколько тысяч раз в день. Администраторы SharePoint Server могут включить панель
разработчика для обнаружения пользовательского кода, который требует оптимизации. Далее приведены несколько
примеров оптимизации пользовательского кода:

Минимизация количества запросов к веб-службам и SQL-запросов.

Выбор минимального объема требуемых данных в каждом обращении к серверу базы данных при минимизации
количества обязательных полных обходов.

Запрет на добавление пользовательского кода на часто используемые страницы.

Использование индексов при извлечении фильтрованных данных.
Ненадежное решение Развертывание пользовательского кода в папках "Bin" может вызвать снижение быстродействия
сервера. При каждом запросе страницы, содержащей ненадежный код, SharePoint Server 2010 будет выполнять проверку
безопасности, прежде чем разрешить загрузку страницы. За исключением случаев, когда развертывание ненадежного кода
обусловлено определенными причинами, необходимо установить пользовательские сборки в глобальный кэш сборок во
избежание ненужной проверки безопасности.
Масштаб данных
21
Масштаб данных представляет собой объем данных, который может храниться на сервере или в серверной ферме при
соблюдении целевых значений задержки и пропускной способности. Как правило, чем больше объем данных в ферме, тем
большее это влияет на пропускную способность и взаимодействие с пользователем в целом. Метод, используемый для
распределения данных по дискам и серверам базы данных, также может повлиять на значения задержки и пропускной
способности фермы.
Размер, архитектура и достаточное аппаратное обеспечение сервера базы данных имеют основополагающее значение для
выбора оптимального решения для базы данных. В идеальной среде размер базы данных контента устанавливается в
зависимости от требований к ограничениям; базы данных распределяются по физическим дискам таким образом, чтобы
исключить создание очереди запросов вследствие чрезмерного использования ресурсов диска. При этом серверы базы данных
способны поддерживать пиковые нагрузки и непредвиденные скачки нагрузок, не превышая пороговые значения объемов
потребления ресурсов.
Также при выполнении определенных операций могут блокироваться некоторые таблицы. В качестве примера можно привести
операцию удаления большого сайта, которая может блокировать связанные таблицы в базе данных контента, где размещен
сайт, вплоть до завершения операции удаления.
Далее приведены несколько примеров оптимизации фермы в целях обеспечения быстродействия данных и хранения:
 Убедитесь в том, что базы данных надлежащим образом распределены по серверам базы данных и ресурсы сервера базы
данных являются достаточными для обеспечения такого объема и распределения данных.

Разделяйте тома баз данных по отдельным логическим устройствам (LUN), состоящим из отдельных физических дисководов.
Для обеспечения потребностей хранения на сервере базы данных используйте несколько дисков с малым временем поиска и
соответствующей конфигурацией RAID-массива.

Можно использовать удаленное хранилище BLOB-данных, если данные содержат много больших двоичных объектов (BLOB).
Удаленное хранилище BLOB-данных предоставляет следующие преимущества:

Данные большого двоичного объекта могут храниться на менее дорогих устройствах, которые настроены для простой
обработки данных обработки.

Хранением большого двоичного объекта управляет система, специально разработанная для работы с данными больших
двоичных объектов.

Высвобождаются ресурсы сервера для операций базы данных.
Эти преимущества не бесплатны. Перед тем как реализовать удаленное хранилище больших двоичных объектов в
рамках SharePoint Server 2010, необходимо оценить потенциальные преимущества по сравнению с затратами, а также
ограничения, которые повлекут за собой реализация и обслуживание удаленного хранилища BLOB-объектов.
22
Дополнительные сведения см. в разделе Plan for remote BLOB storage (RBS) (SharePoint Server 2010).
Дополнительные сведения о планировании масштаба данных см. в разделе Планирование и настройка рабочих характеристик
хранилища и SQL Server (SharePoint Server 2010).
Надежность
Надежность представляет собой совокупный показатель способности серверной фермы достигать заданных целевых значений
задержки, пропускной способности и емкости данных. Надежной считается ферма, время работы, реагирование, процент сбоев и
частота и амплитуда пиков задержки не выходит за рамки установленных целевых значений и эксплуатационных требований.
Надежная ферма способна также поддерживать заданные целевые значения задержки и пропускной способности при пиковых
нагрузках или во время выполнения системных операций (например, обход или ежедневное резервное копирование).
Основным фактором в обеспечении надежности является влияние стандартных административных операций на целевые уровни
производительности. Во время выполнения определенных операций (например, повторное построение индексов базы данных,
задания таймера обслуживания или удаление нескольких сайтов с большими объемами контента), система, возможно, не сможет
быстро обрабатывать пользовательские запросы. Это затронет уровни как задержки, так и пропускной способности для
пользовательских запросов. Степень воздействия на ферму зависит от частоты и затрат на транзакцию, предусмотренных для
таких менее распространенных операций, а также от того, выполняются ли они в рабочее или нерабочее время.
Далее приведены несколько способов повышения надежности системы.
 Планирование ресурсоемких заданий таймера и административных задач на период пониженной загрузки.

Вертикальное масштабирование оборудования на существующих серверах фермы или горизонтальное масштабирование
путем добавления веб-серверов, серверов приложений или дополнительных серверов баз данных.

Распределение ресурсоемких служб и компонентов по специализированным серверам. Можно также использовать службу
балансировки аппаратной нагрузки для направления трафика отдельных компонентов на веб-серверы, специально
выделенные для определенных компонентов и служб.
Управление емкостью в сравнении с планированием емкости
Процесс управления емкостью является логическим продолжением процесса планирования загрузки в рамках циклического
подхода, подразумевающего непрерывные мониторинг и оптимизацию емкости развертывания SharePoint Server 2010 в
соответствии с изменяющимися условиями и требованиями.
23
SharePoint Server 2010 обладает гибкими возможностями и может настраиваться для сценариев с различными уровнями
масштабирования. Архитектура развертывания зависит от конкретного случая. Таким образом, разработчики и администраторы
системы должны хорошо понимать и ориентироваться в требованиях, предусматриваемых конкретной средой.
Модель управления емкостью SharePoint Server 2010
24
25



Этап 1. Модель Моделирование представляет собой процесс, с помощью которого определяются ключевые решения,
поддержка которых требуется в рамках конкретной среды, а также устанавливаются все важнейшие параметры и показатели.
В результате моделирования создается список всех ключевых данных, которые потребуются при разработке среды.

Определение предполагаемой рабочей нагрузки и наборов данных.

Определение целевых значений производительности и надежности фермы.

Анализ журнала служб IIS SharePoint Server 2010.
Этап 2. Разработка По завершении сбора данных на этапе 1 можно приступать к разработке фермы. В результате должна
быть создана детализированная архитектура данных, а также физическая и логическая топология.

Определение начальной архитектуры.

Выбор оборудования.
Этап 3. Пилотный проект, тестирование и оптимизация После разработки новой среды необходимо выполнить
развертывание пилотного проекта среды для тестирования в условиях рабочей нагрузки и с предполагаемыми
характеристиками потребления. Для существующей фермы тестирование рекомендуется выполнять в том случае, если в
инфраструктуру внесены существенные изменения, однако для поддержания целевых значений производительности может
потребоваться регулярная оптимизация в зависимости от результатов мониторинга. Итогом этого этапа является анализ
результатов тестирования и создание оптимизированной архитектуры, способной поддерживать заданные целевые значения
производительности и емкости.

Пилотный проект Развертывание пилотного проекта среды.

Тестирование Тестирование в сравнении с целевыми значениями задержки и пропускной способности.

Оптимизация Сбор результатов тестирования и внесение необходимых изменений в ресурсы и топологию фермы.

Этап 4. Развертывание На этом этапе выполняется реализация фермы или развертывание изменений для существующей
фермы. Результатом внедрения новой разработки является развертывание динамического производства, включая все
переносы контента и пользовательских данных. Для существующей фермы выполняется изменение сопоставлений фермы и
обновление планов обслуживания.

Этап 5. Мониторинг и облуживание На этом этапе предусматривается настройка функций мониторинга, прогнозирования
и выявления узких мест, выполнения регулярного обслуживания и операций по устранения узких мест.
26
Увеличение номинального размера в сравнении с уменьшением
номинального размера
Увеличением номинального размера называется такой подход к разработке фермы, при котором соответствие целевым
значениям обеспечивается без полного задействования оборудования; при этом ресурсы фермы SharePoint Server используются
в недостаточном объеме. В увеличенной среде по объему памяти, ЦП и прочим показателям ресурсов фермы видно, что среда
способна обеспечивать свои потребности, задействуя меньший объем ресурсов. Недостатком увеличения номинального размера
является увеличение затрат на оборудование и обслуживание, что может привести к увеличению потребности в электроэнергии
и площадях.
Уменьшение номинального объема подразумевает такой подход к разработке фермы, при котором целевые значения
производительности и емкости недостижимы, поскольку аппаратные ресурсы в ферме SharePoint Server задействованы в
избыточном объеме. В отдельных случаях уменьшение номинального размера фермы выполняется в целях снижения затрат на
оборудование, однако в целом это приводит к увеличению задержки, что ведет к нарушению взаимодействия с пользователем,
недовольству пользователей, более частой эскалации, увеличению затрат на техническую поддержку и ненужным затратам на
устранение неисправностей и настройку среды.
На этапе разработки фермы следует убедиться в том, что ферма соответствует установленным требованиям к
производительности и емкости, как при регулярной пиковой нагрузке, так и в условиях непредвиденных скачков. Разработка,
тестирование и оптимизация позволяют убедиться в том, что в ферме используется надлежащее оборудование.
В целях обеспечения целевых уровней производительности и возможностей роста желательно иметь доступ к большему объему
ресурсов, чем это необходимо для выполнения текущих задач. Стоимость дополнительных инвестиций в оборудование, как
правило, значительно ниже, чем совокупные затраты, связанные с диагностикой и устранением неисправностей, вызванных
уменьшением номинального размера.
Необходимо всегда выбирать размер системы таким образом, чтобы адекватно реагировать на увеличение потребности в
ресурсах при пиковых нагрузках, которые могут варьироваться для различных служб в разное время. Для эффективной оценки
потребности в емкости необходимо определить период максимального потребления для всех ресурсов. В определенное время
дня возможно увеличение загрузки по различных компонентам и службам (например, в начале рабочего дня или после
обеденного перерыва).
Ферма также должна обеспечивать работоспособность в период незапланированных пиковых нагрузок; например при отправке
объявлений по всей организации сайт одновременно посещает значительно большее количество пользователей, чем обычно.
Емкость фермы также следует пересмотреть в случае предоставления учетных данных для дополнительных пользователей.
Такие ситуации, как слияние или поглощение, для которых характерно появление новых сотрудников или участников,
27
осуществляющих доступ к ферме, могут негативно сказаться на производительности, если заранее не выполнена их оценка и
планирование.
Операционные состояния: зеленая и красная зона
При описании загрузки производственной системы учитываются два основных операционных состояния: состояние зеленой
зоны, при котором система работает в условиях стандартной ожидаемой загрузки, и состояние красной зоны, при котором для
фермы характерна временная повышенная потребность в ресурсах, при которой работа может поддерживаться только в течение
ограниченного периода, пока не наступит отказ, либо иные неисправности, связанные с производительностью и надежностью.
Зеленая зона Это состояние, при котором сервер или ферма работают в условиях стандартной загрузки (до прогнозируемых
ежедневных пиковых нагрузок). Ферма, работающая в этом диапазоне загрузки, должна обеспечивать время отклика и задержку
в пределах допустимых параметров.
Красная зона Рабочий диапазон, в котором загрузка превышает стандартный уровень пиковой загрузки, однако, система все же
способна в течение ограниченного периода обслуживать запросы.
Конечная цель разработки фермы — развертывание среды, способной обеспечить согласованную работу в режиме загрузки
"красная зона" без отказа службы, с соблюдением допустимых целевых значений задержки и пропускной способности.
Ограничения и границы программного обеспечения
В SharePoint Server 2010 существуют определенные ограничения, предусмотренные при проектировании, изменение которых
недопустимо; а также другие ограничения с установленными значениями по умолчанию, которые могут быть изменены
администратором фермы. Кроме того, существуют ненастраиваемые ограничения, например число семейств веб-сайтов для
одного веб-приложения.
Границы представляют собой абсолютные ограничения, предусмотренные при проектировании, изменение которых
недопустимо. Важно понимать эти ограничения, что позволит избежать ошибочных допущений на этапе проектирования фермы.
В качестве примера границы можно привести документ, размер которого составляет 2 ГБ. Настроить SharePoint Server 2010 для
хранения документов, размер которых превышает 2 ГБ, невозможно. Это встроенное абсолютное значение, которое
предусмотрено при проектировании и не может быть изменено.
Порогом называется ограничение, для которого установлено значение по умолчанию, превышение которого недопустимо, за
исключением тех случаев, когда это значение изменяется. В определенных обстоятельствах пороговое значение может быть
превышено для адаптации расхождений в проекте фермы. Тем не менее, важно понимать, что эти действия могут повлиять на
производительность фермы и фактическое значение других ограничений.
28
В некоторых случаях значение порога по умолчанию может быть превышено только до достижения абсолютного максимального
значения. В качестве примера можно снова привести ограничение по размеру документа. По умолчанию размер документа
ограничен значением 50 МБ, но это значение можно изменить до 2 ГБ (максимум).
Поддерживаемые ограничения определяют проверенные значения для данного параметра. Значения по умолчанию для этих
ограничений были определены посредством тестирования и представляют известные ограничения для продукта. Превышение
поддерживаемых ограничений может повлечь за собой непредвиденные результаты, значительное снижение быстродействия и
производительности или иные отрицательные последствия.
Некоторые поддерживаемые ограничения являются настраиваемыми параметрами, для которых по умолчанию устанавливаются
рекомендуемые значения, в то время как другие ограничения связаны с параметрами, которые не могут быть представлены
настраиваемым значением.
В качестве примера поддерживаемого ограничения можно привести число семейств сайтов для одного веб-приложения.
Значение поддерживаемого ограничения составляет 500 000 семейств сайтов. Это максимальное значение при котором
соблюдаются эталонные показатели производительности, достигнутые в процессе тестирования.
Важно отметить, что многие из ограничений, описываемых в этом документе, представляют собой точку на кривой, описывающей
повышение нагрузки и соответствующее ему снижение производительности. В связи с этим превышение некоторых из
установленных ограничений, например числа семейств веб-сайтов для веб-приложения, повлечет за собой лишь частичное
снижение производительности фермы. Однако в большинстве случаев не рекомендуется работать с близкими к установленным
ограничениям значениями параметров, поскольку оптимальные показатели производительности и надежности достигаются при
разумном балансе между ограничениями на уровне структуры фермы.
Рекомендованные значения порогов и поддерживаемых ограничений определяются на основании производительности. Другими
словами, превышение этих ограничений возможно, однако это может повлечь за собой снижение производительности фермы и
изменение других ограничений. Многие используемые в SharePoint Server 2010 ограничения можно изменять. Тем не менее, в
каждом случае следует четко представлять влияние таких изменений на другие компоненты фермы.
При обращении в службу поддержки пользователей Майкрософт по поводу производственной системы, которая не соответствует
заявленным минимальным требованиям к оборудованию, указанным в документе Hardware and software requirements (SharePoint
Server 2010), помощь не будет предоставлена до тех пор, пока система не будет обновлена с учетом минимальных требований.
Установка ограничений
В SharePoint Server 2010 значения порогов и поддерживаемых ограничений устанавливаются по результатам тестирования и
наблюдения за поведением фермы при повышении нагрузки вплоть до того момента, когда достигаются эффективные рабочие
границы для служб и операций фермы. Некоторые службы и компоненты фермы могут поддерживать более высокие нагрузки,
чем другие. Таким образом, иногда значение ограничения устанавливается как среднее от нескольких показателей.
29
Например, при наблюдении за поведением фермы под нагрузкой в процессе добавления семейств сайтов работе некоторых
компонентов может наблюдаться неприемлемо высокое значение задержки, однако при этом другие компоненты будут работать
в допустимых пределах. В связи с этим устанавливаемое ограничение на максимальное число семейств сайтов не является
абсолютным и вычисляется на основе ожидаемого набора характеристик, при которых общая производительность фермы будет
приемлемой при заданных ограничениях в большинстве ситуаций.
Если другие службы работают при значениях параметров, превышающих используемые при тестировании, фактические
максимальные ограничения для других служб снижаются. В связи с этим важно тщательно тестировать возможности управления
мощностью и масштабирования в каждой конкретной среде, чтобы определить фактические ограничения для этой среды.
Дополнительные сведения о границах и ограничениях, а также об их влиянии на процесс управления емкостью см. в разделе
Управление мощностью SharePoint Server 2010: ограничения, связанные с программным обеспечением.
Ключевые различия: сравнение SharePoint Server 2010 с Office
SharePoint Server 2007
SharePoint Server 2010 предоставляет расширенный набор компонентов и более гибкую модель топологии в сравнении с
предыдущими версиями. Перед использованием этой более сложной архитектуры для предоставления пользователям более
мощных компонентов и функций необходимо внимательно изучить их воздействие на емкость и производительность фермы.
В Office SharePoint Server 2007 предусматривались четыре основные службы, которые можно было включить в поставщиках
общих служб (SSP): служба поиска, служба вычислений Excel, служба профилей пользователей и служба каталогов бизнесданных. Кроме того, существовал относительно небольшой набор клиентов, которые были способны взаимодействовать
непосредственно с Office SharePoint Server 2007.
В SharePoint Server 2010 предусмотрены службы с более высоким уровнем доступности, т. е. приложения-службы SharePoint
(SSA); и SharePoint Server 2010 предоставляет расширенный диапазон клиентских приложений, способных осуществлять
взаимодействие с фермой, включая несколько новых приложений Office, ПО для мобильных устройств, инструменты
разработчика и браузеры. Далее приведены некоторые примеров того, каким образом расширенные взаимодействия клиентов
влияют на характеристики емкости:
 SharePoint Server 2010 включает социальные приложения, интегрируемые с Outlook, разрешающие клиентам Outlook 2010
отображать сведения о получателях электронной почты, запрошенные из фермы SharePoint Server при просмотре сообщений
в клиенте Outlook. Они предоставляют новый набор шаблонов трафика и нагрузку на сервер, которую следует учитывать.

Некоторые новые возможности клиента Microsoft Office 2010 обеспечивают автоматическое обновление данных в ферме
SharePoint Server даже в том случае, когда клиентские приложения открыты, но не используются активно. Такие клиенты, как
30
SharePoint Workspace и OneNote также содержат несколько новых шаблонов трафика и нагрузку на сервер, которую следует
учитывать.

Новые возможности веб-интерактивности SharePoint Server 2010, например Office Web Apps, позволяющие редактировать
файлы Office непосредственно в браузере, используют вызовы AJAX, представляющие несколько новых шаблонов трафика и
нагрузку на сервер, которую следует учитывать.
В Office SharePoint Server 2007 в качестве основного клиента для взаимодействия с сервером использовался веб-браузер. При
использовании расширенного набора функций в SharePoint Server 2010 ожидается увеличение общего количества запросов в
секунду (RPS). Кроме этого, ожидается уменьшение процентной доли запросов, поступающих от браузера, по сравнению с Office
SharePoint Server 2007, благодаря чему появляется возможность увеличения процента нового трафика, поступающего от других
клиентов по мере их внедрения в масштабах организации.
В SharePoint Server 2010 представлена такая новая функция, как собственная встроенная поддержка видео, которая может
увеличить нагрузку на ферму. Некоторые функции также были расширены для поддержки большего масштаба в сравнении с
предыдущими версиями.
В следующем разделе описаны взаимодействия клиентов, клиентские службы и компоненты, а также их производительность и
влияние на емкость системы, которое следует учесть при разработке решения.
Дополнительные сведения об обновлении до SharePoint Server 2010 см. в статье Upgrading to SharePoint Server 2010.
Службы и компоненты
В следующей таблице представлено упрощенное описание требований к ресурсам для различных служб на каждом из уровней.
Пустые поля означают, что служба не запущена или не оказывает влияния на этот уровень.
X — обозначает минимальные или незначительные затраты на ресурс. Предполагается, что служба использует этот ресурс
совместно с другими службами.
XX — обозначает средние затраты на ресурс. Служба может использовать этот ресурс совместно с другими службами, влияние
которых минимально.
XXX — обозначает высокие затраты на ресурс. Использование этого ресурса совместно с другими службами не
предусматривается.
Дополнительные сведения о планировании баз данных SQL Server см. в разделе Планирование и настройка рабочих
характеристик хранилища и SQL Server (SharePoint Server 2010).
Список статей, посвященных управлению емкостью для большинства специализированных служб и компонентов SharePoint
Server 2010 (по мере доступности будут добавляться дополнительные статьи), см. в разделе Результаты тестирования
производительности и емкости и рекомендации (SharePoint Server 2010).
31
Приложение-служба
ЦП веб-сервера
ОЗУ веб- ЦП сервера
сервера приложений
Служба SharePoint
Foundation
XXX
XXX
Служба центра
администрирования
XX
ОЗУ сервера
приложений
XX
ЦП SQL Количество
Хранилище
Server операций
SQL-сервера
ввода-вывода
в секунду для
SQL Server
XX
XXX
XXX
X
X
X
XX
XXX
XXX
XXX
XXX
XXX
Служба регистрации событий * XX
XX
Служба поиска SharePoint
XXX
XXX
XXX
XXX
Приложение-служба Word
Viewing *
X
X
XXX
XX
Служба PowerPoint *
XX
XX
XXX
XX
Служба вычислений Excel
XX
X
XX
XXX
Служба Visio *
X
X
XXX
XXX
X
X
X
Служба Access *
X
X
XXX
XX
X
X
X
Служба профилей
пользователей
X
XX
XX
XX
XXX
XXX
XX
Служба управляемых
метаданных *
X
XX
XX
XX
X
X
XX
Служба веб-аналитики *
X
X
XXX
XXX
XXX
32
Приложение-служба
ЦП веб-сервера
ОЗУ веб- ЦП сервера
сервера приложений
ОЗУ сервера
приложений
Служба подключения к
бизнес-данным *
XX
XX
XXX
XXX
Служба InfoPath Forms
Service
XX
XX
XX
XX
X
X
X
Служба Word Conversion
X
X
XXX
XX
X
X
X
Приложение-служба
PerformancePoint *
XX
XX
XXX
XXX
X
X
X
Служба Project *
X
X
X
X
XXX
XXX
XX
Изолированные решения *
X
X
XXX
XXX
Возможности выполнения
рабочих процессов *
XXX
XXX
Служба таймера
XX
XX
XX
XX
PowerPivot *
X
X
XXX
XXX
XX
XX
XXX
33
ЦП SQL Количество
Хранилище
Server операций
SQL-сервера
ввода-вывода
в секунду для
SQL Server
Примечание.
Звездочкой (*) отмечены новые службы SharePoint Server 2010.

Служба SharePoint Foundation Основная служба SharePoint для совместной работы с контентом. В больших
развертываниях SharePoint Server рекомендуется выделить избыточные веб-серверы в зависимости от прогнозируемого
объема трафика, правильно подобрать мощность компьютеров на основе SQL Server, обслуживающих базы данных
контента, и правильно выделить хранилище в зависимости от размера фермы.

Служба центра администрирования Служба администрирования. Эта служба требует сравнительно небольших ресурсов
емкости. В целях обеспечения избыточности рекомендуется включить службу на нескольких серверах фермы.

Служба регистрации событий Служба, осуществляющая регистрацию показателей потребления и исправности в целях
мониторинга. Эта служба активно использует функцию записи и может потребовать наличия сравнительно большого
пространства на диске в зависимости от количества показателей и частоты их регистрации. В больших развертываниях
SharePoint Server 2010 рекомендуется изолировать базу данных использования от баз данных контента, разместив их на
разных компьютерах на основе SQL Server.

Приложение-служба поиска SharePoint Общее приложение-служба, обеспечивающее возможности индексации и
выполнения запросов. Как правило, эта служба потребляет относительно большой объем ресурсов и может
масштабироваться для обслуживания очень больших развертываний контента. В больших развертываниях SharePoint Server,
где поиск в корпоративной среде имеет существенное значение, рекомендуется использовать для размещения приложенийслужб поиска отдельную "ферму служб" со специализированными ресурсами базы данных; несколько серверов приложений,
обслуживающих отдельные функции поиска (обход или запрос), а также специализированные целевые веб-серверы в
фермах контента, которые обеспечивают приемлемую пропускную способность для выполнения обхода и запроса. Также
можно включить приложения-службы FAST в качестве приложения-службы поиска. Создайте один или несколько
соединителей FAST Search для индексации контента в FAST Search Server 2010 for SharePoint и создайте другой запрос
FAST Search (SSA) для выполнения запросов контента, обход которого выполняется соединителями FAST Search.

Приложение-служба Word Viewing Эта служба позволяет просматривать документы Word непосредственно в браузере.
Эта служба добавляется при установке Office Web Apps вместе с SharePoint Server 2010. Для этой службы требуется, чтобы
сервер приложений подготовил исходные файлы для просмотра в браузере. В больших развертываниях SharePoint Server
34
рекомендуется выполнить горизонтальное масштабирование службы на нескольких серверах приложений в целях
обеспечения избыточности и пропускной способности.
Примечание.
Функция редактирования Word и OneNote в браузере включается при установке Office Web Apps в ферме SharePoint Server 2010. Тем
не менее, этот компонент запускается на веб-серверах фермы без использования приложений-служб.

Приложение-служба PowerPoint Эта служба отображает файлы PowerPoint и позволяет пользователям редактировать их
непосредственно в браузере, а также позволяет осуществлять вещание и совместно использовать динамические
презентации PowerPoint. Эта служба добавляется при установке Office Web Apps в SharePoint Server 2010. Для этой службы
требуется, чтобы сервер приложений подготовил исходные файлы для просмотра в браузере. В больших развертываниях
SharePoint Server, где эта возможность используется сравнительно часто, рекомендуется выполнить развертывание
нескольких серверов приложений в целях обеспечения избыточности и пропускной способности, а также добавить
дополнительные веб-серверы в случае частого использования функции вещания PowerPoint.

Приложение-служба вычислений Excel Эта служба отображает листы Excel непосредственно в браузере и выполняет
вычисления Excel на сервере. Служба также включает функцию редактирования листов непосредственно в браузере при
установке Office Web Apps в SharePoint Server 2010. В больших развертываниях SharePoint Server, где эта возможность
используется сравнительно часто, рекомендуется выделить достаточное количество серверов приложений с достаточным
объемом ОЗУ в целях обеспечения приемлемой производительности и пропускной способности.

PowerPivot для SharePoint Эта служба отображает листы Excel с включенной функцией PowerPivot непосредственно в
браузере. В больших развертываниях SharePoint Server, где эта возможность используется сравнительно часто,
рекомендуется выделить достаточное количество серверов приложений с достаточным объемом ОЗУ и ЦП в целях
обеспечения приемлемой производительности и пропускной способности. Дополнительные сведения см. в статье,
посвященной требованиям к оборудованию и программному обеспечению (PowerPivot для SharePoint).

Приложение-служба Visio Эта служба отображает динамические диаграммы Visio непосредственно в браузере. Эта
служба зависима от приложения-службы состояния сеанса, которому требуется относительно небольшая база данных SQL
Server. Для службы Visio требуется, чтобы сервер приложений подготовил исходные файлы Visio для просмотра в браузере.
В больших развертываниях SharePoint Server, где эта возможность используется сравнительно часто, рекомендуется в целях
обеспечения приемлемой производительности и пропускной способности выполнить горизонтальное масштабирование
службы на несколько серверов приложений с достаточным объемом ЦП и ОЗУ.
35

Приложение-служба доступа Эта служба предназначена для размещения решений Access в SharePoint Server 2010. В
больших развертываниях SharePoint Server, где эта возможность используется сравнительно часто, рекомендуется в целях
обеспечения приемлемой производительности и пропускной способности выполнить горизонтальное масштабирование на
несколько серверов приложений с достаточным объемом ОЗУ. Служба Access использует службу отчетов SQL, которой
требуется база данных SQL Server, расположенная вместе с остальными базами данных.

Приложение-служба профилей пользователей Эта служба обеспечивает выполнение сценариев социальных сетей в
SharePoint Server 2010 и включает синхронизацию функций личных сайтов, тегирования, заметок и профилей с каталогами и
другими возможностями социальной сети. Для службы профилей требуются три относительно ресурсоемких базы данных:
для синхронизации, профилей и тегирования. Эта служба зависима от приложения-службы управляемых метаданных. В
больших развертываниях SharePoint Server рекомендуется распределить эту службу в ферму общих служб и правильно
масштабировать сервер базы данных в целях обеспечения приемлемой производительности для стандартных транзакций и
заданий синхронизации каталогов.

Приложение-служба управляемых метаданных Эта служба обеспечивает работу центрального хранилища метаданных и
синдикацию типов контента в масштабах предприятия. Эту службу можно включить в федерацию специализированной
фермы служб. Эта служба требует использования базы данных, которая может располагаться вместе с другими базами
данных.

Приложение-служба веб-аналитики Эта служба выполняет вычисления и сохраняет для фермы статистику по
характеристикам потребления. Эта служба использует ресурсы и возможности хранения SQL Server в относительно большом
объеме. Эту службу можно включить в федерацию специализированной фермы служб. В больших развертываниях
SharePoint Server рекомендуется изолировать базы данных веб-аналитики от остальных критически важных или
ресурсоемких баз данных путем их размещения на других серверах баз данных.

Приложение-служба подключения к бизнес-данным Эта служба обеспечивает интеграцию различных организационных
бизнес-приложений в SharePoint Server 2010. Для этой службы требуется, чтобы служба приложения поддерживала
подключения данных к внешним ресурсам. В больших развертываниях SharePoint Server, где эта возможность используется
сравнительно часто, рекомендуется в целях обеспечения приемлемой производительности выделить достаточное
количество серверов приложений с достаточным объемом ОЗУ.

Приложение-служба InfoPath Forms Эта служба предоставляет формы SharePoint Server 2010 с доступом через браузер, а
также обеспечивает интеграцию с клиентским приложением InfoPath для создания форм. Для этой службы необходимо
использовать сервер приложений; служба зависима от приложения-службы состояния сеанса, которая требует относительно
небольшой базы данных. Эта служба может располагаться вместе с другими службами, и ее требования к емкости
сравнительно невысоки, хотя они могут расти в зависимости от частоты использования этой возможности.
36

Приложение-служба автоматизации Word Эта служба обеспечивает преобразование файлов Word из одного формата
(например, DOC) в другой (DOCX или PDF). Эта служба требует использования сервера приложений. В крупных
развертываниях SharePoint Server, где эта возможность используется сравнительно часто, рекомендуется в целях
обеспечения приемлемой пропускной способности преобразований выполнить горизонтальное масштабирование службы на
несколько серверов приложений с достаточными ресурсами ЦП. Для этой службы также требуется относительно небольшая
база данных для поддержания очереди заданий преобразования.

Приложение-служба PerformancePoint Эта служба обеспечивает возможности бизнес-аналитики PerformancePoint в
SharePoint Server 2010 и позволяет создавать аналитические зрительные образы. Эта служба требует использования
сервера приложений и базы данных. В больших развертываниях SharePoint Server, где эта возможность используется
сравнительно часто, рекомендуется в целях обеспечения приемлемой производительности и пропускной способности
выделить достаточный объем ОЗУ для серверов приложений.

Приложение-служба Project Эта служба обеспечивает все возможности планирования и отслеживания Microsoft Project
Server 2010 в качестве дополнения к SharePoint Server 2010. Эта служба требует использования службы приложений и
относительно ресурсоемкой базы данных. В крупных развертываниях SharePoint Server, где эта возможность используется
сравнительно часто, рекомендуется выделить специальный сервер базы данных для базы данных Project Server и, возможно,
даже выделить специализированную ферму SharePoint Server для решений управления Project Server.

Служба таймера Этот процесс отвечает за выполнение различных запланированных заданий на различных серверах в
ферме. Система выполняет различные задания таймера; некоторые запускаются на всех серверах фермы, другие — только
на определенных серверах, в зависимости от роли сервера. Некоторые задания таймера довольно ресурсоемки и
потенциально способны создать нагрузку как на локальный сервер, так и на серверы баз данных в зависимости от того, как
они работают и каким объемом контента они оперируют. В больших развертываниях SharePoint Server, где задания таймера
потенциально способны повлиять на задержку для конечного пользователя рекомендуется выделить сервер, чтобы
изолировать выполнение наиболее ресурсоемких заданий.

Рабочий процесс Эта возможность позволяет интегрировать рабочие процессы в SharePoint Server 2010 и исполнять их на
веб-сервере. Потребление ресурсов зависит от сложности рабочих процессов и общего количества событий, которые ими
обрабатываются. В больших развертываниях SharePoint Server, где эта возможность используется сравнительно часто,
рекомендуется в целях обеспечения неизменности трафика конечного пользователя и предотвращения задержки в
исполнении рабочего процесса добавить веб-серверы или изолировать сервер, который будет выполнять обработку только
службы таймера рабочего процесса.

Изолированные решения Эта служба обеспечивает изоляцию пользовательского кода в специализированных ресурсах
фермы. В больших развертываниях SharePoint Server, где эта возможность используется сравнительно часто, рекомендуется
37
в случае, если пользовательский код влияет на производительность сервера, выделить специализированные
дополнительные веб-серверы.
Взаимодействие новых клиентских приложений с SharePoint Server 2010
В этом разделе рассматриваются некоторые новые взаимодействия клиентов и серверов, поддерживаемые SharePoint Server
2010, и их использование при планировании загрузки.
В следующей таблице представлено схематическое описание стандартной нагрузки на систему, оказываемой этими новыми
возможностями:
X — обозначает минимальную или незначительную нагрузку на системные ресурсы
XX — обозначает средний уровень нагрузки на системные ресурсы
XXX — обозначает высокий уровень нагрузки на системные ресурсы
Клиент
Трафик
Полезная нагрузка
Office Web Apps
XXX
XX
PowerPoint Broadcast
XXX
X
Клиентское приложение Word и PowerPoint 2010
XX
X
Клиентское приложение OneNote
XXX
XXX
Outlook Social Connector
XX
XX
SharePoint Workspace
XXX
XX

Office Web Apps Веб-просмотр и редактирование файлов Word, PowerPoint, Excel и OneNote выполняется с
использованием подмножества запросов браузера с несколько отличающимися характеристиками трафика. Такой тип
взаимодействия предусматривает относительно высокий уровень загрузки трафика, необходимый для включения таких
возможностей, как совместное редактирование. В больших развертываниях SharePoint Server, где включены эти
возможности, следует ожидать дополнительной нагрузки на веб-серверы.
38

PowerPoint Broadcast Набор запросов, связанный с просмотром динамической презентации PowerPoint в веб-браузере,
представляет собой другое подмножество запросов браузера. Во время сеансов вещания PowerPoint клиенты-участники
запрашивают изменения из службы. В больших развертываниях SharePoint Server, где эта возможность используется
сравнительно часто, следует ожидать повышенной нагрузки на веб-серверы.

Клиентские приложения Word и PowerPoint 2010 В клиентах Word и PowerPoint 2010 появились новые компоненты,
позволяющие использовать преимущества фермы SharePoint Server, например совместное редактирование документов, при
котором все клиентские приложения, задействованные в сеансе совместного редактирования, часто отправляют и загружают
обновления на сервер или с сервера. В больших развертываниях SharePoint Server, где эта возможность используется
сравнительно часто, следует ожидать повышенной нагрузки на веб-серверы.

Клиентское приложение OneNote 2010 Взаимодействие OneNote 2010 с фермой SharePoint Server осуществляется
аналогично предыдущей версии OneNote; при этом SharePoint Server 2010 используется для совместного доступа и
редактирования записных книжек OneNote. В этом сценарии добавляется нагрузка на SharePoint Server 2010, даже в том
случае, когда клиент открыт, но не используется. В больших развертываниях SharePoint Server, где эта возможность
используется сравнительно часто, следует ожидать повышенной нагрузки на веб-серверы.

Клиентское приложение Outlook 2010 В Outlook 2010 используется новый компонент — Outlook Social Connector —
позволяющий использовать преимущества фермы SharePoint Server (этот компонент можно добавить также в предыдущие
версии Outlook). Этот компонент позволяет просматривать действия в социальных сетях, запрашиваемые из фермы
SharePoint Server непосредственно в сообщениях электронной почты. В больших развертываниях SharePoint Server, где эта
возможность включена, следует ожидать повышенной нагрузки на веб-серверы.

SharePoint Workspace В клиенты SharePoint Workspace 2010 добавлены новые компоненты, позволяющие использовать
преимущества фермы SharePoint Server и включить функцию синхронизации веб-сайтов, списков и библиотек документов с
клиентом для использования в автономном режиме. SharePoint Workspace 2010 регулярно выполняет синхронизацию с
присоединенными серверными объектами во время работы клиента независимо от того, используется он активно или нет. В
больших развертываниях SharePoint Server, где эта возможность используется сравнительно часто, следует ожидать
повышенной нагрузки на веб-серверы.
39
Ключевые отличительные признаки развертывания SharePoint
Server 2010
Каждое развертывание SharePoint Server 2010 содержит ключевой набор характеристик, который делает его уникальным и
отличает от других ферм. Эти ключевые отличительные признаки развертывания можно описать следующими четырьмя
категориями:
 Спецификации Описание оборудования, топологии и конфигурации фермы.

Рабочая нагрузка Описание потребностей фермы, включая количество пользователей и характеристики потребления.

Набор данных Описание размеров и распределения контента.

Исправность и производительность Описание производительности фермы в соответствии с целевыми значениями
задержки и пропускной способности.
Спецификации
Оборудование
Оборудование представляет собой физические ресурсы компьютера — процессоры, память и жесткие диски. К оборудованию
также относятся физические компоненты сети, например карты сетевого интерфейса, кабели, коммутаторы, маршрутизаторы и
системы балансировки нагрузки. Многие проблемы, связанные с производительностью и емкостью, можно разрешить путем
использования правильно подобранного оборудования. Неправильное использование аппаратных ресурсов (например,
недостаточный объем памяти на сервере) может снизить производительность всей фермы.
Топология
Топологией называется распределение и взаимодействие оборудования и компонентов фермы. Существуют два типа топологии:
 Логическая топология Карта компонентов программного обеспечения (служб и функций) в ферме.
 Физическая топология Карта серверов и физических ресурсов.
Как правило, физическая топология фермы определяется количеством пользователей и характеристиками использования, в то
время как логическую топологию определяют различные бизнес-требования, например необходимость поддержки отдельных
функций, рассчитанных на предполагаемую нагрузку.
Конфигурация
Термином "конфигурация" описываются настройки программного обеспечения и способа установки параметров. Также
конфигурацией называется кэширование, СДРес, способы установки настраиваемых ограничений, а также любая часть
программной среды, которая может быть настроена или изменена в соответствии с конкретными требованиями.
40
Рабочая нагрузка
Рабочая нагрузка определяет ключевые рабочие характеристики фермы, включая контингент пользователей, параллелизм,
используемые функции и агенты пользователей или клиентские приложения, используемые для подключения к ферме.
С различными функциями SharePoint Server связаны различные затраты ресурсов фермы. Интенсивное использование более
затратных функций может потенциально повлиять на производительность и исправность системы. Адекватная оценка
характеристик спроса и потребления позволяет правильно подобрать размер реализации и снизить риск постоянной работы в
условиях неисправности системы.
Контингент пользователей
Контингент пользователей для приложений на основе SharePoint Server объединяет понятия общего количества пользователей и
их распределения по географическому признаку. Также в пределах общего контингента пользователей существуют подгруппы
пользователей, которые могут использовать данные функции или службы более интенсивно, чем другие. Параллелизм
пользователей определяется как итоговый процент пользователей, активно использующих систему в данный момент времени. К
показателям, определяющим контингент пользователей, относится общее количество уникальных пользователей и количество
пользователей, работающих параллельно.
Характеристики потребления
На производительность фермы может повлиять не только количество пользователей, взаимодействующих с системой, но также
относящиеся к ним характеристики потребления. В двух организациях с одинаковым количеством пользователей требования
могут существенно различаться в зависимости от того, насколько часто пользователи осуществляют доступ к ресурсам фермы, а
также наличием в ферме активных ресурсоемких функций и служб. К показателям, описывающим характеристики потребления,
относятся частота уникальных операций, общий набор операций (соотношение операций чтения и записи, а также
административных операций), шаблоны использования и нагрузки с учетом новых функций, которые активны в ферме (например,
личные веб-сайты, поиск, рабочие процессы и Office Web Apps).
Набор данных
Объем контента, хранящегося в системе, и характеристики архитектуры, в пределах которой хранится контент, может в
значительной степени повлиять на общую исправность и производительность системы. Адекватная оценка размера, частоты
доступа и распределения данных позволит правильно выбрать размер хранилища в системе и предотвратить образование узких
мест, замедляющих взаимодействие пользователей со службами фермы и мешающих работе конечных пользователей.
Чтобы правильно оценить и спроектировать архитектуру хранилища в решении на основе SharePoint Server, необходимо знать
объем данных, которые будут храниться в системе, а также количество пользователей, запрашивающих данные из различных
источников данных. Объем контента также является важным моментом при определении емкости диска, поскольку он может
повлиять на производительность других функций, а также на задержку сети и доступную пропускную способность канала. К
41
показателям, определяющим набор данных, относится общий размер контента, общее число документов, общее количество
семейств веб-сайтов, а также средние и максимальные значения размера семейства веб-сайтов.
Исправность и производительность
Исправность фермы SharePoint Server является, по сути, упрощенной оценкой, отражающей надежность, стабильность и
производительность системы. То, насколько качественно ферма выполняет поставленные задачи, зависит в основном от первых
трех отличительных признаков. Оценка исправности и производительности отслеживается и описывается путем вычленения
набора показателей. Дополнительные сведения см. в разделе Мониторинг и обслуживание SharePoint Server 2010. Эти
показатели включают время работы системы, задержку, распознаваемую конечным пользователем, частоту отказа страницы и
показатели использования ресурсов (ЦП, ОЗУ).
Любые существенные изменения в оборудовании, топологии, конфигурации, рабочей нагрузке или наборе данных могут
значительно повлиять на надежность и уровень реагирования системы. Оценка исправности может быть использована для
отслеживания производительности в динамике по времени, а также для оценки влияния изменения условий эксплуатации или
конфигурации системы на надежность фермы.
Эталонные архитектуры
SharePoint Server 2010 — это сложный мощный продукт, и универсальных решений, подходящих для любой архитектуры, не
существует. Каждое развертывание SharePoint Server уникально и определяется присущими ему характеристиками
использования и данных. Все организации должны внимательно подойти к внедрению процесса управления емкостью и
эффективно использовать преимущества гибкого подхода, предоставляемого системой SharePoint Server 2010 для настройки
решения правильно выбранного размера, которое оптимально соответствует потребностям организации.
Концепция эталонной архитектуры служит для описания и демонстрации различных основных категорий развертываний
SharePoint Server и не является панацеей для разработчиков при разработке решений. Этот радел посвящен рассмотрению
векторов стандартного масштабирования развертывания SharePoint Server.
Архитектуры, перечисленные здесь, позволяют выявить признаки, отличающие эти универсальные категории, а также отличить
их по общим факторам затрат и объему усилий.
Развертывание обособленного сервера
Архитектура развертывания обособленного сервера состоит из единственного сервера, на котором установлен и работает
SharePoint Server 2010, и поддерживаемой версии SQL Server. Такая архитектура может использоваться разработчиками в целях
оценки или для изолированных реализаций с низкой значимостью в отделах с небольшим количеством пользователей.
42
Развертывание небольшой фермы
Развертывание небольшой фермы состоит из обособленного сервера или кластера базы данных и одного-двух компьютеров на
базе SharePoint Server 2010. Основные характеристики архитектуры включают ограниченную избыточность и отработку отказа, а
также минимальный набор включенных возможностей SharePoint Server.
Небольшие фермы рекомендуется использовать для обслуживания только ограниченных развертываний с минимальным
набором включенных приложений-служб, относительно небольшим контингентом пользователей, относительно низким уровнем
загрузки (несколько запросов в минуту или очень небольшое количество запросов в секунду) и относительно небольшим
объемом данных (от 10 гигабайт).
43
Развертывание фермы среднего размера
Такая архитектура использует декомпозицию топологии по трем уровням: специализированные веб-серверы,
специализированные серверы приложений и один или несколько серверов или кластеров баз данных. Отделение уровня
интерфейсного сервера от уровня сервера приложения позволяет использовать более гибкий подход к изоляции служб и
обеспечивает возможность балансировки нагрузки в масштабах всей системы.
Это наиболее распространенная архитектура, которая предусматривает широкий спектр топологий служб и размеров ферм.
Развертывание фермы среднего размера рекомендуется использовать для обслуживания сред, обладающих следующими
характеристиками:
 Несколько приложений-служб, распределенных по нескольким серверам. Стандартный набор функций может включать
службу Office Web Apps, службу профилей пользователей, службу управляемых метаданных и службу вычислений Excel.

Контингент пользователей, состоящий из десятков тысяч пользователей, и нагрузка на уровне 10–50 запросов в секунду.

Хранилище данных размером один-два терабайта.
44
45
Развертывание фермы большого размера
При развертывании больших ферм используется декомпозиция служб и решений в нескольких фермах, а также дополнительные
возможности горизонтального масштабирования уровней в обособленной ферме. Несколько служб SharePoint Server могут быть
развернуты на ферме специализированных служб, обслуживающей запросы от нескольких ферм, потребляющих ресурсы. В эти
большие архитектуры, как правило, входят веб-серверы, несколько серверов приложений в зависимости от характеристик
потребления локальных (не общих) служб и несколько серверов на базе SQL Server или кластеров SQL Server в зависимости от
размера контента и баз данных приложений-служб, активированных в ферме. Большие архитектуры фермы предназначены для
обслуживания развертываний, обладающих следующими характеристиками:
 Несколько приложений-служб, включенных в федерацию, ресурсы которых потребляются фермой специализированных
служб (как правило, к этим службам относятся служба профилей пользователей, служба поиска, служба управляемых
метаданных и веб-аналитика).

Большинство других приложений-служб активируется локально.

Контингент пользователей в диапазоне нескольких сотен тысяч пользователей.

Нагрузка потребления в диапазоне нескольких сотен запросов в секунду.

Набор данных в диапазоне десяти и более терабайт.
46
47
См. также
Понятия
Планирование емкости для SharePoint Server 2010
Тестирование производительности для SharePoint Server 2010
Мониторинг и обслуживание SharePoint Server 2010
Управление мощностью SharePoint Server 2010: ограничения, связанные с программным обеспечением
Результаты тестирования производительности и емкости и рекомендации (SharePoint Server 2010)
Performance and capacity technical case studies (SharePoint Server 2010) (на английском языке)
Другие ресурсы
Hardware and software requirements (SharePoint Server 2010)
48
Планирование емкости для SharePoint Server 2010
В этой статье описывается порядок планирования емкости фермы Microsoft SharePoint Server 2010. Если вы правильно
оцениваете и хорошо понимаете важность планирования емкости и управления ею, эти знания помогут вам определиться с
размерами системы. Определение размеров заключается в выборе и настройке подходящей архитектуры данных, логической и
физической топологии, а также оборудования для платформы решения. Существует целый ряд вопросов управления емкостью,
которые следует учесть для определения наиболее подходящих вариантов оборудования и конфигурации.
Прежде чем приступать к чтению этой статьи, вы должны прочитать статью Обзор управления емкостью и изменения размера
для SharePoint Server 2010.
В этой статье описываются шаги, которые необходимо предпринять для эффективного управления емкостью в среде
организации. На каждом шаге потребуются определенные сведения для его успешного выполнения и будут получены
определенные результаты, которые будут использоваться на последующем шаге. Эти требования и результаты для каждого
шага указаны в таблицах.
Содержание:
 Шаг 1. Модель

Шаг 2. Макет

Шаг 3. Пилотный проект, тестирование и оптимизация

Шаг 4. Развертывание

Шаг 5. Наблюдение и поддержка
Шаг 1. Модель
Моделирование среды на основе SharePoint Server 2010 начинается с анализа имеющихся решений и оценки ожидаемого спроса
и целей для планируемого развертывания. Для начала нужно собрать сведения о базе пользователей, требованиях к данным,
времени ожидания и целевой производительности, а также определить компоненты SharePoint Server для развертывания. Из
этого раздела вы узнаете, какие данные следует собирать, как их собирать и как их можно использовать на последующих шагах.
49
Определение предполагаемой рабочей нагрузки и набора данных
Для надлежащей оценки размеров развертывания SharePoint Server 2010 необходимо изучить и осмыслить характеристики
спроса, которые предположительно будет обрабатывать данное решение. Для определения спроса необходимо описать как
характеристики рабочей нагрузки, например количество пользователей и часто используемые операции, так и характеристики
набора данных, например размер и распределение контента.
В этом разделе рассматриваются некоторые специфические метрики и параметры, данные по которым следует собирать, а
также механизмы сбора этих данных.
Рабочая нагрузка
Рабочая нагрузка описывает спрос, который придется удовлетворять системе, базу пользователей и характеристики
использования. В приведенной ниже таблице показаны основные метрики, которые помогут определить рабочую нагрузку. В эту
таблицу можно записывать соответствующие метрики по мере сбора данных.
Характеристики рабочей нагрузки
Значение
Среднее число запросов в секунду при обычной
нагрузке
Среднее число запросов в секунду при пиковой
нагрузке
Общее число уникальных пользователей в день
Среднее число параллельных пользователей при
обычной нагрузке
Максимальное число параллельных пользователей при
пиковой нагрузке
Общее число запросов в день
Ожидаемое распределение рабочей нагрузки
Число запросов в день
Веб-браузер — обход службы поиска
50
%
Характеристики рабочей нагрузки
Значение
Веб-браузер — общее взаимодействие при совместной
работе
Веб-браузер — социальное взаимодействие
Веб-браузер — общее взаимодействие
Веб-браузер — Office Web Apps
Клиенты Office
Клиент OneNote
SharePoint Workspace
Синхронизация Outlook RSS
Outlook Social Connector
Другие взаимодействия (пользовательские приложения
или веб-службы)

Параллельные пользователи: этот показатель чаще всего используется для измерения способности одновременного
выполнения операций в ферме серверов и представляет число отдельных пользователей, создающих запросы в
определенный интервал времени. Основные метрики: среднее число в день и число параллельных пользователей во время
пиковой нагрузки.

Запросов в секунду (RPS): этот показатель числа запросов в секунду чаще всего используется для описания спроса на
ферму серверов, выраженного в количестве запросов, обработанных фермой за секунду, без разделения запросов по типам
и размерам. Каждая база пользователей организации создает системную нагрузку со скоростью, зависящей от уникальных
характеристик использования в организации. Дополнительные сведения об этом понятии см. в разделе Глоссарий в статье
Обзор управления емкостью и изменения размера для SharePoint Server 2010.
51

Общее число запросов в день: хороший показатель общей нагрузки, которую должна обрабатывать система. Обычно
учитываются все запросы за 24 часа, кроме запросов подтверждения проверки подлинности (состояние HTTP 401).

Общее число пользователей в день: еще один ключевой показатель общей нагрузки, которую должна обрабатывать
система. Эта величина представляет фактическое число уникальных пользователей за 24 часа, а не общее число
сотрудников в организации.
Примечание.
Общее число пользователей в день может указывать на потенциал роста нагрузки в ферме. Например, если число потенциальных
пользователей равно 100 тысячам сотрудников, 15 тысяч пользователей в день показывают, что со временем нагрузка может значительно
возрасти по мере увеличения вовлеченности пользователей.

Распределение рабочей нагрузки: информация о распределении запросов в зависимости от клиентских приложений,
взаимодействующих с фермой, помогает прогнозировать тенденции и ожидаемые изменения нагрузки после перехода на
SharePoint Server 2010. При переходе пользователей на более новые версии клиентов, например Office 2010, и
использовании новых возможностей ожидается увеличение числа новых шаблонов нагрузки, запросов в секунду и общего
числа запросов. Для каждого клиента можно описать число отдельных пользователей, использующих его в течение дня, и
общее число запросов, создаваемых клиентом или компонентом на сервере.
Например, на приведенной ниже схеме показан снимок реальной внутренней среды Майкрософт, обслуживающей
стандартное социальное решение. На этом примере видно, что большая часть нагрузки создается при обходе данных во
время поиска и обычном просмотре веб-страниц пользователями. Видно также, что существенная нагрузка порождается
новым компонентом Outlook Social Connector (6,2 процента запросов).
52
53
54
Оценка производственной рабочей нагрузки
Оценивая требуемую скорость передачи данных в ферме, начните с совокупности транзакций, которые будут в этой ферме
использоваться. Проанализируйте наиболее часто используемые транзакции, которые будут обслуживаться системой,
определите, как часто они будут использоваться и каким количеством пользователей. Это поможет затем в ходе лабораторных
испытаний проверить, может ли ферма поддерживать такую нагрузку.
На следующей диаграмме показана взаимосвязь рабочей нагрузки и нагрузки на систему.
55
56
Для оценки ожидаемой рабочей нагрузки соберите следующие сведения.
 Определите операции взаимодействия пользователя, такие как просмотр веб-страниц, загрузка и отправка файлов, просмотр
и изменение данных через Office Web Applications в браузере, совместное редактирование, синхронизация сайтов в
SharePoint Workspace, взаимодействие в Outlook Social Connector, синхронизация RSS (в Outlook или других средствах
просмотра), вещание в PowerPoint, общие записные книжки в OneNote, общие книги в службе Excel, общие приложения в
службе Access и другие. Дополнительные сведения см. в разделе Службы и компоненты в статье Обзор управления
емкостью и изменения размера для SharePoint Server 2010. В первую очередь определите взаимодействия, которые могут
оказаться специфичными для вашего развертывания, и оцените влияние такой нагрузки; в качестве примера можно привести
интенсивное использование форм InfoPath, вычислений службы Excel и аналогичных специализированных решений.

Определите системные операции, такие как добавочные обходы службы поиска, ежедневное резервное копирование,
задания таймера синхронизации профилей, обработка данных Web Analytics и другие.

Оцените общее число пользователей в день, которые предположительно будут использовать каждую функциональную
возможность, и получите ориентировочное число параллельных пользователей и запросов верхнего уровня в секунду; можно
также сделать некоторые допущения, например относительно текущей параллельности и показателя числа запросов в
секунду для параллельных пользователей, который отличается для разных функциональных возможностей; для оценки
используйте таблицу рабочей нагрузки, приведенную ранее в этом разделе. Важно определить не столько среднюю
производительность, сколько пиковую нагрузку. Планирование пиковой активности позволит надлежащим образом
определить размеры решения на основе SharePoint Server 2010.
Если уже имеется решение Office SharePoint Server 2007, изучите файлы журнала IIS или обратитесь к имеющимся средствам
веб-мониторинга, чтобы лучше понять предполагаемое поведение существующего решения, либо прочитайте подробные
инструкции в приведенном ниже разделе. Если такое решение отсутствует, заполните таблицу, используя приблизительные
оценки. На последующих шагах придется проверить сделанные допущения и выполнить более точную настройку системы.
Анализ журналов IIS в SharePoint Server 2010
Чтобы найти основные метрики для существующего развертывания SharePoint Server 2010, такие как число активных
пользователей, интенсивность использования системы этими пользователями, тип поступающих запросов и тип отправляющих
запросы клиентов, необходимо извлечь данные из журналов ULS и IIS. Проще всего для получения этих данных использовать
средство синтаксического анализа журналов — полнофункциональную утилиту, которую можно бесплатно загрузить с сайта
Майкрософт. Средство синтаксического анализа журналов поддерживает чтение и запись в ряде текстовых и двоичных
форматов, включая все форматы IIS.
Подробные сведения о том, как анализировать использование SharePoint Server 2010 с помощью средства синтаксического
анализа журналов, см. в статье, посвященной анализу использования продуктов и технологий Microsoft SharePoint (Возможно, на
57
английском языке) (http://www.microsoft.com/downloads/details.aspx?familyid=f159af68-c3a3-413c-a3f72e0be6d5532e&displaylang=en) (Возможно, на английском языке).
Средство синтаксического анализа журналов Log Parser 2.2 можно загрузить по адресу
http://www.microsoft.com/downloads/details.aspx?FamilyID=890CD06B-ABF8-4C25-91B2-F8D975CF8C07&displaylang=en (Возможно,
на английском языке).
Набор данных
Набор данных описывает объем контента, хранящегося в системе, и его распределение по хранилищу данных. В приведенной
ниже таблице показаны основные метрики, которые помогут определить набор данных. В эту таблицу можно записывать
соответствующие метрики по мере сбора данных.
Объект
Значение
Размер базы данных (в ГБ)
Число баз данных контента
Число семейств веб-сайтов
Число веб-приложений
Число сайтов
Размер индекса поиска (число элементов)
Число документов
Число списков
Средний размер сайтов
Максимальный размер сайта
Число профилей пользователей
58

Размер контента: определение размеров контента, который предположительно будет храниться в системе SharePoint Server
2010, имеет большое значение для планирования и проектирования хранилища системы, а также для надлежащей оценки
размеров поискового решения, которое будет выполнять обход и индексирование этого контента. Размер контента
описывается в терминах общего объема дискового пространства. Если осуществляется перенос контента из существующего
развертывания, возможно, проще определить общий размер переносимых данных; кроме того, при планировании следует
оставить место для будущего роста на основании прогнозируемой тенденции.

Общее число документов: отличается от размера совокупности данных и имеет большое значение для отслеживания общего
числа элементов. Реакции системы в ситуации, когда 100 ГБ данных состоят из 50 файлов по 2 ГБ каждый, будут отличаться
от ситуации, когда имеется 100 000 файлов по 1 КБ каждый. В крупных развертываниях, чем меньше нагрузки приходится на
отдельный элемент, документ или область документов, тем выше производительность. Распределенный контент, когда
несколько файлов меньшего размера распределено по множеству сайтов и семейству сайтов, проще обслуживать, чем одну
большую библиотеку документов с очень большими файлами.

Максимальный размер семейства веб-сайтов: важно определить наибольшую единицу контента, которая будет храниться
в SharePoint Server 2010; как правило, невозможность разделения этой единицы контента определяется организационной
необходимостью. Средний размер всех семейств веб-сайтов и предполагаемый общий размер семейств веб-сайтов — это
дополнительные показатели, помогающие определить предпочтительную структуру данных.

Характеристики данных приложений-служб: помимо анализа требований к хранилищу для контента следует
проанализировать и оценить размеры других хранилищ SharePoint Server 2010, в том числе:

Общий размер индекса поиска

Общий размер базы данных профилей на основе числа пользователей в хранилище профилей

Общий размер базы данных социального контента на основе предполагаемого числа тегов, коллег и операций

Размер хранилища метаданных

Размер базы данных использования
 Размер базы данных Web Analytics
Дополнительные сведения о порядке оценки размеров баз данных см. в статье Планирование и настройка рабочих
характеристик хранилища и SQL Server (SharePoint Server 2010).
Задание целевых показателей производительности и надежности фермы
Одним из результатов, полученных в разделе Шаг 1. Модель, является хорошее понимание целевых показателей
производительности и надежности, наилучшим образом соответствующих нуждам организации. Период работоспособности
59
правильно спроектированного решения SharePoint Server должен выражаться "четырьмя девятками" (99,99 %) при скорости
отклика сервера меньше секунды.
Для описания производительности и надежности фермы используются следующие показатели:
 Доступность сервера: обычно выражается в процентах от общего времени работоспособности системы. Необходимо
отслеживать любое неожиданное время простоя и сравнивать общую доступность с целевым показателем, заданным для
организации. Целевые показатели обычно выражаются девятками (например, 99 %, 99,9 %, 99,99 %)

Скорость отклика сервера: время, которое требуется ферме для обслуживания запросов, является хорошим показателем
для наблюдения за исправностью фермы. Этот показатель обычно называется задержкой на сервере и используется для
применения среднего или срединного (50-я процентиль) времени ожидания при обслуживании ежедневных запросов.
Целевые показатели обычно выражаются в долях секунды или секундах. Имейте в виду, что если в вашей организации
имеется целевой показатель для обслуживания страниц из SharePoint Server 2010 менее чем за две секунды, то время
отклика сервера должно включать доли секунды на то, чтобы страница дошла до клиента по сети, и время на
воспроизведение в браузере. К тому же, большое время отклика сервера служит показателем неисправности фермы,
поскольку обычно это влияет на производительность и практически невозможно поддерживать заданное число запросов в
секунду, если сервер тратит больше секунды на большинство запросов.

Пиковость сервера: еще одним хорошим показателем для отслеживания задержки на сервере является режим обработки
пяти процентов запросов, которые являются самыми медленными. Медленными обычно являются запросы, которые
попадают в систему в период ее высокой нагрузки, или, если говорить даже более обобщенно, запросы, на которые влияют
более редкие факторы, связанные с работой пользователей в системе; работоспособной считается система, в которой самые
медленные запросы также находятся под контролем. Целевой показатель здесь такой же, как и для скорости отклика
сервера, но для достижения отклика не более секунды в период пиковой нагрузки сервера необходимо построить систему,
содержащую множество резервных ресурсов для обработки пиковой нагрузки.

Использование системных ресурсов: общими показателями для наблюдения за исправностью системы являются также
системные счетчики, показывающие исправность каждого сервера в топологии фермы. Чаще всего для этой цели
используются такие показатели, как процент использования ЦП и доступная память; однако имеется несколько
дополнительных счетчиков, которые помогут определить неисправность системы; подробные сведения см. в разделе Шаг 5.
Поддержка.
60
Шаг 2. Макет
Теперь, когда завершен сбор некоторых фактических и предполагаемых данных по решению, которое необходимо получить,
можно перейти к следующему шагу и начать проектирование запланированной архитектуры, которая предположительно сможет
удовлетворить ожидаемый спрос.
В конце этого шага должны быть получены проект для физической топологии и макет для логической топологии, что позволит
определиться со всеми необходимыми заказами на приобретение.
Спецификации оборудования тесно связаны с количеством компьютеров в макете, и существует несколько решений для
обработки различных типов нагрузки. Обычно используется либо небольшое количество мощных компьютеров (вертикальная
масштабируемость), либо большее количество менее мощных компьютеров (горизонтальная масштабируемость); каждое
решение имеет свои преимущества и недостатки с точки зрения емкости, избыточности, энергопотребления, затрат,
пространства и других факторов.
Рекомендуется в начале этого шага определиться с архитектурой и топологией. Определите, как планируется расположить
различные фермы и различные службы в каждой ферме, а затем выберите спецификации оборудования для каждого отдельного
сервера в проекте. Этот процесс можно также осуществить несколько иначе: определите спецификации оборудования, которое
предполагаете развернуть (многие организации ограничены определенными корпоративными стандартами), а затем
спроектируйте архитектуру и топологию.
Используйте приведенную ниже таблицу для записи параметров проекта. Данные указаны в качестве примера, их не следует
использовать для определения размеров вашей фермы. Эти данные просто показывают, как использовать таблицу для ваших
собственных данных.
Роль
Тип (стандартный или
виртуальный)
Число
компьютеров
Процессоры
ОЗУ Число
Размер диска, Диск данных
операций
ОС+журнал
ввода-вывода
в секунду
Веб-серверы
Виртуальный
4
4 ядра
8
1 кластер
4 Quad-Core 48
2,33 (ГГц)
Сервер базы данных контента Стандартный
Не определен 400 ГБ
2000
400 ГБ
Не определен
20 дисков по
300 ГБ,
15 тыс.
об/мин
61
Роль
Тип (стандартный или
виртуальный)
Число
компьютеров
Процессоры
ОЗУ Число
Размер диска, Диск данных
операций
ОС+журнал
ввода-вывода
в секунду
Серверы приложений
Виртуальный
4
4 ядра
16
Не определен 400 ГБ
Не определен
Целевой веб-сервер для
обхода службы поиска
Виртуальный
1
4 ядра
8
Не определен 400 ГБ
Не определен
Сервер запросов поиска
Стандартный
2
2 Quad-Core 32
2,33 (ГГц)
Не определен 400 ГБ
500 ГБ
Сервер программы-обходчика Стандартный
службы поиска
2
2 Quad-Core 16
2,33 (ГГц)
400
Сервер базы данных для
обхода службы поиска
Стандартный
1 кластер
4 Quad-Core 48
2,33 (ГГц)
4000
100 ГБ
(настроен для
чтения)
16 дисков по
150 ГБ, 15
тыс. об/мин
База данных хранилища
свойств службы поиска +
сервер базы данных
администрирования
Стандартный
1 кластер
4 Quad-Core 48
2,33 (ГГц)
2000
100 ГБ
(настроен для
записи)
16 дисков по
150 ГБ, 15
тыс. об/мин
400 ГБ
Не определен
Определение архитектуры в качестве отправной точки
В этом разделе рассказывается, как выбрать архитектуру.
При развертывании SharePoint Server 2010 можно выбрать топологию для реализации решения; можно развернуть один сервер
или использовать множество серверов в ферме SharePoint Server с кластеризованными или отраженными серверами баз данных
и серверами приложений c невысокой производительностью для различных служб. Затем выбираются спецификации
оборудования в зависимости от требований каждой из ролей, а также от необходимой емкости, доступности и избыточности.
Для начала рассмотрите различные эталонные архитектуры и представьте себе структуру фермы; решите, следует ли разделять
решение по нескольким фермам или организовать федерацию некоторых служб, например служб поиска, в выделенной ферме.
62
Дополнительные сведения см. в разделе Эталонные архитектуры в статье Обзор управления емкостью и изменения размера
для SharePoint Server 2010.
Примеры технического внедрения SharePoint Server 2010
В руководство по управлению емкостью для SharePoint Server 2010 включены некоторые примеры технического внедрения
имеющихся производственных сред, в которых подробно описываются существующие производственные среды на основе
SharePoint Server. Со временем будут опубликованы дополнительные примеры технического внедрения; эти примеры можно
использовать в качестве образца для проектирования среды на основе SharePoint Server, предназначенной для конкретных
целей.
Можно использовать эти примеры внедрения как эталонные при проектировании архитектуры собственных решений SharePoint
Server, особенно если описание главных отличительных признаков этого развертывания совпадает с нуждами и целевыми
показателями создаваемого решения.
В этих документах приведены следующие сведения для каждого задокументированного примера внедрения:
 Спецификации, такие как оборудование, топология фермы и конфигурация

Рабочая нагрузка, включая базу пользователей и характеристики использования

Набор данных, включая размеры контента, характеристики контента и распределение контента

Исправность и производительность, включая набор записанных показателей, описывающих характеристики надежности и
производительности фермы
Для получения дополнительных сведений загрузите соответствующие документы со страницы примеров технического
внедрения: производительность и емкость (Возможно, на английском языке) (http://technet.microsoft.com/ruru/library/cc261716.aspx (Возможно, на английском языке)).
Выбор оборудования
Выбор правильных спецификаций для компьютеров в ферме — это важнейший шаг для обеспечения надлежащей надежности и
производительности развертывания; при этом в ходе планирования необходимо учесть величину пиковой нагрузки и период
пиковой нагрузки; другими словами, когда ферма работает в условиях средней нагрузки, в ней должно быть достаточно
доступных ресурсов для обработки максимального ожидаемого спроса при соблюдении целевых показателей задержки и
производительности.
Основные компоненты емкости и производительности оборудования серверов можно отнести к следующим четырем категориям:
процессорная мощность, производительность диска, пропускная способность (емкость) сети и возможности памяти системы.
63
Необходимо принять во внимание еще один момент — использование виртуальных машин. При развертывании фермы
SharePoint Server можно использовать виртуальные машины. Это не приносит дополнительных выгод в плане
производительности, зато дает ряд преимуществ в плане управления. Виртуализация компьютеров с SQL Server обычно не
рекомендуется, но виртуализация на уровне веб-сервера и сервера приложений может принести определенные преимущества.
Дополнительные сведения см. в статье, посвященной планированию виртуализации (http://technet.microsoft.com/ruru/library/ff607968.aspx).
Рекомендации по выбору оборудования
Выбор процессоров
SharePoint Server 2010 предлагается только для 64-разрядных компьютеров. Как правило, большее число процессоров позволяет
обслуживать более высокий спрос.
В SharePoint Server 2010 можно увеличить возможности отдельных веб-серверов, добавляя дополнительные ядра
(протестировано максимум 24 ядра); чем больше ядер имеет сервер, тем большую нагрузку он может поддерживать при прочих
равных условиях. В крупных развертываниях SharePoint Server рекомендуется размещать либо несколько 4-ядерных вебсерверов (которые можно виртуализировать), либо меньшее количество более мощных веб-серверов (8,16 или 24 ядра).
Требования к емкости процессора сервера приложений отличаются в зависимости от роли сервера и работающих на нем служб.
Некоторым компонентам SharePoint Server требуется большая процессорная мощность, чем другим. Например, служба поиска
SharePoint очень зависит от процессорной мощности сервера приложений. Дополнительные сведения о требованиях к ресурсам
со стороны компонентов и служб SharePoint Server см. в статье, посвященной службам и компонентам, ранее в этом документе.
Требования к емкости процессора для SQL Server также зависят от баз данных служб, размещаемых на компьютере с SQL
Server. Дополнительные сведения о стандартном режиме работы и требованиях каждой базы данных см. в статье Планирование
и настройка рабочих характеристик хранилища и SQL Server (SharePoint Server 2010).
Выбор памяти
Серверам требуется различный объем памяти в зависимости от функции и роли сервера. Например, серверы, на которых
выполняются компоненты обхода службы поиска, работают быстрее при наличии большого объема памяти, поскольку документы
считываются в память для обработки. Веб-серверам, использующим возможности кэширования, входящие в SharePoint Server
2010, тоже может потребоваться больше памяти.
Как правило, требования к памяти веб-сервера напрямую зависят от числа разрешенных в ферме пулов приложений и числа
обслуживаемых параллельных запросов. В большинстве производственных развертываний SharePoint Server рекомендуется
выделять не менее 8 ГБ ОЗУ на каждый веб-сервер и 16 ГБ для серверов с более высоким трафиком или развертываний, где
настроено несколько пулов приложений в целях изоляции.
64
Требования к памяти серверов приложений также различаются; некоторые компоненты SharePoint Server предъявляют более
высокие требования на уровне приложений, чем другие. В большинстве производственных развертываний SharePoint Server
рекомендуется выделять не менее 8 ГБ ОЗУ на каждый сервер приложений; серверы приложений с памятью 16 ГБ, 32 ГБ и 64 ГБ
обычно используются, если на одном сервере используется несколько приложений-служб или если разрешены службы, которые
напрямую зависят от памяти, например служба вычислений Excel и служба поиска SharePoint Server.
Требования к памяти со стороны серверов баз данных напрямую зависят от размеров баз данных. Дополнительные сведения о
выборе памяти для компьютеров с SQL Server см. в статье Планирование и настройка рабочих характеристик хранилища и SQL
Server (SharePoint Server 2010).
Выбор сетей
Помимо предоставления высокой скорости пользователям для быстрого доступа клиентов к данным по сети необходимо
обеспечить в распределенной ферме высокую скорость доступа для межсерверной связи. В частности, это касается
распределения служб по нескольким серверам или объединения некоторых служб в федерацию в другие фермы. В ферме
создается значительный трафик на уровне веб-сервера, уровне сервера приложений и уровне сервера баз данных, и сеть может
легко стать узким местом при определенных обстоятельствах, например при работе с очень большими файлами или при очень
высоких нагрузках.
Конфигурации веб-серверов и серверов приложений должны включать не менее двух сетевых карт (NIC): одна карта для
обработки пользовательского трафика, другая — для обработки межсерверной связи. Задержка в сети между серверами может
оказать существенное влияние на производительность, поэтому важно поддерживать сетевую задержку менее 1 миллисекунды
между веб-сервером и компьютерами SQL Server, содержащими базы данных контента. Кроме того, компьютеры SQL Server, на
которых располагаются базы данных приложений-служб, должны находиться как можно ближе к работающему с ними серверу
приложений. Сеть между серверами фермы должна иметь пропускную способность не менее 1 Гбит/с.
Выбор дисков и хранилища
Управление дисками — это не просто функция предоставления подходящего пространства для данных. Необходимо оценить
текущий спрос и его потенциальный рост и выбрать такую архитектуру хранилища, которая не будет замедлять работу системы.
На каждом диске всегда должно быть не менее 30 процентов дополнительной емкости сверх максимальной оценки требований к
данным, чтобы оставалось пространство для дальнейшего роста. Кроме того, в большинстве производственных сред скорость
диска (число операций ввода-вывода в секунду) имеет решающее значение для обеспечения достаточной производительности,
удовлетворяющей спрос на серверное хранилище данных. Необходимо оценить объем трафика (число операций ввода-вывода в
секунду), который потребуется для наиболее важных баз данных в развертывании, и выделить достаточно дисков для
поддержания этого трафика.
65
Дополнительные сведения о порядке выбора дисков для серверов баз данных см. в статье Планирование и настройка рабочих
характеристик хранилища и SQL Server (SharePoint Server 2010).
Веб-серверы и серверы приложений также имеют требования к хранилищу данных. В большинстве производственных сред
рекомендуется выделять не менее 200 ГБ дискового пространства для ОС и временных файлов и 150 ГБ дискового пространства
для журналов.
Шаг 3. Пилотный проект, тестирование и оптимизация
Этап тестирования и оптимизации является важнейшим компонентом эффективного управления емкостью. Необходимо
протестировать новые архитектуры, прежде чем развертывать их в производственной среде, и провести приемочные испытания
в соответствии с рекомендациями по наблюдению, чтобы проверить, достигают ли спроектированные архитектуры целевых
показателей производительности и емкости. Это позволяет выявить и оптимизировать потенциальные узкие места, прежде чем с
ними столкнутся пользователи в реальном развертывании. Если выполняется обновление среды Office SharePoint Server 2007 и
планируется внесение архитектурных изменений или выполняется оценка пользовательской нагрузки новых компонентов
SharePoint Server, тестирование позволяет проверить, будет ли новая среда на основе SharePoint Server соответствовать
целевым показателям производительности и емкости.
По окончании тестирования среды можно проанализировать результаты тестов и определить, какие изменения необходимо
внести для достижения целевых показателей производительности и емкости, установленных в разделе Шаг 1. Модель.
Ниже перечисляются вспомогательные шаги, которые рекомендуется выполнить на этапе подготовки:
 Создайте тестовую среду, похожую на исходную архитектуру, разработка которой описывалась в разделе Шаг 2. Макет.

Заполните хранилище набором данных, указанным в разделе Шаг 1. Модель.

Приложите к системе искусственной нагрузку, представляющую рабочую нагрузку, определенную в разделе Шаг 1. Модель.

Запустите тесты, проанализируйте результаты и оптимизируйте используемую архитектуру.

Выполните развертывание этой оптимизированной архитектуры в центре обработки данных и реализуйте пилотный проект с
небольшим набором пользователей.

Проанализируйте результаты пилотного проекта, выявите потенциально узкие места и оптимизируйте используемую
архитектуру. При необходимости повторите тестирование.

Выполните развертывание в рабочей среде.
Тестирование
66
Тестирование помогает определить, способен ли макет системы поддерживать рабочую нагрузку и характеристики
использования. См. в разделе Тестирование производительности для SharePoint Server 2010 подробные сведения о
тестировании развертывания SharePoint Server 2010.
 Создание плана тестирования

Создание тестовой среды

Разработка соответствующих тестов и средств тестирования
Развертывание пилотной среды
Прежде чем развертывать SharePoint Server 2010 в производственной среде, необходимо развернуть пилотную среду и
протестировать ферму, чтобы проверить, может ли она соответствовать целевым показателям производительности и емкости
для ожидаемой пиковой нагрузки. Рекомендуется при тестировании в пилотной среде использовать сначала искусственную
нагрузку, в особенности для крупных развертываний, а затем нагрузку в виде небольшого числа реальных пользователей и
реального контента. Анализ пилотной среды с небольшим числом реальных пользователей позволяет до полного перехода в
производственную среду проверить ряд допущений в отношении характеристик использования и роста контента.
Оптимизация
Если не удается добиться соответствия целевым показателям производительности и емкости путем масштабирования
оборудования фермы или внесения изменений в топологию, придется пересмотреть решение. Например, если первоначальные
требования относились к одной ферме для совместной работы, поиска и социального взаимодействия, возможно, следует
создать федерацию некоторых служб, например поиска, в выделенной ферме служб или разделить рабочую нагрузку между
большим количеством ферм. В качестве альтернативы можно развернуть одну выделенную ферму для социального
взаимодействия и еще одну — для совместной работы групп.
Шаг 4. Развертывание
После выполнения заключительных тестов и проверки того, что выбранная архитектура способна поддерживать целевые
показатели производительности и емкости, установленные в разделе Шаг 1. Модель, можно приступать к развертыванию
решения SharePoint Server 2010 в производственной среде.
Подходящая стратегия внедрения зависит от среды и ситуации. Хотя тема развертывания SharePoint Server в общем выходит за
рамки содержания данного документа, здесь рассматриваются некоторые рекомендуемые действия, связанные с задачей
планирования емкости. Ниже приводятся примеры.
67

Развертывание новой фермы SharePoint Server. Для задачи планирования емкости необходимы стандартизированные
утвержденные планы по проектированию и развертыванию SharePoint Server 2010. В данном случае внедрение будет первым
широкомасштабным развертыванием SharePoint Server 2010. Это потребует перемещения или повторного создания в
производственной среде серверов и служб, которые использовались во время выполнения задачи планирования емкости.
Это наиболее очевидный сценарий, поскольку здесь не требуется никаких обновлений или изменений в существующей
ферме.

Обновление фермы Office SharePoint Server 2007 на SharePoint Server 2010. При выполнении задачи планирования
емкости должен быть проверен и утвержден проект для фермы, который может соответствовать существующему спросу и
масштабироваться для соответствия растущему спросу и использованию фермы SharePoint Server 2010. Часть задачи
планирования емкости должна включать тестовые переносы данных, которые позволяют проверить длительность процесса
обновления, необходимость изменения или замены пользовательского кода, необходимость обновления программных
средств сторонних поставщиков и т. д. В заключение планирования емкости необходимо получить проверенный и
утвержденный проект, представление о времени, которое займет обновление, и план наилучшего метода обновления —
например, обновление на месте или перенос баз данных контента в новую ферму. Если выполняется обновление на месте,
то во время планирования емкости можно обнаружить, что потребуется дополнительное оборудование или обновление
существующего оборудования; кроме того, можно рассмотреть некоторые аспекты, касающиеся времени простоя. В
результате выполнения задачи планирования емкости необходимо получить список необходимых изменений оборудования и
план развертывания изменений оборудования в ферме, которое необходимо выполнить прежде всего. После того как
аппаратная платформа, проверенная во время планирования емкости, будет установлена на месте, можно двигаться дальше
и выполнять обновление на SharePoint Server 2010.

Повышение производительности существующей фермы SharePoint Server 2010. Задача планирования емкости должна
помочь выявить узкие места в текущей реализации, разработать способы сокращения или исключения этих узких мест и
проверить усовершенствованную реализацию, соответствующую бизнес-требованиям организации для служб SharePoint
Server. Существуют различные способы решения проблем производительности начиная с таких несложных, как
перераспределение служб по имеющемуся оборудованию, обновление имеющегося оборудования или добавление
дополнительного оборудования и дополнительных служб. Следует протестировать и проверить различные подходы при
выполнении задачи планирования емкости, а затем составить план развертывания на основе результатов тестирования.
68
Шаг 5. Наблюдение и поддержка
Для поддержания производительности системы необходимо вести наблюдение за сервером, чтобы определить потенциальные
узкие места. Чтобы вести эффективное наблюдение, необходимо ознакомиться с ключевыми показателями, которые покажут,
какая часть фермы требует внимания, и научиться интерпретировать эти показатели. Если оказывается, что ферма отклоняется
от заданных целевых показателей, можно перенастроить ферму путем добавления или удаления аппаратных ресурсов,
изменения топологии или изменения способа хранения данных.
См. в разделе Мониторинг и обслуживание SharePoint Server 2010 список параметров, которые можно изменять для наблюдения
за средой на ранних этапах; это поможет определить, какие изменения необходимы. Помните, что расширение возможностей
наблюдения повлияет на объем дискового пространства, необходимый для базы данных использования. После того как среда
стабилизируется и дальнейшая необходимость в таком пристальном наблюдении отпадет, можно вернуть для параметров
значения по умолчанию.
Дополнительные сведения о наблюдении за исправностью и устранении неисправностей с помощью встроенных средств
наблюдения за исправностью в интерфейсе центра администрирования SharePoint Server см. в следующих статьях:
Health Monitoring (SharePoint Server 2010)
Решение проблем и диагностика (http://technet.microsoft.com/ru-ru/library/ee748639.aspx)
См. также
Понятия
Обзор управления емкостью и изменения размера для SharePoint Server 2010
Тестирование производительности для SharePoint Server 2010
Мониторинг и обслуживание SharePoint Server 2010
Планирование и настройка рабочих характеристик хранилища и SQL Server (SharePoint Server 2010)
Другие ресурсы
Health Monitoring (SharePoint Server 2010)
69
Тестирование производительности для SharePoint Server
2010
В этой статье описывается тестирование производительности Microsoft SharePoint Server 2010. Этап тестирования и
оптимизации — это важнейший компонент эффективного управления емкостью. Перед развертыванием в рабочей среде новую
архитектуру необходимо протестировать, а также провести приемочное тестирование в сочетании со следующими
рекомендациями по мониторингу, чтобы гарантировать, что разработанная архитектура достигает целей по производительности
и емкости. Это позволяет определить и оптимизировать потенциальные узкие места до того, как с ними столкнутся пользователи
в реальном развертывании. При обновлении из среды Microsoft Office SharePoint Server 2007 и планировании архитектурных
изменений или оценке пользовательской нагрузки новых компонентов SharePoint Server 2010 тестирование особенно важно для
обеспечения соответствия новой основанной на SharePoint Server 2010 среды целям по производительности и емкости.
После тестирования среды результаты тестирования можно проанализировать, чтобы определить, какие изменения необходимо
сделать для достижения целей по производительности и емкости, установленных на Этапе 1: модельПланирование емкости для
SharePoint Server 2010.
Ниже перечисляются вспомогательные шаги, которые рекомендуется выполнить на этапе подготовки:
 Создайте тестовую среду, сходную с исходной архитектурой, разработка которой описывалась в разделе Шаг 2: макет.

Заполните хранилище набором данных, указанным вами в разделе Шаг 1: модель.

Приложите к системе искусственной нагрузку, представляющую рабочую нагрузку, определенную в разделе Шаг 1: модель.

Запустите тесты, проанализируйте результаты и оптимизируйте используемую вами архитектуру.

Выполните развертывание этой оптимизированной архитектуры в центре обработки данных и реализуйте пилотный проект с
небольшим набором пользователей.

Проанализируйте результаты пилотного проекта, выявите потенциально узкие места и оптимизируйте используемую
архитектуру. При необходимости повторите тестирование.

Выполните развертывание в рабочей среде.
70
Прежде чем приступать к чтению этой статьи, вы должны прочитать статью Обзор управления емкостью и изменения размера
для SharePoint Server 2010.
Содержание:
 Создание плана тестирования

Создание тестовой среды

Создание тестов и средств тестирования
Создание плана тестирования
Убедитесь, что план включает следующие элементы:
 Оборудование, предназначенное для работы при ожидаемой целевой рабочей производительности. Всегда измеряйте
производительность тестовых систем с запасом.

При наличии пользовательского кода или компонента важно сначала протестировать их производительность изолированно,
чтобы проверить их производительность и стабильность. После подтверждения стабильности протестируйте систему с
установленными компонентами и сравните с производительностью фермы без них. Пользовательские компоненты часто
являются главной причиной проблем с производительностью и надежностью в рабочих системах.

Необходимо понимать цель тестирования. Цели тестирования следует определить заблаговременно. Проверка
производительности новых пользовательских компонентов, разработанных для фермы? Проверка длительности обхода и
индексирования контента? Определение скорости обработки запросов, которую может поддерживать ферма? Для
тестирования могут быть выбраны разные цели, и при разработке хорошего плана тестирования сначала нужно решить,
каковы эти цели.

Необходимо понимать, как измерить цель тестирования. Например, при измерении пропускной способности фермы
необходимо измерить показатель RPS и задержку страниц. При измерении производительности поиска необходимо измерить
время обхода контента и скорость индексирования документов. Хорошее понимание цели тестирования поможет ясно
определить, какие ключевые индикаторы производительности необходимо проверить для выполнения тестов.
Создание тестовой среды
После определения целей теста, необходимых измерений и требований к емкости фермы (на этапах 1 и 2 этого процесса),
следующей целью будет проектирование и создание тестовой среды. Работа по созданию тестовой среды часто
71
недооценивается. Тестовая среда должна как можно точнее соответствовать рабочей среде. При разработке тестовой среды
следует продумать следующие компоненты и функции:
 Проверка подлинности — выберите способ проверки подлинности, который будет использовать ферма: доменные службы
Active Directory, проверка подлинности на основе форм (и с каким каталогом), проверка подлинности на основе утверждений
и т. д. Независимо от используемого каталога, сколько пользователей необходимо для тестовой среды и как их создать?
Сколько необходимо групп или ролей и как их создать и наполнить? Также следует убедиться, что для служб проверки
подлинности выделено достаточно ресурсов и они не станут узким местом во время тестирования.

DNS — определите, какие пространства имен понадобятся во время тестирования. Определите, какие серверы будут
отвечать на запросы и запланируйте, какие IP-адреса будут использоваться различными серверами и какие записи DNS
необходимо создать.

Балансировка нагрузки — если используется больше одного сервера (обычно так и есть, так как в противном случае
нагрузка слишком незначительна, чтобы ее тестировать), понадобится решение балансировки нагрузки. Это может быть
оборудование балансировки нагрузки или программная балансировка, подобная балансировке сетевой нагрузки Windows.
Определите, что будет использоваться, и запишите все сведения о конфигурации, которые понадобятся для быстрой и
эффективной настройки. Учтите, что агенты нагрузочного тестирования обычно пытаются разрешить IP-адрес в URL-адрес
только один раз в 30 минут. Это означает, что для балансировки нагрузки не следует использовать файл локальных узлов
или циклический перебор DNS, так как агенты тестирования вероятно будут доходить до одного и того же сервера для
каждого отдельного запроса, вместо выполнения балансировки между всеми доступными серверами.

Тестовые серверы — при планировании тестовой среды необходимо запланировать не только серверы для фермы
SharePoint Server 2010, но и серверы, необходимые для выполнения тестов. Обычно это как минимум 3 сервера; может
понадобиться и больше. Если для тестирования используется Visual Studio Team System (Team Test Load Agent), один сервер
будет использоваться в качестве контроллера нагрузочного тестирования. Еще как минимум 2 сервера обычно используются
в качестве агентов нагрузочного тестирования. Агенты — это компьютеры, которые получают от контроллера тестирования
указания для выполнения тестов и отправляют запросы в ферму SharePoint Server 2010. Сами результаты тестов
сохраняются на компьютере под управлением SQL Server. Не следует использовать тот же компьютер SQL Server, который
используется для фермы SharePoint Server 2010, так как запись данных тестирования будет занимать доступные ресурсы
SQL Server для фермы SharePoint Server 2010. Также необходимо отслеживать тестовые серверы при выполнении тестов,
таким же образом, как отслеживаются серверы в ферме SharePoint Server 2010, контроллеры доменов и т. д., чтобы
гарантировать, что результаты тестов характеризуют настраиваемую ферму. Иногда агенты или контроллер нагрузки могут
сами стать узким местом. Если это происходит, то демонстрируемая тестами производительность как правило не отражает
то максимальное значение, которое может поддерживать ферма.
72

SQL Server — в тестовой среде следуйте руководствам, данным в разделах "Настройка SQL Server" и "
Проверка и
мониторинг хранилища и производительности SQL Server" статьи Планирование и настройка рабочих характеристик
хранилища и SQL Server (SharePoint Server 2010).

Проверка набора данных — при выборе контента, с которым будут выполняться тесты, учтите, что наилучшим вариантом
является использование данных из существующей рабочей среды. Например, можно создать резервную копию баз данных
контента из рабочей фермы и восстановить их в тестовой среде, а затем присоединить базы данных к ферме. При
выполнении тестов с искусственно созданными или типовыми данными результаты могут быть искажены из-за их отличия от
реального контента.
Если необходимо создать типовые данные, учтите следующие соображения при построении такого контента:
 Все страницы должны быть опубликованы; ничто не должно быть извлечено

Навигация должна быть реалистичной; не выходите за пределы того, чего достаточно для использования в рабочей среде.

Следует продумать настройки, которые будет использовать рабочий сайт. Например, реализованные в тестовой среде
главные страницы, таблицы стилей, JavaScript и т. д. должны как можно точнее соответствовать рабочей среде.

Определите, сколько потребуется групп и/или уровней разрешений SharePoint и как связать с ними пользователей.

Определите, нужно ли импортировать профили и сколько времени это займет.

Определите, понадобятся ли аудитории и как они будут создаваться и наполняться.

Определите, нужны ли дополнительные источники контента для поиска и что потребуется для их создания. Если создавать
их не нужно, определите, будет ли предоставлен сетевой доступ для их обхода.

Определите, достаточно ли типовых данных — документов, списков, элементов списков и т. д. Если данных недостаточно,
запланируйте создание этого контента.

Запланируйте достаточно уникального контента для адекватного тестирования поиска. Распространенной ошибкой является
отправка одного и того же документа — сотен или даже тысяч элементов — в разные библиотеки документов с разными
именами. Это может повлиять на производительность поиска, так как обработчик запросов будет регулярно тратить время на
повторное обнаружение, чего он не должен делать в рабочей среде с реальным контентом.
Создание тестов и средств тестирования
После подготовки тестовой среды необходимо создать и настроить тесты, которые будут использоваться для измерения
производительности фермы. В этом разделе иногда будут приводиться ссылки на Visual Studio Team System (Team Test Load
73
Agent), но многие концепции применимы независимо от используемого средства нагрузочного тестирования. Дополнительные
сведения о Visual Studio Team System см. в статье о Visual Studio Team System на веб-сайте MSDN (http://msdn.microsoft.com/ruru/library/fda2bad5.aspx" ).
Для нагрузочного тестирования ферм SharePoint 2010 можно также использовать набор нагрузочных тестов SharePoint (LTK) в
сочетании с VSTS. Набор нагрузочных тестов создает нагрузочный тест Visual Studio Team System 2008, основанный на
журналах IIS Windows SharePoint Services 3.0 и Microsoft Office SharePoint Server 2007. Нагрузочный тест VSTS можно
использовать для создания искусственной нагрузки для SharePoint Foundation 2010 или SharePoint Server 2010 как часть
упражнения по планированию емкости или нагрузочного испытания перед обновлением.
Набор нагрузочных тестов входит в состав набора средств администрирования Microsoft SharePoint 2010 версии 1.0, доступный в
центре загрузки Майкрософт (Возможно, на английском языке)
(http://www.microsoft.com/downloads/details.aspx?FamilyId=718447d8-0814-427a-81c3-c9c3d84c456e&displaylang=en) (Возможно, на
английском языке).
Ключевым условием успеха тестов является возможность эффективного моделирования реалистичной рабочей нагрузки с
помощью создания запросов в широком диапазоне данных тестового сайта, моделируя действия пользователей, которые будут
обращаться к широкому диапазону контента в рабочей ферме SharePoint Server 2010. Для этого обычно необходимо строить
тесты таким образом, чтобы они управлялись данными. Вместо создания сотен отдельных тестов, в которых жестко заданы
обращения к конкретным страницам, следует применить всего несколько тестов, которые используют источники данных,
содержащие URL-адреса этих элементов, для динамического доступа к соответствующему набору страниц.
В Visual Studio Team System (Team Test Load Agent) источник данных может быть представлен в разных форматах, но формат
файла CSV часто наиболее прост для управления и транспортировки между средой разработки и тестовой средой. Помните, что
при создании CSV-файлов с таким контентом может понадобиться создание пользовательских средств для перечисления
основанной на SharePoint Server 2010 среды и записи используемых URL-адресов.
Использование таких средств может понадобиться для выполнения следующих задач:
 Создание пользователей и групп в Active Directory или в другом хранилище для проверки подлинности, если используется
проверка подлинности на основе форм

Перечисление URL-адресов для сайтов, списков и библиотек, элементов списков, документов и т. д. и их размещение в CSVфайлах для нагрузочных тестов

Отправка образцов документов в различные библиотеки документов и на сайты

Создание семейств веб-сайтов, веб-сайтов, списков, библиотек, папок и элементов списков

Создание личных сайтов
74

Создание CSV-файлов с именами и паролями тестовых пользователей; это учетные записи пользователей, от имени которых
будут выполняться нагрузочные тесты. Должно быть несколько файлов, чтобы некоторые содержали только пользователей с
правами администратора, некоторые — пользователей с повышенными привилегиями (такими как "автор" / "участник",
"менеджер иерархии" и т. д.), некоторые — только читателей и т. д.

Создание списка образцов ключевых слов и фраз для поиска

Наполнение групп и уровней разрешений SharePoint пользователями и группами Active Directory (или ролями, если
используется проверка подлинности на основе форм)
При создании веб-тестов необходимо соблюдать и реализовывать следующие рекомендации:
 Записывайте простые веб-тесты в качестве отправной точки. В этих тестах жестко задаются значения для таких параметров,
как URL-адрес, идентификаторы и т. д. Замените эти жестко заданные значения на ссылки из CSV-файлов. Привязка данных
к этим значениям в Visual Studio Team System (Team Test Load Agent) выполняется очень просто.

Всегда создавайте для теста правила проверки. Например, если при запросе страницы происходит ошибка, в ответе часто
можно получить страницу error.aspx. С точки зрения веб-теста это выглядит просто как один из положительных ответов, так
как в результатах нагрузочного теста возвращается код состояния HTTP 200 ("успешно"). Хотя очевидно, что произошла
ошибка, ее необходимо отслеживать по-другому. Создание одного или нескольких правил проверки позволяет при получении
в ответе некоторого текста определить, что проверка завершилась неудачей, и пометить запрос как неудачный. Примером
простого правила проверки в Visual Studio Team System (Team Test Load Agent) может быть проверка ResponseUrl — она
регистрирует ошибку, если отображенная после перенаправления страница не совпадает со страницей ответа, которая была
записана в тесте. Также можно добавить правило FindText, которое регистрирует ошибку, если находит слова "в доступе
отказано", например, в ответе.

Используйте для тестов несколько пользователей с разными ролями. Некоторые поведения, например выходное
кэширование, действуют по-разному в зависимости от прав текущего пользователя. Например, администратор семейства
веб-сайтов или прошедший проверку пользователь с правами на утверждение или разработку не получит кэшированные
результаты, так как он всегда должен видеть текущую версию контента. Однако анонимные пользователи получат
кэшированный контент. Необходимо убедиться, что среди тестовых пользователей есть пользователи со всеми ролями,
которые приблизительно соответствуют пользователям в рабочей среде. Например, в рабочей среде вероятно существует
только два или три администратора семейства сайтов, поэтому не следует создавать тесты, в которых 10% запросов страниц
выполняются учетными записями администраторов семейства сайтов тестового контента.

Зависящие от синтаксического анализа запросы — это атрибут Visual Studio Team System (Team Test Load Agent), который
определяет, должен ли агент тестирования пытаться получить только страницу или также все связанные запросы,
75
являющиеся частью страницы, например изображения, таблицы стилей, скрипты и т. д. При нагрузочном тестировании эти
элементы обычно игнорируются по нескольким причинам:

После первого обращения пользователя к сайту эти элементы часто кэшируются локальным браузером

Как правило, эти элементы не поступают из SQL Server в среде, основанной на SharePoint Server 2010. При включенном
кэшировании больших двоичных объектов они обслуживаются веб-серверами и поэтому не создают нагрузку на SQL
Server.
Включение в тесты зависящих от синтаксического анализа запросов имеет смысл при постоянно высоком проценте впервые
посещающих сайт пользователей, при отключенном кэшировании браузера, или если по какой-то причине использование
кэширования больших двоичных объектов не планируется. Однако для большинства реализаций это скорее исключение, чем
практическое правило. Обратите внимание, включение этого запроса может существенно увеличить числа RPS, о которых
сообщает контроллер тестирования. Эти запросы обслуживаются так быстро, что могут создать впечатление, что доступная
производительность фермы гораздо выше, чем на самом деле.
 Не забудьте также выполнить моделирование действий клиентского приложения. Клиентские приложения, такие как Microsoft
Word, PowerPoint, Excel и Outlook, также порождают запросы ферм SharePoint Server 2010. Они добавляют нагрузку на среду,
отправляя такие запросы сервера, как получение RSS-каналов, получение социальных сведений, запросы сведений о
структуре сайтов и списков, синхронизация данных и т. д. Эти типы запросов должны включаться в тесты и моделироваться,
если в реализации есть такие клиенты.


В большинстве случаев веб-тест должен содержать только один запрос. Если тест содержит только один запрос, это
упрощает настройку и диагностику окружения теста и отдельных запросов. Как правило, веб-тесты должны содержать
несколько запросов только в тех случаях, когда моделируемые ими операции состоят из нескольких запросов. Например,
многошаговый тест потребуется для тестирования такого набора действий: извлечение документа, его редактирование,
возвращение и публикация. Для этого документа также требуется резервирование состояния между действиями — например,
одна и та же учетная запись должна использоваться для его извлечения, правки и возвращения. Такие многошаговые
операции, требующие переноса состояния между действиями, лучше всего обслуживаются несколькими запросами в одном
веб-тесте.
Проверьте каждый веб-тест в отдельности. Убедитесь, что каждый тест способен успешно выполняться, перед тем как
выполнять его в более крупном нагрузочном тесте. Убедитесь, что все имена веб-приложений разрешаются, а используемые
в тесте учетные записи пользователей обладают достаточными правами для его выполнения.
Веб-тесты содержат запросы отдельных страниц, отправки документов, просмотра элементов списков и т. д. Все эти запросы
действуют совместно в нагрузочных тестах. В нагрузочный тест включаются все различные веб-тесты, которые должны быть
выполнены. На выполнение каждого веб-теста может быть выделен определенный процент времени — например, если вы
76
считаете, что 10% запросов в рабочей ферме — это поисковые запросы, настройте в нагрузочном тесте для выполнения вебтеста поисковых запросов 10% времени. В Visual Studio Team System (Team Test Load Agent) для нагрузочных тестов также
можно настроить такие элементы, как набор браузеров, набор сетей, шаблоны нагрузки и параметры выполнения.
Существует несколько дополнительных рекомендаций, которых следует придерживаться и реализовать в нагрузочных тестах:
 Используйте в тестах подходящее соотношение операций чтения/записи. Перегрузка теста операциями записи может
существенно повлиять на общую производительность теста. Даже в фермах для совместной работы в соотношении
операций чтения/записи операций чтения значительно больше. Дополнительные сведения см. на странице, содержащей
примеры технического внедрения: производительность и емкость (Возможно, на английском языке)
(http://technet.microsoft.com/ru-ru/library/cc261716.aspx).

Учитывайте влияние других ресурсоемких операций и продумайте, должны ли они происходить во время нагрузочного
тестирования. Например, во время нагрузочного тестирования обычно не выполняются такие операции, как резервное
копирование и восстановление. Во время нагрузочного тестирования обычно не выполняется полный обход контента при
поиске, тогда как добавочный обход можно считать нормальным. Необходимо учесть, как такие задачи будут запланированы
в рабочей среде — будут ли они выполняться во время пиковой нагрузки? Если нет, их вероятно следует исключить во время
нагрузочного тестирования, когда определяется максимальная для стабильного состояния нагрузка, которая может
поддерживаться для пикового трафика.

Не используйте время задержки. Время задержки — это функция Visual Studio Team System (Team Test Load Agent), которая
позволяет моделировать время паузы между нажатиями пользователя на странице. Например, типичный пользователь
может загрузить страницу, потратить три минуты на ее чтение, а затем щелкнуть ссылку на странице, чтобы перейти на
другой сайт. Правильное моделирование такой ситуации в тестовой среде практически невозможно и в сущности не сделает
результаты тестирования более ценными. Трудность моделирования обусловлена тем, что в большинстве организаций нет
способа отслеживания действий различных пользователей и времени, которое проходит между нажатиями пользователей на
разных типах сайтов SharePoint (например, на сайтах публикации, сайтах поиска, сайтах для совместной работы и т д.). Это
также не имеет практического смысла, так как пользователь может делать паузы между запросами страниц, а серверы на
основе SharePoint Server 2010 — не могут. Они просто получают равномерный поток запросов, который может иметь пики и
провалы с течением времени, но не простаивают в состоянии ожидания во время пауз между нажатиями пользователей на
ссылки на страницах.

Следует понимать разницу между пользователями и запросами. В Visual Studio Team System (Team Test Load Agent) имеется
шаблон нагрузки, в который можно ввести число моделируемых пользователей. Это число не имеет отношения к
пользователям приложения, а просто определяет, сколько потоков должно использоваться в агентах нагрузочного
тестирования для создания запросов. Будет ошибкой считать, что если в развертывании имеется, к примеру, 5000
77
пользователей, то и в Visual Studio Team System (Team Test Load Agent) нужно использовать число 5000 — это не так! Это
одна из многих причин, почему при оценке требований планирования емкости требования к нагрузке должны быть основаны
на числе запросов в секунду, а не на количестве пользователей. В нагрузочном тесте Visual Studio Team System (Team Test
Load Agent) вы обнаружите, что часто можно создавать сотни запросов в секунду, используя всего 50 — 75 "пользователей"
нагрузочного теста.

Используйте шаблон постоянной нагрузки для получения наиболее надежных и воспроизводимых результатов тестирования.
В Visual Studio Team System (Team Test Load Agent) можно выбрать шаблон нагрузки, основанный на постоянном количестве
пользователей (потоков, как объяснялось в предыдущем абзаце), шаблон с постепенным увеличением количества
пользователей или тестирование нагрузки на основе цели. В шаблоне с постепенным увеличением количества
пользователей тестирование начинается с небольшим количеством пользователей, которое постепенно увеличивается
посредством добавления дополнительных пользователей через каждые несколько минут. Тестирование нагрузки на основе
цели выполняется при установке пороговых значений для определенного счетчика диагностики, например для счетчика
загрузки ЦП. Тест пытается управлять нагрузкой, чтобы поддерживать значение этого счетчика между минимальным и
максимальным пороговыми значениями, которые для него определены. Однако, если необходимо определить только
максимальную производительность, которую ферма SharePoint Server 2010 может поддерживать во время пиковой нагрузки,
более эффективным и правильным будет выбор шаблона постоянной нагрузки. Он позволяет проще определить, какую
нагрузку система может принять, прежде чем начнет регулярно превышать пороговые значения, которые должны
поддерживаться в работоспособной ферме.
Учтите, что при каждом запуске нагрузочного теста он изменяет данные в базе данных. Выполняет ли он отправку документов,
изменение элементов списков или просто регистрирует действия в базе данных использования, некоторые данные будут
записываться в базу данных SQL Server. Чтобы обеспечить получение непротиворечивого и допустимого набора результатов при
каждом нагрузочном тестировании, перед запуском первого нагрузочного теста необходимо иметь доступную резервную копию.
После выполнения каждого теста резервная копия должна использоваться для восстановления контента в исходное состояние.
См. также
Понятия
Обзор управления емкостью и изменения размера для SharePoint Server 2010
Планирование емкости для SharePoint Server 2010
Мониторинг и обслуживание SharePoint Server 2010
Планирование и настройка рабочих характеристик хранилища и SQL Server (SharePoint Server 2010)
78
Другие ресурсы
Health Monitoring (SharePoint Server 2010)
79
Мониторинг и обслуживание SharePoint Server 2010
В этой статье представлены сведения о счетчиках мониторинга и производительности для ферм Microsoft SharePoint Server 2010.
Для поддержки производительности системы SharePoint Server 2010 необходимо отслеживать сервер, чтобы определить
потенциальные узкие места. Для эффективного отслеживания необходимо знать, какие ключевые индикаторы могут сообщить о
том, что определенная часть фермы требует внимания, и как интерпретировать эти индикаторы. Если обнаружится, что ферма
работает, не достигая определенных для нее целей, ферму можно отрегулировать, добавляя или удаляя аппаратные ресурсы,
изменяя топологию или способ хранения данных.
Сведения этого раздела должны помочь администраторам в ручной настройке счетчиков производительности и других
параметров. Дополнительные сведения об отслеживании исправности и устранении неполадок с помощью средств мониторинга
исправности, встроенных в интерфейс центра администрирования SharePoint, см. в следующих статьях:
 Health Monitoring (SharePoint Server 2010)
 Solving Problems and Troubleshooting (SharePoint Server 2010)
Прежде чем приступать к чтению этой статьи, вы должны прочитать статью Обзор управления емкостью и изменения размера
для SharePoint Server 2010.
Содержание:
 Настройка мониторинга

Устранение узких мест
Настройка мониторинга
Ниже приведен список параметров, которые можно изменить для отслеживания среды на ранних стадиях, которое поможет
определить необходимость изменений. Имейте в виду, что увеличение возможностей мониторинга повлияет на объем дискового
пространства, необходимый для базы данных использования. Когда среда станет стабильной и детальный мониторинг станет
ненужным, можно вернуть этим параметрам значения по умолчанию.
80
Параметр
Значение
Примечания
Защита журнала событий от переполнения
Отключено
Значение по умолчанию
Включено. Этот параметр
можно отключить, чтобы
собрать как можно больше
данных мониторинга. Для
выполнения обычных
операций он должен быть
включен.
5 мин.
Значение по умолчанию 30
минут. При уменьшении
значения этого параметра
данные импортируются в
базу данных использования
чаще. Это особенно удобно
при диагностике. Для
выполнения обычных
операций значение этого
параметра должно быть
равно 30 минутам.
Включено
Значение по умолчанию
Отключено, кроме
поставщика "Мониторинг
исправности поиска —
трассировка событий". Эти
поставщики собирают
Расписание задания таймера
Импорт данных об использовании Microsoft
SharePoint Foundation
Поставщики диагностики
Включить всех поставщиков диагностики
81
Параметр
Значение
Примечания
данные о исправности для
различных функций и
компонентов. Для
выполнения обычных
операций можно вернуть
значение по умолчанию.
Задать интервалы расписания "задание-диагностикисчетчик-производительности-поставщик-wfe" и
"задание-диагностики-счетчик-производительностипоставщик-sql"
1 минута
Значение по умолчанию 5
минут. При уменьшении
значения этого параметра
данные будут выбираться
чаще, что особенно
полезно при диагностике.
Для выполнения обычных
операций значение этого
параметра должно быть
равно 5 минутам.
Включено
Значение по умолчанию
Отключено. Включение
этого параметра позволяет
выполнять диагностику
ошибок запросов контента,
используя трассировку
стека процесса. Для
выполнения обычных
операций этот параметр
должен быть отключен.
Прочее
Включить трассировку стека для запросов контента
82
Параметр
Значение
Примечания
Включить информационную панель разработчика
Включено
Значение по умолчанию
Отключено. Включение
этого параметра позволяет
выполнять диагностику
медленных страниц или
других проблем с помощью
информационной панели
разработчика. Для
выполнения обычных
операций, когда
диагностика уже не нужна,
этот параметр следует
отключить.
Включено
Включение ведения
журнала этого набора
счетчиков позволяет
собирать больше данных
об использовании и лучше
понимать шаблоны
трафика в среде.
Сбор данных об использовании
Использование импорта контента
Использование экспорта контента
Запросы страниц
Использование компонента
Использование запроса поиска
Использование инвентаризации сайта
Задания таймера
Использование оценок
Счетчики производительности
При использовании базы данных использования в нее можно добавить счетчики производительности, помогающие отслеживать
и оценивать производительность фермы. Данные этих счетчиков регистрируются автоматически с определенным интервалом (по
83
умолчанию 30 минут). Таким образом, можно запрашивать базу данных использования, чтобы получать данные счетчиков и
создавать графическое представление результатов с течением времени. Ниже приведен пример использования командлета
PowerShell Add-SPDiagnosticsPerformanceCounter для добавления счетчика "% загруженности процессора" в базу данных
использования. Этот командлет необходимо выполнить на одном из веб-серверов:
Копировать
код
Add-SPDiagnosticsPerformanceCounter -Category "Processor" -Counter "% Processor Time" -Instance "_Total" WebFrontEnd
Существует несколько универсальных счетчиков производительности, которые следует отслеживать для любой системы
серверов. Эти счетчики приведены в следующей таблице.
Счетчик производительности
Описание
Процессор
Необходимо отслеживать производительность процессора, чтобы
гарантировать, что совокупное использование процессора не
сохраняется на постоянно высоком уровне (свыше 80 процентов), так
как в противном случае система будет не способна обрабатывать
неожиданные всплески активности. А также, что в обычном
состоянии не произойдет "эффект домино", когда при отказе одного
из компонентов остальные компоненты приходят в нерабочее
состояние. Например, при наличии трех веб-серверов усредненная
по всем серверам загрузка процессора не должна превышать 60%,
чтобы при отказе одного из серверов у двух других серверов
сохранялся запас для обработки дополнительной нагрузки.
Сетевой интерфейс
Отслеживайте скорость отправки и получения данных через сетевую
интерфейсную плату. Она не должна превышать 50 процентов
пропускной способности сети.
84
Счетчик производительности
Описание
Диски и кэш
Существует несколько параметров логического диска, которые
необходимо отслеживать регулярно. Доступное дисковое
пространство является существенным фактором при оценке емкости,
но также необходимо проанализировать время простоя диска. В
зависимости от типов приложений или служб, выполняемых на
серверах, можно проанализировать время чтения и записи диска.
Расширенная очередь для функции записи или чтения будет влиять
на производительность. Кэш оказывает существенное влияние на
операции чтения и записи. Необходимо отслеживать увеличение
количества ошибок кэша.
Память и файл подкачки
Отслеживайте объем доступной для выделения физической памяти.
Нехватка памяти приведет к чрезмерному использованию файла
подкачки и увеличению частоты ошибок страниц.
Системные счетчики
В следующей таблице приведены сведения о системных объектах и счетчиках, которые можно добавить в набор отслеживаемых
в базе данных использования счетчиков, выполнив команду SPDiagnosticPerformanceCounter на веб-сервере.
Объекты и счетчики
Описание
Процессор
% загруженности процессора
Показывает использование процессора за период времени.
Постоянно высокое значение этого счетчика может указывать на
негативное влияние на производительность. Не забывайте учитывать
"совокупное значение" в многопроцессорных системах. Также можно
измерить использование каждого процессора, чтобы обеспечить
балансировку производительности между ядрами.
85
Объекты и счетчики
Описание
Диск
- Средняя длина очереди диска
Показывает среднее число запросов на чтение и запись, помещенных
в очередь для выбранного диска за определенный интервал
времени. Большая длина очереди диска может не быть проблемой,
пока это не сказывается на операциях чтения/записи диска и система
работает в стабильном состоянии без расширения очереди.
Средняя длина очереди на чтение диска
Среднее число помещенных в очередь запросов на чтение.
Средняя длина очереди на запись диска
Среднее число помещенных в очередь запросов на запись.
Обращений чтения с диска/сек
Число операций чтения с диска в секунду.
Обращений записи на диск/сек
Число операций записи на диск в секунду.
Память
- Доступно МБ
Показывает объем доступной для выделения физической памяти.
Нехватка памяти приведет к чрезмерному использованию файла
подкачки и увеличению частоты ошибок страниц.
- Ошибок кэша/сек
Этот счетчик показывает частоту возникновения ошибок, когда при
поиске страницы в кэше файловой системы ее не удается найти. Это
может быть программная ошибка, когда страница находится в
памяти, или аппаратная ошибка, когда страница находится на диске.
Эффективное использование кэша для операций чтения и записи
может оказывать существенное влияние на производительность
сервера. Необходимо отслеживать увеличение количества ошибок
кэша, на которое указывает уменьшение значений счетчиков
Асинхронных быстрых чтений/сек или Упреждающих чтений/сек.
- Обмен страниц/сек
Этот счетчик показывает частоту считывания страниц с диска или
86
Объекты и счетчики
Описание
записи на диск в случае страничных прерываний. Увеличение его
значения указывает на проблемы, связанные с производительностью
всей системы.
Файл подкачки
- % использования и пиковый % использования
Файл подкачки сервера, иногда называемый своп-файлом, хранит
адреса "виртуальной" памяти на диске. Ошибки страниц возникают,
когда выполняемый процесс должен остановиться и ждать, пока
требуемые "виртуальные" ресурсы не загрузятся с диска в память.
Они могут возникать чаще, если физическая память является
недостаточной.
Сетевой адаптер
- Всего байт/сек
Это скорость отправки и получения данных через сетевую
интерфейсную плату. Если эта скорость превышает 40-50 процентов
пропускной способности сети, может потребоваться дополнительное
выяснение причин. Для точного выяснения причин отследите
счетчики Получено байт/сек и Отправлено байт/сек.
Процесс
- Рабочий набор
Этот счетчик показывает текущий размер (в байтах) рабочего набора
для данного процесса. Эта память резервируется для процесса, даже
если он не используется.
- % загруженности процессора
Этот счетчик показывает процент загруженности процессора данным
процессом.
Число потоков (_Total)
Текущее число потоков.
ASP.NET
87
Объекты и счетчики
Описание
Всего запросов
Общее число запросов с момента запуска службы.
Запросов в очереди
Microsoft SharePoint Foundation 2010 предоставляет стандартные
блоки для HTML-страниц, которые отображаются в браузере
пользователя через HTTP. Этот счетчик показывает число запросов,
ожидающих обработки.
Время ожидания запроса
Время в миллисекундах, в течение которого самый последний запрос
ожидал обработки в очереди. При увеличении числа событий
ожидания пользователи будут ощущать ухудшение
производительности отображения страниц.
Отказанных запросов
Общее число запросов, не выполненных из-за нехватки ресурсов
сервера для их обработки. Этот счетчик представляет число запросов,
возвративших код состояния HTTP 503, указывающий на перегрузку
сервера.
Выполняется запросов (_Total)
Число запросов, выполняемых в данный момент.
Запросов/сек (_Total)
Число запросов, выполняемых в секунду. Представляет текущую
пропускную способность приложения. При постоянной нагрузке это
число должно оставаться в определенном диапазоне, запрещая
другую работу сервера (такую как сборка мусора, поток очистки
кэша, внешние средства сервера и т. д.).
Память CLR .NET
Сборов мусора для поколения 0
Этот счетчик показывает, сколько раз с момента запуска приложения
для объектов поколения 0 (т. е. для объектов, существующих меньше
остальных, размещенных самыми последними) выполнялся сбор
"мусора". Это число можно использовать в соотношении "поколение
0: поколение 1: поколение 2", чтобы убедиться, что число сборов для
88
Объекты и счетчики
Описание
поколения 2 не на много превышает число сборов для поколения 0
(оптимально — в два раза).
Сборов мусора для поколения 1
Показывает, сколько раз с момента запуска приложения для
объектов поколения 1 выполнялся сбор "мусора".
Сборов мусора для поколения 2
Показывает, сколько раз с момента запуска приложения для
объектов поколения 2 выполнялся сбор "мусора". Этот счетчик
увеличивается в конце сбора мусора для поколения 2 (также
называемом полным сбором мусора).
% времени на сбор мусора
Показывает процент времени, затраченного на выполнение сбора
"мусора" с момента завершения последнего цикла сбора мусора.
Этот счетчик обычно может служить индикатором работы по сбору и
уплотнению памяти, которую выполняет сборщик мусора по
поручению приложения. Этот счетчик обновляется только при
завершении каждого сбора мусора. Этот счетчик не является
усредненным, он отражает последнее наблюдаемое значение. При
нормальной работе значение этого счетчика не должно превышать
5%.
Счетчики SQL Server
В следующей таблице приведены сведения об объектах и счетчиках SQL Server.
Объекты и счетчики
Описание
Общая статистика
Этот объект содержит счетчики для мониторинга работы сервера в
целом, например число текущих подключений или число
пользователей, в течение секунды подключающихся к компьютерам
89
Объекты и счетчики
Описание
с запущенными экземплярами SQL Server и отключающихся от них.
Подключения пользователей
Этот счетчик показывает число подключений пользователей для
экземпляра SQL Server. Если его значение окажется на 500% выше
базового, это может привести к снижению производительности.
Базы данных
Этот объект содержит счетчики для мониторинга операций массового
копирования, пропускной способности средства резервного
копирования и восстановления, операций с журналами транзакций.
Мониторинг транзакций и журналов транзакций позволит
определить, сколько пользовательских операций выполняется в базе
данных и насколько заполнен журнал транзакций. Объем
пользовательских операций может влиять на производительность
базы данных, размер журнала, выполнение блокировки и
репликации. Мониторинг операций с журналом на нижнем уровне,
дающий оценки активности пользователей и загруженности
ресурсов, помогает выявлять узкие места в системе.
Транзакций/сек
Этот счетчик показывает количество транзакций для данной базы
данных или всего экземпляра SQL Server, выполняемых в секунду.
Это число помогает в определении базового уровня и устранении
проблем.
Блокировки
Этот объект содержит информацию о блокировках SQL Server по
отдельным типам ресурсов.
Количество взаимоблокировок/сек
Этот счетчик показывает число взаимоблокировок, происходящих в
секунду в SQL Server. Его значение не должно превышать 0.
Среднее время ожидания (мс)
Этот счетчик показывает среднее время ожидания по всем запросам
блокировки, вызвавшим переход в состояние ожидания.
90
Объекты и счетчики
Описание
Время ожидания блокировки (мс)
Этот счетчик показывает общее время ожидания для блокировок,
установленных за последнюю секунду.
Ожиданий блокировок/сек
Этот счетчик показывает число запросов блокировки в секунду,
которые не были удовлетворены немедленно и были вынуждены
ждать освобождения ресурсов.
Кратковременные блокировки
Этот объект содержит счетчики для мониторинга внутренних
блокировок ресурсов SQL Server, называемых кратковременными
блокировками. Мониторинг таких блокировок, дающий оценки
активности пользователей и загруженности ресурсов, помогает
выявлять узкие места в системе.
Среднее время ожидания кратковременной блокировки (мс)
Этот счетчик показывает среднее время ожидания блокировки для
запросов кратковременных блокировок, которым пришлось ожидать
обработки.
Ожиданий кратковременных блокировок/сек
Этот счетчик показывает число запросов кратковременных
блокировок, которые не удалось удовлетворить немедленно.
Статистика SQL
Этот объект содержит счетчики для слежения за компиляцией и
типом запросов, направляемых в экземпляр SQL Server.
Мониторинг числа компиляций и повторных компиляций, а также
число пакетов, полученных экземпляром SQL Server, позволяет
судить о том, как быстро в SQL Server обрабатываются запросы
пользователей и насколько эффективно работает оптимизатор
запросов.
Компиляций SQL/сек
Этот счетчик показывает, сколько раз в секунду вводится путь к
компилируемому коду.
Повторных компиляций SQL/сек
Этот счетчик показывает число повторных компиляций инструкции в
91
Объекты и счетчики
Описание
секунду.
Кэш планов
Этот объект содержит счетчики, позволяющие следить за тем, как в
SQL Server используется память для хранения таких объектов, как
хранимые процедуры, специальные и подготовленные инструкции
Transact-SQL и триггеры.
Коэффициент попадания в кэш
Этот счетчик показывает отношение числа успешных обращений в
кэш к числу операций поиска для планов.
Буферный кэш
Этот объект содержит счетчики, позволяющие контролировать, как в
SQL Server используется память для хранения страниц данных,
внутренних структур данных и кэша процедур, и как работает
физическая подсистема ввода-вывода при чтении и записи страниц
базы данных SQL Server.
Коэффициент попадания в буферный кэш
Этот счетчик показывает, сколько страниц (в процентах от общего
числа) было найдено в буферном кэше, что позволило не считывать
их с диска. Его значение равняется отношению общего числа
успешных обращений в кэш к общему числу операций поиска в кэше
с момента запуска экземпляра SQL Server.
Устранение узких мест
Узкие места системы — это точки конфликта, возникающие при нехватке ресурсов для обслуживания пользовательских запросов
на транзакции. Они могут быть связаны с физическим оборудованием, операционной системой или приложением. Часто
причиной узкого места является пользовательский код или сторонние решения, анализ которых может принести лучшие
результаты, чем добавление оборудования. Другой распространенной причиной узких мест является неправильная настройка
фермы или неэффективная реализация решения, когда способ структурирования данных требует больше ресурсов, чем
необходимо. Системный администратор должен справляться с узкими местами, постоянно отслеживая производительность. При
92
обнаружении проблемы, связанной с производительностью, необходимо выбрать решение, наиболее подходящее для
устранения узкого места. Счетчики производительности и другие приложения мониторинга производительности, например
System Center Operations Manager (SCOM), являются ключевыми средствами отслеживания и анализа проблем, помогающими в
разработке решения.
Устранение физического узкого места
Физические узкие места основаны на конфликтах процессора, диска, памяти и сети: при слишком большом количестве запросов
они конфликтуют из-за нехватки физических ресурсов. Описанные в разделе "Отслеживание производительности" объекты и
счетчики показывают источник проблемы производительности, например аппаратный процессор или ASP.NET. Для устранения
узкого места необходимо определить проблему и внести устраняющие ее изменения.
Проблемы редко возникают мгновенно; обычно происходит постепенное ухудшение производительности, которое можно
отследить при регулярном мониторинге с использованием средства мониторинга производительности или более сложной
системы, например SCOM. Для обоих вариантов в той или иной степени можно внедрить в предупреждение решение в виде
рекомендательного текста или подготовленных команд.
Для устранения узких мест может потребоваться изменение конфигурации оборудования или системы, если вы определили, что
проблемы не являются следствием неправильной настройки, неэффективного пользовательского кода или сторонних решений,
либо неэффективной реализации решения. В следующих таблицах представлены пороговые значения проблем и возможные
варианты их решения. Некоторые варианты предполагают обновление или изменение оборудования.
Объекты и счетчики
Проблема
Варианты решения
Процессор
Процессор — % загруженности процессора Свыше 75-85%
Обновить процессор
Увеличить число процессоров
Добавить дополнительный сервер (серверы)
Диск
Средняя длина очереди диска
Постепенное увеличение, нестабильное
Увеличить число или скорость дисков
состояние системы и копирование очереди Изменить конфигурацию массива для чередования
томов
93
Объекты и счетчики
Проблема
Варианты решения
Переместить некоторые данные на другой сервер
% времени простоя
Больше 90%
Увеличить число дисков
Переместить данные на другой диск или сервер
% свободного места
Меньше 30%
Увеличить число дисков
Переместить данные на другой диск или сервер
Память
Доступно МБ
Менее 2 ГБ на веб-сервере.
Добавить память.
Примечание.
Доступная память сервера SQL будет намеренно
недостаточной и не всегда укажет на проблему.
Ошибок кэша/сек
Больше 1
Добавить память
Увеличить скорость или размер кэша, если
возможно
Переместить данные на другой диск или сервер
Обмен страниц/сек
Больше 10
Добавить память
Файл подкачки сервера, иногда
называемый своп-файлом, хранит адреса
"виртуальной" памяти на диске. Ошибки
страниц возникают, когда выполняемый
Добавить память
Файл подкачки
% использования и пиковый %
использования
94
Объекты и счетчики
Проблема
Варианты решения
процесс должен остановиться и ждать,
пока требуемые "виртуальные" ресурсы не
загрузятся с диска в память. Они могут
возникать чаще, если физическая память
является недостаточной.
Сетевой адаптер
Всего байт/сек
Свыше 40-50% пропускной способности
Уточните причину, отследив счетчики "Получено
сети. Это скорость отправки и получения
байт/сек" и "Отправлено байт/сек".
данных через сетевую интерфейсную плату. Переоцените скорость сетевой интерфейсной
платы
Проверьте количество, размер и использование
буферов памяти
Процесс
Рабочий набор
Больше 80% общей памяти
Добавить память
% загруженности процессора
Ниже 75-85%.
Увеличить число процессоров
Перераспределить нагрузку на дополнительные
серверы
ASP.NET
Перезапуски пула приложений
Несколько в день, приводят к временному Убедитесь, что не реализованы параметры,
замедлению.
которые автоматически перезапускают пул
приложений в течение дня без необходимости.
Запросов в очереди
Сотни или тысячи запросов в очереди.
Развернуть дополнительные веб-серверы
Максимальное значение по умолчанию для этого
счетчика 5000. Этот параметр можно изменить в
95
Объекты и счетчики
Проблема
Варианты решения
файле Machine.config
Время ожидания запроса
При увеличении числа событий ожидания Развернуть дополнительные веб-серверы
пользователи будут ощущать ухудшение
производительности отображения страниц.
Отказанных запросов
Больше 0
Развернуть дополнительные веб-серверы
См. также
Понятия
Обзор управления емкостью и изменения размера для SharePoint Server 2010
Тестирование производительности для SharePoint Server 2010
Планирование емкости для SharePoint Server 2010
Планирование и настройка рабочих характеристик хранилища и SQL Server (SharePoint Server 2010)
Другие ресурсы
Health Monitoring (SharePoint Server 2010)
96
Управление мощностью SharePoint Server 2010:
ограничения, связанные с программным обеспечением
В этом документе описываются ограничения для Microsoft SharePoint Server 2010, связанные с программным обеспечением. К
ним относятся следующие:
 Границы — статические ограничения, которые конструктивно не могут быть превышены

Пороги — настраиваемые ограничения, которые могут быть превышены в соответствии с конкретными требованиями

Поддерживаемые ограничения — настраиваемые ограничения, которые по умолчанию установлены на основании
протестированных значений
Примечание.
В процессе планирования рекомендуется руководствоваться содержащейся в этом документе информацией о планировании загрузки. Эта
информация основана на результатах тестов, проведенных корпорацией Майкрософт, и полученных динамических свойствах. Однако
результаты для конкретной системы, вероятнее всего, будут отличаться от тестовых из-за различия в используемом оборудовании и
внедренных на сайтах компонентах и функциях.
Содержание:
 Обзор ограничений, связанных с программным обеспечением


Границы, пороги и поддерживаемые ограничения

Установка ограничений
Ограничения и границы

Ограничения по иерархии

Ограничения для веб-приложений
97

Ограничения для веб-сервера и сервера приложений

Ограничения для баз данных контента

Ограничения для семейств сайтов

Ограничения для списков и библиотек

Ограничения для столбцов

Ограничения для страниц

Ограничения по компонентам

Ограничения поиска

Ограничения для службы профилей пользователей

Ограничения для развертывания контента

Ограничения для блогов

Ограничения для служб Business Connectivity Services

Ограничения для рабочих процессов

Ограничения для хранилища терминов (базы данных) управляемых метаданных

Ограничения для служб Visio

Ограничения для служб PerformancePoint

Ограничения для служб автоматизации Word

Ограничения для SharePoint Workspace

Ограничения для OneNote

Ограничения для службы веб-приложений Office

Ограничения для Project Server
Обзор ограничений, связанных с программным обеспечением
В данной статье представлена информация, позволяющая лучше понять протестированные ограничения производительности и
мощности в SharePoint Server 2010, а также приведены рекомендации по взаимосвязи между ограничениями и приемлемой
производительностью. С помощью этих данных можно определить, удовлетворяет ли запланированное развертывание
98
требованиям к ограничениям производительности и мощности, а также правильно настроить соответствующие ограничения в
развертывании.
Результаты тестирования и рекомендации, представленные в данной статье, относятся к ферме с одним сервером SharePoint
Server 2010. Добавление в установку серверов не приведет к увеличению ограничений по мощности для объектов, которые
перечислены в таблицах раздела Ограничения и границы этой статьи. С другой стороны, при добавлении серверных
компьютеров увеличивается пропускная способность фермы, что может потребоваться для достижения приемлемой
производительности при наличии большого количества объектов. В некоторых случаях при необходимости использовать
большее количество объектов в рамках решения может потребоваться большее число серверов в ферме.
Обратите внимание, что существует целый ряд факторов, который может воздействовать на производительности в каждой
конкретной среде, и каждый из этих факторов влияет на производительность в различных областях. Некоторые результаты
тестирования и рекомендации в этой статье могут относиться к компонентам или действиям пользователей, которые отсутствуют
в конкретной среде и не относятся к вашему решению. Точные данные для конкретной среды можно получить только в
результате тщательного тестирования.
Границы, пороги и поддерживаемые ограничения
В SharePoint Server 2010 существуют определенные конструктивные ограничения, которые не могут быть превышены, а также
ограничения другого рода, которые получают значения по умолчанию и могут изменяться администратором фермы. Кроме того,
существуют ненастраиваемые ограничения, например, число семейств сайтов для одного веб-приложения.
 Границы представляют собой абсолютные ограничения, которые конструктивно не могут быть превышены. Важно понимать
эти ограничения, что позволит избежать ошибочных допущений на этапе проектирования фермы.
В качестве примера границы можно привести установленное на уровне 2 ГБ ограничение на размер документа. В SharePoint
Server невозможно настроить хранение документов, размер которых превышает 2 ГБ. Это абсолютное встроенное значение,
которое конструктивно не может быть превышено.
 Пороги имеют значение по умолчанию, которое не может быть превышено до тех пор, пока не будет изменено само
значение. При определенных обстоятельствах пороги могут быть превышены в целях адаптации к изменениям структуры
фермы, однако важно понимать, что это влечет за собой снижение производительности и изменение действующего значения
других ограничений.
В некоторых случаях значение порога по умолчанию может быть превышено только до достижения абсолютного
максимального значения. В качестве примера снова можно привести ограничение на размер документа. По умолчанию порог
размера документа составляет 50 МБ и при необходимости может быть изменен вплоть до максимально возможного
значения границы в 2 ГБ.
99

Поддерживаемые ограничения задают протестированные значения для указанного параметра. Значения по умолчанию для
этих ограничений были определены посредством тестирования и представляют известные ограничения для продукта.
Превышение поддерживаемых ограничений может повлечь за собой непредсказуемое поведение, существенное снижение
производительности и другие потенциально опасные эффекты.
Некоторые поддерживаемые ограничения могут настраиваться и по умолчанию получают рекомендуемые значения. Другие
же относятся к параметрам, настройка которых невозможна.
В качестве примера поддерживаемого ограничения можно привести число семейств сайтов для одного веб-приложения.
Значение поддерживаемого ограничения составляет 250 000 семейств сайтов. Это максимальное значение при котором
соблюдаются эталонные показатели производительности, достигнутые в процессе тестирования.
Важно помнить, что многие из ограничений, описываемых в этом документе, представляют собой точку на кривой, описывающей
повышение нагрузки и соответствующее ему снижение производительности. В связи с этим, превышение некоторых их
установленных ограничений, например, числа семейств сайтов для веб-приложения, повлечет за собой лишь частичное
снижение производительности фермы. Однако в большинстве случаев не рекомендуется работать с близкими к установленным
ограничениям значениями параметров, поскольку оптимальные показатели производительности и надежности достигаются при
разумном балансе между ограничениями на уровне структуры фермы.
Рекомендованные значения порогов и поддерживаемых ограничений определяются на основании производительности. Другими
словами, превышение этих ограничений возможно, однако это может повлечь за собой снижение производительности фермы и
изменение других ограничений. Многие используемые в SharePoint Server ограничения можно изменять, однако в каждом случае
следует четко представлять влияние таких изменений на другие компоненты фермы.
Установка ограничений
В SharePoint Server 2010 значения порогов и поддерживаемых ограничений устанавливаются по результатам тестирования и
наблюдения за поведением фермы при повышении нагрузки вплоть до того момента, когда достигаются эффективные рабочие
границы для служб и операций фермы. Некоторые службы и компоненты фермы могут поддерживать более высокие нагрузки,
чем другие, поэтому иногда значение ограничения устанавливается как среднее от нескольких показателей.
Например, при наблюдении за поведением фермы под нагрузкой в процессе добавления семейств сайтов работе некоторых
компонентов может наблюдаться неприемлемо высокое значение задержки, однако при этом другие компоненты будут работать
в допустимых пределах. В связи с этим устанавливаемое ограничение на максимальное число семейств сайтов не является
абсолютным и вычисляется на основе ожидаемого набора характеристик, при которых общая производительность фермы будет
приемлемой при заданных ограничениях в большинстве ситуаций.
Очевидно, что если некоторые службы работают при значениях параметров, превышающих используемые при тестировании,
максимальные эффективные ограничения для других служб снижаются. В связи с этим важно тщательно тестировать
100
возможности управления мощностью и масштабирования в каждой конкретной среде, чтобы определить эффективные
ограничения для этой среды.
Примечание. В этом документе не описывается оборудование, которое использовалось для проверки ограничений, поскольку эти
данные были получены на основе результатов для различных ферм и сред. Описание используемых для тестирования ферм
можно найти в статьях Результаты тестирования производительности и емкости и рекомендации (SharePoint Server 2010) и
Performance and capacity technical case studies (SharePoint Server 2010) (на английском языке).
Модель эквалайзера
Пороги и поддерживаемые значения концептуально можно представить в виде регуляторов на графическом эквалайзере, каждый
из которых отвечает за отдельную частоту. В этой модели увеличение значения одного из ограничений может повлечь за собой
уменьшение эффективного значения одного или нескольких других ограничений.
Допустим, один регулятор представляет максимальное число документов в библиотеке — поддерживаемое ограничение с
максимальным протестированным значением около 30 миллионов документов. Тем не менее, это значение будет зависеть от
другого регулятора, который представляет максимальный размер документов в ферме, — порог со значением по умолчанию,
равным 50 МБ.
Если увеличить максимальный размер документа до 1 ГБ, чтобы обеспечить поддержку видеофайлов и других крупных объектов,
максимальное число обрабатываемых в библиотеке документов соответствующим образом уменьшается. Например, в
конкретной конфигурации оборудования и топологии фермы может поддерживаться 1 миллион документов размером до 50 МБ.
Однако в той же ферме с тем же числом документов никогда не удастся достичь приемлемых показателей задержки и
пропускной способности, если в ней будут обрабатываться более крупные в среднем документы, для которых ограничение
размера увеличено 1 ГБ.
Размер снижения максимально допустимого числа документов в этом примере сложно спрогнозировать, поскольку он
основывается на числе крупных файлов в библиотеке, объеме содержащихся в них данных, характеристиках нагрузки на ферму,
а также доступности аппаратных ресурсов.
Ограничения и границы
В данном разделе описаны объекты, которые могут входить в решение, и содержатся указания по достижению приемлемой
производительности для каждого типа таких объектов. Под понятием "приемлемая производительность" подразумевается, что
при тестировании система может поддерживать определенное число объектов без существенного снижения производительности
или уменьшения значений связанных ограничений. Объекты перечислены по области и по компоненту. Представлены сведения
101
по ограничениям, примечания, описывающие условия, при которых получены эти ограничения, а также ссылки на
дополнительные сведения (если таковые имеются).
С помощью рекомендаций в данной статье проверьте общие планы решений. Если значения в планируемом решении
превышают представленные рекомендации по одному или нескольким объектам, выполните некоторые из указанных далее
действий:
 Оцените решение, чтобы убедиться, что в других областях потери производительности компенсированы.

Отметьте эти области для последующего тестирования и проверки по мере разработки развертывания.

Измените или разбейте на компоненты решение, чтобы убедиться, что границы рекомендаций по мощности не превышены.
Ограничения по иерархии
В этом разделе приводятся ограничения, логически упорядоченные по иерархии фермы SharePoint Server 2010.
Ограничения для веб-приложений
В следующей таблице представлено несколько рекомендаций для веб-приложений.
Ограничение
Максимальное значение
Тип ограничения
Примечания
База данных контента
300 для каждого веб-приложения
Поддерживаемое
ограничение
При 300 базах данных контента
для каждого веб-приложения
производительность
пользовательских операций,
например, открытия сайта или
семейств сайтов, не снижается.
При этом производительность
административных операций,
таких как создание нового
семейства сайтов снижается. Для
управления веб-приложением с
большим числом баз данных
контента рекомендуется
использовать Windows
102
Ограничение
Максимальное значение
Тип ограничения
Примечания
PowerShell, поскольку при
увеличении числа БД
производительность интерфейса
управления существенно
снижается, что влечет за собой
значительные задержки при
навигации.
Зона
5 для каждого веб-приложения
Граница
Количество зон для фермы жестко
ограничено пятью ("По
умолчанию", "Интрасеть",
"Интернет", "Настраиваемая" и
"Экстрасеть").
Управляемый путь
20 для каждого веб-приложения
Поддерживаемое
ограничение
Управляемые пути кэшируются на
веб-сервере. Ресурсы ЦП
расходуются на обработку
входящих запросов к списку
управляемых путей.
Если число управляемых путей
для веб-приложения превышает
20, нагрузка на веб-сервер по
обработке каждого запроса
возрастает.
Если в веб-приложении
планируется использовать более
20 управляемых путей,
рекомендуется проверить
приемлемость достигаемой при
этом производительности
103
Ограничение
Максимальное значение
Тип ограничения
Примечания
системы.
Размер кэша решений
300 МБ для каждого веб-приложения
Порог
В кэше решений служба InfoPath
хранит кэшированные решения,
что позволяет ускорить процесс их
извлечения. В случае превышения
размера кэша решения
извлекаются с диска, что влечет
увеличение времени ответа. Для
настройки размера кэша решений
можно воспользоваться
командлетом Windows
PowerShell SetSPInfoPathFormsService.
Дополнительные сведения см. в
статье SetSPInfoPathFormsService.
Ограничения для веб-сервера и сервера приложений
В следующей таблице представлено несколько рекомендаций для веб-серверов в ферме.
Ограничение
Максимальное значение
Тип ограничения
Примечания
Пулы приложений
10 для каждого веб-сервера
Поддерживаемое
ограничение
Максимальное количество
определяется
возможностями
оборудования.
Этот предел в большой
степени зависит от
104
Ограничение
Максимальное значение
Тип ограничения
Примечания
следующих факторов:

Объем ОЗУ,
выделенный для вебсерверов

Рабочая нагрузка на
ферму, то есть
размер
пользовательской
базы и модель
использования
(отдельные пулы
приложений с
высокой нагрузкой
могут требовать до 10
ГБ)
Ограничения для баз данных контента
В следующей таблице представлено несколько рекомендаций для баз данных контента.
Ограничение
Максимальное значение
Тип ограничения
Примечания
Размер базы данных контента
200 ГБ для каждой базы данных контента
Поддерживаемое
ограничение
Чтобы обеспечить
максимально возможное
быстродействие системы,
настоятельно
рекомендуется
ограничивать размер баз
данных контента до 200 ГБ.
105
Ограничение
Максимальное значение
Тип ограничения
Примечания
Базы данных контента
размером до 1 ТБ
поддерживаются только
для крупных, содержащих
один сайт, репозиториев и
архивов с раздельными
функциями ввода-ввода и
схемами использования,
таких как центры записей. В
таких сценариях
поддерживаются более
крупные базы данных,
поскольку их модели вводавывода и типовые форматы
структур данных
оптимизированы и
протестированы для
использования в
крупномасштабных
развертываниях.
Дополнительные сведения
о крупномасштабных
репозиториях документов
см. в разделе "Оценка
требований к
производительности и
мощности для
крупномасштабных
репозиториев документов"
статьи Результаты
106
Ограничение
Максимальное значение
Тип ограничения
Примечания
тестирования
производительности и
емкости и рекомендации
(SharePoint Server 2010),
а также в разделе "Типовые
сценарии управления
большими объемами
контента" статьи Enterprise
content storage planning
(SharePoint Server 2010).
Размер семейства сайтов
(если оно не единственное
в базе данных) не должен
превышать 100 ГБ.
Семейств сайтов для базы данных контента Рекомендованное количество — 2000
Максимальное количество — 5000
Поддерживаемое
ограничение
Настоятельно
рекомендуется ограничить
число семейств сайтов в
базе данных контента до
2000. Тем не менее,
поддерживается до 5000
семейств сайтов для
каждой базы данных.
Эти ограничения связаны со
скоростью обновления. Чем
большее число семейств
сайтов содержится в базе
данных, тем ниже скорость
обновления.
Ограничение числа
107
Ограничение
Максимальное значение
Тип ограничения
Примечания
семейств сайтов в базе
данных подчиняется
ограничению на размер
базы данных контента,
содержащей несколько
семейств сайтов (200 ГБ). В
связи с этим, по мере
увеличения числа семейств
в базе данных их средний
размер должен
уменьшаться.
Если число семейств сайтов
превышает 2000,
возрастает риск
длительного простоя систем
в периоды обновления.
Если планируется
превышение этого
ограничения,
рекомендуется разработать
четкую стратегию
обновления и
модернизировать
оборудование, чтобы
повысить скорость
обновления ПО для баз
данных.
Чтобы установить уровень
предупреждения для числа
108
Ограничение
Максимальное значение
Тип ограничения
Примечания
сайтов в базе данных
контента, воспользуйтесь
командлетом Windows
PowerShell SetSPContentDatabase с
параметром WarningSiteCount.
Дополнительные сведения
см. в статье SetSPContentDatabase.
Подсистема удаленного хранилища
больших двоичных объектов (RBS) на
устройстве хранения данных,
подключаемом к сети (NAS)
Время до получения первого байта любого Граница
ответа от устройства NAS не может
превышать 20 мс
Если SharePoint Server
2010 настроено на
использование RBS, и
большие двоичные объекты
хранятся на устройстве
NAS, учитывайте значение
следующей границы.
Начиная с момента
отправки запроса большого
двоичного объекта из
SharePoint Server 2010 до
получения первого байта
ответа от устройства NAS
не должно пройти более 20
мс.
109
Ограничения для семейств сайтов
В таблице далее представлено несколько рекомендаций для семейств сайтов.
Ограничение
Максимальное значение
Тип ограничения
Примечания
Веб-сайт
250 000 для каждого семейства
сайтов
Поддерживаемое
ограничение
Максимальное рекомендуемое число
сайтов и дочерних сайтов составляет
250 000.
Используя дочерние сайты, можно
создать очень большое суммарное
число веб-сайтов. Например, в
неглубокой иерархии со 100 сайтами,
для каждого из которых создано
1000 дочерних сайтов, суммарное
число сайтов составляет 100 000. В
глубокой иерархии из 100 сайтов с 10
уровнями дочерних сайтов
суммарное число сайтов также
составит 100 000.
Примечание. Удаление или создание
сайта (дочернего сайта) может
существенным образом повлиять на
доступность сайта. Доступ к сайтам
или дочерним сайтам в процессе
удаления будет ограничен. При
попытке одновременного создания
большого числа дочерних сайтов
может произойти сбой.
Размер семейства сайтов
100 ГБ для каждого семейства сайтов Поддерживаемое
110
Размер семейства сайтов (если оно не
единственное в базе данных) не
Ограничение
Максимальное значение
Тип ограничения
Примечания
ограничение
должен превышать 100 ГБ.
Некоторые действия в семействе
сайтов, например, резервное
копирование/восстановление
семейства или выполнение
командлета Windows PowerShell
Move-SPSite, сопряжены с
выполнением ресурсоемких операций
Microsoft SQL Server, что может
повлиять на производительность или
привести к недоступности других
активных семейств сайтов в той же
базе данных. Дополнительные
сведения см. в статье Move-SPSite.
Ограничения для списков и библиотек
В следующей таблице представлены рекомендации для списков и библиотек. Дополнительные сведения см. в техническом
документе "Разработка крупных списков и обеспечение максимальной производительности списка" в статье Результаты
тестирования производительности и емкости и рекомендации (SharePoint Server 2010).
Ограничение
Максимальное значение
Тип ограничения
Примечания
Размер строки списка
8000 байт для каждой
строки
Граница
Суммарный размер каждого элемента списка или
библиотеки в базе данных не может превышать 8000
байт. 256 байт зарезервировано для встроенных
столбцов, в результате чего для пользовательских
столбцов остается 7744 байта. Дополнительные сведения
о затратах пространства для каждого вида полей см. в
111
Ограничение
Максимальное значение
Тип ограничения
Примечания
разделе Ограничения для столбцов.
Размер файла
2 ГБ
Граница
Максимальный размер файла по умолчанию равен 50
МБ. При необходимости это значение можно увеличить
до 2 ГБ, однако установка большого значения может
привести к снижению производительности фермы.
Документы
30 000 000 для каждой
библиотеки
Поддерживаемое
ограничение
С помощью вложения папок, используя стандартные
представления и иерархию сайтов, можно создавать
крупные библиотеки документов. Это значение зависит от
организации документов и папок, а также от типа и
размера хранящихся документов.
Основные версии
400 000
Поддерживаемое
ограничение
Если это ограничение превышено, возможны сбои при
выполнении базовых операций с файлами (открытие,
сохранение, удаление и просмотр).
Элементы
30 000 000 для каждого
списка
Поддерживаемое
ограничение
Используя стандартные представления, иерархии сайтов
и навигацию на основе метаданных, можно создавать
очень большие списки. Это значение зависит от числа
столбцов в списке и интенсивности его использования.
Ограничение на размер
строк
6 внутренних строк таблицы Поддерживаемое
в базе данных для элемента ограничение
списка или библиотеки
112
Задает максимальное число внутренних строк таблицы в
базе данных, которые могут использоваться для элемента
списка или библиотеки. При работе с большими
списками, содержащими множество столбцов, каждый
элемент может быть разбит на несколько внутренних
строк таблицы (по умолчанию до шести строк). Это
значение настраивается администраторами фермы только
посредством объектной модели. Для этого используется
метод объектной модели
Ограничение
Максимальное значение
Тип ограничения
Примечания
SPWebApplication.MaxListItemRowStorage (Возможно,
на английском языке).
Массовые операции
100 элементов для каждой Граница
массовой операции
В пользовательском интерфейсе для каждой массовой
операции можно выбрать до 100 элементов.
Пороговое значение
8 операций объединения
подстановки представления для каждого запроса
списка
Порог
Задает максимально допустимое число объединений на
запрос, в том числе, основанных на подстановке,
пользователе или группе, либо столбцах состояния
рабочего процесса. Если в запросе используется более
восьми объединений, операция блокируется. Это не
относится к операциям с одним элементом. При
использовании максимального представления объектной
модели, в котором не заданы поля представления,
SharePoint возвращает до восьми первых подстановок.
Пороговое значение
представления списка
5000
Порог
Задает максимальное число элементов списка или
библиотеки, которые могут обрабатываться
одновременно операцией базы данных (например,
запросом), вне установленного администратором
ежедневного периода времени, в течение которого число
запросов не ограничено.
Пороговое значение
представления списка для
аудиторов и
администраторов
20 000
Порог
Задает максимальное число элементов списка или
библиотеки, которые могут обрабатываться
одновременно операцией базы данных (например,
запросом), выполняемой аудитором или
администратором с соответствующими разрешениями.
Этот параметр используется совместно с параметром
"Перезапись объектной модели".
113
Ограничение
Максимальное значение
Тип ограничения
Примечания
Дочерний сайт
2000 для каждого
представления сайта
Порог
Производительность интерфейса перечисления дочерних
сайтов определенного веб-сайта ухудшается, если общее
количество дочерних сайтов превышает 2000.
Аналогичным образом, по мере увеличения числа
дочерних сайтов существенно снижается
производительность страницы "Весь контент сайта" и
элемента управления древовидного представления.
Порог
Рекомендуемое максимальное число параллельных
редакторов равно 10. Значение границы составляет 99.
Совместное редактирование 10 параллельных
DOCX-, PPTX- и PPSXредакторов для каждого
файлов в Microsoft Word и документа
Microsoft PowerPoint
Если документ уже открыт для редактирования 99
параллельными редакторами, при попытке открыть этот
же документ каждый следующий пользователь видит
сообщение об ошибке "Файл уже используется" и может
открыть только доступную для чтения копию файла.
Совместное редактирование документа более чем 10
редакторами ведет к постепенному снижению
производительности пользовательского интерфейса,
росту числа конфликтов и увеличению числа операций по
отправке изменений.
Область безопасности
1000 для каждого списка
Порог
Максимальное число областей безопасности для каждого
списка не должно превышать 1000.
Область определяет границы безопасности для
защищаемого объекта и любых его дочерних объектов,
для которых не определена отдельная граница
безопасности. Область содержит список контроля доступа
(ACL), но, в отличие от списков контроля доступа NTFS,
может также включать участников безопасности,
относящихся к SharePoint Server. В списки контроля
114
Ограничение
Максимальное значение
Тип ограничения
Примечания
доступа для области могут входить пользователи
Windows, учетные записи других пользователей
(например, учетные записи на основе форм), а также
группы Active Directory или SharePoint.
Ограничения для столбцов
Данные SharePoint Server 2010 хранятся в таблицах SQL Server. Чтобы обеспечить создание максимального числа столбцов в
списке SharePoint, если данные не умещаются на одной строке, в SharePoint Server автоматически создается несколько строк в
базе данных. Такой способ называется переносом по строкам.
Каждая операция переноса по строкам в SQL Server сопряжена с увеличением нагрузки на сервер при запросе такого элемента,
поскольку в запрос включается оператор SQL join. Чтобы оптимизировать нагрузку, для каждого элемента SharePoint по
умолчанию устанавливается ограничение в шесть строк SQL Server. Это ограничение влечет за собой ограничение на число
столбцов каждого типа, которые можно включить в список SharePoint. В следующей таблице описываются ограничения для
каждого типа столбца.
Значение параметра переноса по строкам можно увеличить, однако это может привести к излишней нагрузке на сервер. Перед
увеличением значения этого ограничения рекомендуется провести тестирование производительности. Дополнительные
сведения см. в техническом документе "Разработка крупных списков и обеспечение максимальной производительности списка" в
статье Результаты тестирования производительности и емкости и рекомендации (SharePoint Server 2010).
Каждый тип столбца имеет размер в байтах. Сумма всех столбцов в списке SharePoint не должна превышать 8000 байт. В
зависимости от интенсивности использования столбцов ограничение в 8000 байт может достигаться раньше, чем ограничение на
перенос по строкам, равное шести строкам.
Ограничение
Максимальное значение
Тип
ограничения
Размер для каждого Примечания
столбца
Однострочный текст
276
Порог
28 байтов
115
В SQL Server перенос по строкам выполняется
через каждые 64 столбца в списке SharePoint.
Соответственно, при использовании значения по
умолчанию в списке SharePoint поддерживается
Ограничение
Максимальное значение
Тип
ограничения
Размер для каждого Примечания
столбца
до 384 однострочных текстовых столбцов (6 * 64 =
384). Однако из-за ограничения на размер
элемент списка SharePoint в 8000 байт, 256 из
которых зарезервировано для встроенных
столбцов SharePoint, фактическое ограничение
составляет 276 столбцов выбора.
Многострочный текст
192
Порог
28 байтов
В SQL Server перенос по строкам выполняется
через каждые 32 столбца в списке SharePoint.
Соответственно, при использовании значения по
умолчанию в списке SharePoint поддерживается
до 192 однострочных текстовых столбцов (6 * 32 =
192).
Столбцы выбора
276
Порог
28 байтов
В SQL Server перенос по строкам выполняется
через каждые 64 столбца в списке SharePoint.
Соответственно, при использовании значения по
умолчанию в списке SharePoint поддерживается
до 384 столбцов выбора (6 * 64 = 384). Однако изза ограничения на размер элемент списка
SharePoint в 8000 байт, 256 из которых
зарезервировано для встроенных столбцов
SharePoint, фактическое ограничение составляет
276 однострочных текстовых столбцов.
Число
72
Порог
12 байтов
В SQL Server перенос по строкам выполняется
через каждые 12 столбцов в списке SharePoint.
Соответственно, при использовании значения по
умолчанию в списке SharePoint поддерживается
до 72 числовых столбцов (6 * 12 = 72).
116
Ограничение
Максимальное значение
Тип
ограничения
Размер для каждого Примечания
столбца
Денежный
72
Порог
12 байтов
В SQL Server перенос по строкам выполняется
через каждые 12 столбцов в списке SharePoint.
Соответственно, при использовании значения по
умолчанию в списке SharePoint поддерживается
до 72 денежных столбцов (6 * 12 = 72).
Дата и время
48
Порог
12 байтов
В SQL Server перенос по строкам выполняется
через каждые 8 столбцов в списке SharePoint.
Соответственно, при использовании значения по
умолчанию в списке SharePoint поддерживается
до 48 столбцов даты и времени (6 * 8 = 48).
Подстановка
96
Порог
4 байта
В SQL Server перенос по строкам выполняется
через каждые 16 столбцов в списке SharePoint.
Соответственно, при использовании значения по
умолчанию в списке SharePoint поддерживается
до 96 однозначных столбцов подстановки (6 * 16 =
96).
Да/Нет
96
Порог
5 байтов
В SQL Server перенос по строкам выполняется
через каждые 16 столбцов в списке SharePoint.
Соответственно, при использовании значения по
умолчанию в списке SharePoint поддерживается
до 96 столбцов типа "Да/Нет" (6 * 16 = 96).
Пользователь или группа 96
Порог
4 байта
В SQL Server перенос по строкам выполняется
через каждые 16 столбцов в списке SharePoint.
Соответственно, при использовании значения по
умолчанию в списке SharePoint поддерживается
до 96 столбцов типа "Пользователь или группа" (6
117
Ограничение
Максимальное значение
Тип
ограничения
Размер для каждого Примечания
столбца
* 16 = 96).
Гиперссылки и рисунки
138
Порог
56 байтов
В SQL Server перенос по строкам выполняется
через каждые 32 столбца в списке SharePoint.
Соответственно, при использовании значения по
умолчанию в списке SharePoint поддерживается
до 192 столбцов типа "Гиперссылки и рисунки" (6 *
32 = 192). Однако из-за ограничения на размер
элемент списка SharePoint в 8000 байт, 256 из
которых зарезервировано для встроенных
столбцов SharePoint, фактическое ограничение
составляет 138 столбцов типа "Гиперссылки и
рисунки".
Вычисляемый столбец
48
Порог
28 байтов
В SQL Server перенос по строкам выполняется
через каждые 8 столбцов в списке SharePoint.
Соответственно, при использовании значения по
умолчанию в списке SharePoint поддерживается
до 48 вычисляемых столбцов (6 * 8 = 48).
GUID
6
Порог
20 байтов
В SQL Server перенос по строкам выполняется
после каждого столбца в списке SharePoint.
Соответственно, при использовании значения по
умолчанию в списке SharePoint поддерживается
до 6 столбцов GUID (6 * 1 = 6).
Int
96
Порог
4 байта
В SQL Server перенос по строкам выполняется
через каждые 16 столбцов в списке SharePoint.
Соответственно, при использовании значения по
умолчанию в списке SharePoint поддерживается
118
Ограничение
Максимальное значение
Тип
ограничения
Размер для каждого Примечания
столбца
до 96 столбцов типа Int (6 * 16 = 96).
Управляемые метаданные 94
Порог
40 байт для
первого и 32 для
каждого
последующего
Для первого добавляемого в список поля
управляемых метаданных выделяется четыре
столбца:

Поле подстановки для фактического тега

Скрытое текстовое поле для строкового
значения

Поле подстановки для захвата всех
элементов

Поле подстановки для избыточных
элементов при захвате всех элементов
Для каждого последующего добавляемого в список
поля управляемых метаданных требуется два
дополнительных столбца:

Поле подстановки для фактического тега

Скрытое текстовое поле для строкового
значения
Максимальное число столбцов управляемых
метаданных вычисляется по формуле (14 + (16 *
(n-1))), где n — это значение, определяющее
сопоставление строк (по умолчанию — 6).
Для столбцов внешних данных выделяются понятия первичного и вторичного столбца. При добавлении столбца внешних данных
можно выбрать несколько вторичных полей внешнего типа контента, которые требуется добавить в список. Например для
внешнего типа контента "Клиент" с полями "ИД", "Имя", "Страна" и "Описание" при добавлении столбца внешних данных "Клиент"
119
можно добавить вторичные поля, содержащие "ИД", "Имя", "Страна" и "Описание" клиента. Ниже приведено общее описание
доступных для добавления столбцов:
 Первичный столбец: текстовое поле.

Скрытый столбец идентификатора: многострочное текстовое поле.

Вторичные столбцы: каждый вторичный столбец может быть текстовым, числовым, логическим или многострочным
текстовым столбцом на основе типа данных, который определен для этого вторичного столбца в модели каталога бизнесданных. Например, идентификатор может сопоставляться со столбцом Число; имя может сопоставляться со столбцом
Однострочный текст; описание — со столбцом Многострочный текст.
Ограничения для страниц
В следующей таблице представлено несколько рекомендаций для страниц.
Ограничение
Максимальное значение
Тип ограничения
Веб-части
25 для каждой вики-страницы или страницы с Порог
веб-частями
Примечания
Данная цифра получена на
основе оценки простых
веб-частей. Количество
веб-частей, которое не
оказывает влияние на
производительность,
зависит от сложности этих
веб-частей.
Ограничения безопасности
Ограничение
Максимальное значение
Тип ограничения
Примечания
Число групп SharePoint, к которым
принадлежит пользователь
5000
Поддерживаемое
ограничение
Это ограничение не
задается жестко, однако
устанавливается в
120
Ограничение
Максимальное значение
Тип ограничения
Примечания
соответствии с
рекомендациями для
Active Directory. Это
значение зависит от
нескольких факторов:
121

Размер маркера
пользователя

Кэш групп: в
SharePoint Server
2010 используется
таблица, в которой
кэшируется число
групп, которым
принадлежит
пользователь до тех
пор, пока эти группы
используются в
списках контроля
доступа (ACL).

Время проверки
безопасности: по
мере увеличения
числа групп, в
которых участвует
пользователь, время,
затрачиваемое на
проверку
доступности,
увеличивается
Ограничение
Максимальное значение
Тип ограничения
Примечания
соответствующим
образом.
Число пользователей в семействе сайтов
2 миллиона для каждого семейства сайтов Поддерживаемое
ограничение
С помощью групп
безопасности Microsoft
Windows, которые
позволяют не управлять
пользователями по
отдельности, к веб-сайту
можно добавить миллионы
пользователей.
Это ограничение связано с
эффективностью
управления и простотой
навигации в
пользовательском
интерфейсе.
При наличии множества
элементов (группы
безопасности или
пользователи) в семействе
сайтов (более тысячи) для
управления
пользователями вместо
пользовательского
интерфейса рекомендуется
применять Windows
PowerShell. Это позволяет
повысить эффективность
122
Ограничение
Максимальное значение
Тип ограничения
Примечания
управления.
Число участников/пользователей Active
Directory в группе SharePoint
5000 для каждой группы SharePoint
Поддерживаемое
ограничение
В SharePoint Server 2010
поддерживается
добавление пользователей
и групп Active Directory в
группу SharePoint.
Если число пользователей
или групп Active Directory
не превышает 5000,
обеспечивается
приемлемая
производительность группы
SharePoint.
Это ограничение в большей
степени влияет на
производительность
следующих операций:
123

Извлечение
пользователей для
проверки
разрешений.
Длительность
выполнения этой
операции возрастает
пропорционально
числу пользователей
в группе.

Отображение
Ограничение
Максимальное значение
Тип ограничения
Примечания
сведений об участии
в группе. Выполнение
этой операции во
всех случаях требует
времени.
Группы SharePoint
10 000 для каждого семейства сайтов
Поддерживаемое
ограничение
При наличии более 10 000
групп время выполнения
операций существенно
увеличивается. Это в
большей степени относится
к операциям добавления
пользователей в
существующую группу,
создания новой группы или
отображения
представлений группы.
Участник безопасности: размер области
безопасности
5000 для каждого списка контроля доступа Поддерживаемое
(ACL)
ограничение
Размер области влияет на
данные, используемые для
вычисления проверки
безопасности, которое
выполняется при каждом
изменении области.
Жесткое ограничение не
устанавливается, однако
продолжительность
вычисления возрастает
пропорционально размеру
области.
124
Ограничения по компонентам
В этом разделе ограничения отсортированы по компонентам.
Ограничения поиска
В следующей таблице представлено несколько рекомендаций для поиска.
Ограничение
Максимальное значение
Тип ограничения
Примечания
Приложения-службы поиска 20 для каждой фермы
SharePoint
Поддерживаемое
ограничение
В одной ферме можно
развертывать несколько
приложений-служб SharePoint,
поскольку компоненты и базы
данных поиска можно назначать
разным серверам. Рекомендуемое
ограничение, равное 20, меньше
максимального ограничения для
любых других приложений-служб в
ферме.
Базы данных обхода
контента и элементы баз
данных
Порог
В базе данных обхода контента
хранятся данные обхода контента
(время, состояние и т. д.) для всех
элементов, для которых выполнен
обход. Поддерживаемое
ограничение составляет 10 баз
данных обхода контента для
каждого приложения-службы
поиска SharePoint.
10 баз данных обхода контента для каждого
приложения-службы поиска
25 миллионов элементов для каждой базы данных
обхода контента
Рекомендуемое ограничение
составляет 25 миллионов
125
Ограничение
Максимальное значение
Тип ограничения
Примечания
элементов для каждой базы
данных обхода контента (или всего
четыре базы данных обхода
контента для каждого
приложения-службы поиска).
Компоненты обхода
контента
16 для каждого приложения-службы поиска
Порог
Рекомендуемое ограничение для
каждого приложения составляет
16 компонентов обхода контента
(по два на каждую базу данных
обхода и по два на каждый сервер
с учетом того, что сервер должен
иметь как минимум восемь
процессоров или ядер).
Для минимального
распространения ухудшений в
производительности системы
ввода-вывода общее число
компонентов обхода контента для
каждого сервера не должно
превышать значения,
вычисляемого по формуле
128/(общее число компонентов
запроса). Превышение
рекомендуемого ограничения не
обязательно приведет к росту
производительности обхода
контента. В действительности,
производительность обхода
контента может уменьшиться в
126
Ограничение
Максимальное значение
Тип ограничения
Примечания
соответствии с наличием
доступных ресурсов на сервере
обхода контента и на узле, либо в
базе данных.
Разделы индекса
20 для каждого приложения-службы поиска; всего Порог
128
Индексированные элементы 100 миллионов для каждого приложения-службы Поддерживаемое
поиска; 10 миллионов для каждого раздела
ограничение
индекса
127
Раздел индекса содержит
подмножество индекса
приложения-службы поиска.
Рекомендуемое ограничение
составляет 20. В результате
увеличения числа разделов
индекса приведет к тому, что
каждый радел будет содержать
меньшее подмножество индекса.
Это, в свою очередь, повлечет
сокращение объема ОЗУ и
дискового пространства,
выделяемого на сервере запросов,
на котором размещается
компонент запроса, назначенный
разделу индекса. Значение
границы, определяющее общее
число разделов индекса,
составляет 128.
Служба поиска SharePoint
поддерживает разделы индекса,
каждый из которых содержит
подмножество индекса поиска.
Рекомендуемый максимум
составляет 10 миллионов
Ограничение
Максимальное значение
Тип ограничения
Примечания
элементов для каждого раздела.
Рекомендуемый максимум для
общего числа элементов
(пользователи, элементы списка,
документы, веб-страницы)
составляет 100 миллионов.
Записи журнала обхода
контента
100 миллионов для каждого приложения поиска
Базы данных свойств
10 для каждого приложения-службы поиска; всего Порог
128
В базе данных свойств хранятся
метаданные для элементов в
каждом связанном разделе
индекса. Раздел индекса может
быть связан только с одним
хранилищем свойств.
Рекомендуемое ограничение
составляет 10 баз данных свойств
для каждого приложения-службы
поиска. Значение границы для
разделов индекса составляет 128.
Компоненты запроса
128 для каждого приложения поиска; 64/(общее Порог
число компонентов обхода контента) для каждого
сервера
Общее число компонентов запроса
ограничивается возможностями
компонентов обхода контента по
копированию файлов.
Максимальное число компонентов
запроса для каждого сервера
128
Поддерживаемое
ограничение
Задает число отдельных записей в
журнале обхода контента.
Определяется в соответствии с
ограничением на число
индексированных элементов.
Ограничение
Максимальное значение
Тип ограничения
Примечания
ограничивается возможностями
компонентов запроса по приему
файлов, распространяемых из
компонентов обхода контента.
Правила области
100 правил для каждой области; всего 600 правил Порог
для каждого приложения-службы поиска
Превышение этого ограничения
повлечет за собой уменьшение
актуальности обхода контента и
задержку возврата потенциальных
результатов из запросов с
заданной областью.
Области
200 для каждого сайта
Порог
Это рекомендуемое ограничение
для каждого сайта. Превышение
этого ограничения может привести
к снижению эффективности обхода
контента и, в случае добавления
областей в группу отображения, к
изменению задержки в браузере
конечного пользователя. Также по
мере превышения
рекомендуемого ограничения на
число областей снижается
производительность при
отображении областей в
интерфейсе администрирования
поиска.
Группы отображения
25 для каждого сайта
Порог
Группы отображения служат для
отображения областей в группах
через пользовательский
129
Ограничение
Максимальное значение
Тип ограничения
Примечания
интерфейс. Превышение
установленного ограничения
приведет к снижению
эффективности поиска в
интерфейсе администрирования
поиска.
Оповещения
1 000 000 для каждого приложения поиска
Поддерживаемое
ограничение
Это проверенное ограничение.
Источники контента
50 для каждого приложения-службы поиска
Порог
Рекомендуемое ограничение в 50
источников может быть
превышено вплоть до значения
границы, которое составляет 500
источников контента для каждого
приложения-службы поиска. Тем
не менее, при этом следует
использовать меньшее число
начальных адресов и соблюдать
ограничение числа параллельных
обходов контента.
Начальные адреса
100 для каждого источника контента
Порог
Рекомендуемое ограничение
может быть превышено вплоть до
значения границы, которое
составляет 500 для каждого
источника контента. Однако с
увеличением числа начальных
адресов пропорционально
сокращается число доступных для
использования источников
130
Ограничение
Максимальное значение
Тип ограничения
Примечания
контента. Если используется
большое число начальных адресов,
рекомендуется задать их в виде
ссылок на HTML-странице и
выполнить обход HTTP-контента
страницы по этим ссылкам.
Число параллельных
обходов контента
20 для каждого приложения поиска
Порог
Число одновременно
выполняемых обходов контента.
Превышение этого ограничения
может привести к сокращению
общей скорости обхода контента.
Свойства для обхода
500 000 для каждого приложения поиска
Поддерживаемое
ограничение
Свойства, которые будут
обнаруживаться в процессе обхода
контента.
Правила воздействия
программы-обходчика
100
Порог
Рекомендуемое ограничение
составляет 100 для каждой фермы
и при необходимости может быть
превышено. Однако это может
привести к снижению
производительности правил сбора
данных для сайтов в интерфейсе
администрирования поиска. При
наличии примерно 2000 таких
правил страница управления
правилами сбора данных для сайта
становится недоступной для
чтения.
131
Ограничение
Максимальное значение
Тип ограничения
Примечания
Правила обхода контента
100 для каждого приложения-службы поиска
Порог
Это значение может быть
превышено, однако это может
привести к снижению
производительности правил
обхода контента в интерфейсе
администрирования поиска.
Управляемые свойства
100 000 для каждого приложения-службы поиска Порог
Это свойства, используемые
поисковой системой в запросах.
Свойства для обхода
сопоставляются с управляемыми
свойствами.
Сопоставления
100 для каждого управляемого свойства
Порог
Превышение этого ограничения
может привести к снижению
скорости обхода контента и
производительности запросов.
Удаление URL-адресов
100 для каждой операции
Поддерживаемое
ограничение
Это рекомендуемое максимальное
количество URL-адресов, которое
следует удалять из системы за
одну операцию.
Достоверные страницы
1 страница верхнего уровня и минимальное число Порог
страниц второго и третьего уровня для каждого
приложения-службы поиска
Рекомендуемое ограничение —
одна достоверная страница
верхнего уровня и минимально
необходимое для обеспечения
релевантности число страниц
второго и третьего уровня.
Значение границы составляет 200
на уровень релевантности для
132
Ограничение
Максимальное значение
Тип ограничения
Примечания
каждого приложения поиска,
однако добавление
дополнительных страниц может
привести к снижению
релевантности. Добавьте ключевой
сайт на первый уровень
релевантности. При
необходимости по одному
добавляйте дополнительные
ключевые сайты на второй или
третий уровень релевантности и
оценивайте релевантность после
каждой операции добавления,
чтобы гарантировать достижение
нужной релевантности.
Ключевые слова
200 для каждого семейства сайтов
Поддерживаемое
ограничение
133
Рекомендуемое ограничение
может быть превышено вплоть до
максимального ограничения в
5000 для каждого семейства
сайтов (задается в ASP.NET) при
использовании пяти наиболее
подходящих элементов на
ключевое слово. Если это
ограничение превышено,
производительность отображения
ключевых слов в пользовательском
интерфейсе администрирования
сайта при превышении этого
ограничения будет ухудшаться.
Ограничение
Максимальное значение
Тип ограничения
Примечания
Устанавливаемое в ASP.NET
ограничение может быть изменено
посредством изменения файлов
Web.Config и Client.config
(MaxItemsInObjectGraph).
Распознанные свойства
метаданных
10 000 на каждый элемент, для которого
выполнен обход контента
Граница
Число свойств метаданных,
которые могут быть определены и
потенциально сопоставлены или
использованы для запросов при
обходе контента элементов.
Ограничения для службы профилей пользователей
В следующей таблице представлено несколько рекомендаций для служб профилей пользователей.
Ограничение
Максимальное значение
Тип ограничения
Профили пользователей
2 000 000 для каждого приложения-службы Поддерживаемое
ограничение
134
Примечания
Приложение-служба
профилей пользователей
поддерживает до 2
миллионов профилей
пользователей с
полноценными
возможностями
социальных компонентов.
Это число представляет
число профилей, которые
могут импортироваться в
хранилище профилей
Ограничение
Максимальное значение
Тип ограничения
Примечания
пользователей из службы
каталогов, а также число
профилей, которое может
поддерживаться
приложением-службой
профилей пользователей
без снижения
производительности
социальных компонентов.
Социальные теги, заметки и оценки
500 000 000 для каждой базы данных
контента социального контента
Поддерживаемое
ограничение
Ограничения для развертывания контента
В следующей таблице представлено несколько рекомендаций для развертывания контента.
135
В базе данных социального
контента поддерживается
до 500 миллионов
социальных тегов, заметок
и оценок без
существенного снижения
производительности.
Однако при этом возможно
уменьшение
производительности
операций обслуживания
базы данных, таких как
резервное копирование и
восстановление.
Ограничение
Максимальное значение
Тип ограничения
Примечания
Число выполняемых заданий
развертывания контента с
разными путями
20
Поддерживаемое
ограничение
Для заданий, которые выполняются параллельно
по путям, подключенным к семействам сайтов в
той же исходной базе данных контента, существует
повышенный риск возникновения
взаимоблокировок базы данных. Для заданий,
которые должны выполняться параллельно,
рекомендуется перемещать семейства сайтов в
разные исходные базы данных контента.
Примечание.
Параллельное выполнение заданий по одному
пути невозможно.
Если для развертывания контента используются
моментальные снимки SQL Server, снимок
создается для каждого пути. Это влечет за собой
рост требований к производительности систем
ввода-вывода для исходной базы данных.
Дополнительные сведения см. в статье Пути и
задания развертывания.
Ограничения для блогов
В следующей таблице представлено несколько рекомендаций для блогов.
136
Ограничение
Максимальное значение
Тип ограничения
Примечания
Записи блогов
5000 для каждого сайта
Поддерживаемое
ограничение
Максимальное
число записей
блогов для
каждого сайта
составляет 5000.
Комментарии
1000 для каждой записи
Поддерживаемое
ограничение
Максимальное
число
комментариев для
каждой записи
составляет 1000.
Ограничения для служб Business Connectivity Services
В следующей таблице представлено несколько рекомендаций для служб Business Connectivity Services.
Ограничение
Максимальное значение
Тип ограничения
Примечания
Внешние типы контента (в памяти)
5000 для каждого веб-сервера (на владельца)
Граница
Общее число
определений
внешнего типа
контента (ECT),
загруженных в
память веб-сервера
на заданный
момент времени.
Подключения к внешним системам
500 для каждого веб-сервера
Граница
Число активных
(открытых)
подключений к
137
Ограничение
Максимальное значение
Тип ограничения
Примечания
внешним системам
на заданный
момент времени.
Максимальное по
умолчанию — 200.
Значение границы
— 500. Это
ограничение
принудительно
применяется в
области вебсервера
независимо от вида
внешней системы
(например, база
данных, сборка
.NET и т. д.).
Максимальное
значение по
умолчанию
ограничивает число
подключений. С
помощью контекста
выполнения в
приложении можно
задать более
высокое
ограничение.
Значение границы
принудительно
138
Ограничение
Максимальное значение
Тип ограничения
Примечания
ограничивает
максимально
возможное число
подключений даже
для тех
приложений, в
которых не
используются
параметры по
умолчанию.
Число элементов базы данных, возвращаемое
для каждого запроса
2000 для каждого средства подключения к базе Порог
данных
Число элементов,
которые может
вернуть средство
подключения к
базе данных для
каждого запроса.
Установленное по
умолчанию
значение 2000
ограничивает число
результатов,
которые могут быть
возвращены для
каждой страницы.
С помощью
контекста
выполнения для
приложения можно
задать более
139
Ограничение
Максимальное значение
Тип ограничения
Примечания
высокое
ограничение.
Параметр
абсолютного
максимума
ограничивает
возвращаемое
число элементов
даже для тех
приложений, в
которых не
используется
значение по
умолчанию.
Значение границы
составляет
1 000 000.
Ограничения для рабочих процессов
В следующей таблице представлено несколько рекомендаций для рабочих процессов.
Ограничение
Максимальное значение
Тип ограничения
Примечания
Порог отсрочки рабочего процесса
15
Порог
Значение 15
определяет
максимальное число
рабочих процессов,
которые могут
140
Ограничение
Максимальное значение
Тип ограничения
Примечания
одновременно
выполняться в
отношении одной
базы данных
контента, за
исключением
экземпляров, которые
выполняются в
службе таймера. При
достижении
порогового значения
новые запросы на
активацию рабочих
процессов
помещаются в
очередь и
выполняются службой
таймера рабочих
процессов позднее.
Если выполняемые не
службой таймера
рабочие процессы
завершаются, новые
запросе учитываются
при определении
этого значения. Для
настройки этого
ограничения можно
использовать
командлет Set141
Ограничение
Максимальное значение
Тип ограничения
Примечания
SPFarmConfig
Windows PowerShell.
Дополнительные
сведения см. в статье
Set-SPFarmConfig.
Примечание. Это
ограничение не
относится к общему
числу экземпляров
рабочих процессов,
которые могут
выполняться, и
определяет только
находящиеся в
обработке
экземпляры.
Повышение этого
ограничения повлечет
за собой повышение
пропускной
способности задач
запуска и завершения
рабочих процессов,
однако также
приведет к росту
нагрузки на базу
данных контента и
системные ресурсы.
Размер пакета таймера рабочих процессов
Порог
100
142
Число событий,
Ограничение
Максимальное значение
Тип ограничения
Примечания
обнаруживаемых и
передаваемых в
рабочие процессы при
каждом выполнении
задания таймера
рабочих процессов.
Для настройки этого
ограничения можно
использовать
оболочку Windows
PowerShell. Чтобы
реализовать
обработку
дополнительных
событий, необходимо
запустить
дополнительные
экземпляры службы
таймера рабочих
процессов Microsoft
SharePoint
Foundation.
Ограничения для хранилища терминов (базы данных) управляемых метаданных
В следующей таблице представлено несколько рекомендаций для хранилищ терминов управляемых метаданных.
143
Ограничение
Максимальное значение
Тип ограничения
Примечания
Максимальное число уровней
вложенных элементов в
хранилище терминов
7
Поддерживаемое
ограничение
Термины в наборе могут быть представлены в
иерархической структуре. В наборе терминов
поддерживается до семи уровней терминов
(родительский и шесть уровней дочерних).
Максимальное число наборов
терминов в хранилище
терминов
1000
Поддерживаемое
ограничение
В хранилище терминов поддерживается до 1000
наборов терминов.
Поддерживаемое
ограничение
Максимальное число терминов в наборе терминов
— 30 000.
Максимальное число терминов 30 000
в наборе терминов
Примечание.
Дополнительные метки для одного и того же
термина, например, синонимы, не учитываются
как отдельные термины.
Общее число элементов в
хранилище терминов
1 000 000
Поддерживаемое
ограничение
В качестве элементов учитываются термины и
наборы терминов. Совокупное число терминов и
наборов терминов не может превышать 1 000 000.
Дополнительные метки для одного и того же
термина, например, синонимы, не учитываются
как отдельные термины.
Примечание.
В хранилище не может одновременно
присутствовать максимальное число наборов
144
Ограничение
Максимальное значение
Тип ограничения
Примечания
терминов и терминов.
Ограничения для служб Visio
В следующей таблице представлено несколько рекомендаций для экземпляров Visio Services в Microsoft SharePoint Server 2010.
Ограничение
Максимальное значение
Размер файла веб-документа Visio 50 МБ
Тип
ограничения
Примечания
Порог
С помощью этого параметра в Visio Services
администратор может изменять максимально
допустимый размер веб-документов для
обработки в Visio.
Увеличение размера файла влечет за собой
приведенные ниже последствия:
Время ожидания повторного
вычисления веб-документа Visio
120 с
Порог
145

Увеличение объема занимаемой памяти в
Visio Services.

Увеличение загрузки ЦП.

Сокращение числа запросов сервера
приложений в секунду.

Увеличение общей задержки.

Увеличение общей сетевой нагрузки на
ферму SharePoint.
С помощью этого параметра в Visio Services
администратор может изменять максимально
допустимое время ожидания для повторного
Ограничение
Максимальное значение
Тип
ограничения
Примечания
вычисления веб-документа после обновления
данных.
Увеличение времени ожидания для повторного
вычисления влечет за собой приведенные ниже
последствия:

Сокращение уровня доступности ЦП и
памяти.

Сокращение числа запросов приложения в
секунду.

Увеличение средней величины задержки
для всех документов.
Сокращение времени ожидания для повторного
вычисления влечет за собой приведенные ниже
последствия:
Минимальный срок хранения в
кэше Visio Services (схемы с
подключением к данным)
Минимальный срок хранения в
кэше: от 0 до 24 ч
Порог

Сокращение сложности поддерживаемых
для отображения диаграмм.

Увеличение числа запросов в секунду.

Сокращение средней величины задержки
для всех документов.
Минимальный срок хранения в кэше применяется
ко всем схемам с подключением к данным. Это
значение определяет самый ранний момент
времени, в который текущая схема удаляется из
кэша.
Если установить слишком низкое значение этого
параметра, это приведет к сокращению
146
Ограничение
Максимальное значение
Тип
ограничения
Примечания
пропускной способности и увеличению задержки,
поскольку слишком частая очистка кэша приводит
к росту числа вычислений в Visio и снижает
уровень доступности ЦП и памяти.
Максимальный срок хранения в
кэше Visio Services (схемы без
подключения к данным)
Максимальный срок хранения в
кэше: от 0 до 24 ч
Порог
Максимальный срок хранения в кэше применяется
ко всем схемам без подключением к данным. Это
значение определяет продолжительность хранения
текущей схемы в памяти.
При увеличении значения этого параметра
снижается задержка для часто запрашиваемых
документов.
Однако слишком большое значение
максимального срока хранения в кэше влечет за
собой увеличение задержки и снижение
пропускной способности для элементов,
кэширование которых не выполняется, поскольку
присутствующие в кэше элементы потребляют
доступную память.
Ограничения для служб PerformancePoint
В следующей таблице перечислены рекомендации для PerformancePoint Services в Microsoft SharePoint Server 2010.
147
Ограничение
Максимальное значение
Тип ограничения
Примечания
Ячейки
1 000 000 для каждого запроса к источнику
данных Excel
Граница
На систему показателей
PerformancePoint,
вызывающую источник
данных Excel,
распространяется
ограничение в 1 000 000
на каждый запрос.
Столбцы и строки
15 столбцов по 60 000 строк
Порог
Максимальное число
столбцов и строк при
отображении любого
объекта панели
мониторинга
PerformancePoint, в
котором в качестве
источника данных
используется рабочая
книга Microsoft Excel.
Число строк может
изменяться в
соответствии с числом
столбцов.
Запрос к списку SharePoint
15 столбцов по 5000 строк
Поддерживаемое
ограничение
Максимальное число
столбцов и строк при
отображении любого
объекта панели
мониторинга
PerformancePoint, в
котором в качестве
148
Ограничение
Максимальное значение
Тип ограничения
Примечания
источника данных
используется список
SharePoint. Число строк
может изменяться в
соответствии с числом
столбцов.
Запрос к источнику данных SQL Server
15 столбцов по 20000 строк
Поддерживаемое
ограничение
Максимальное число
столбцов и строк при
отображении любого
объекта панели
мониторинга
PerformancePoint, в
котором в качестве
источника данных
используется таблица
SQL Server. Число
строк может изменяться
в соответствии с числом
столбцов.
Ограничения для служб автоматизации Word
В следующей таблице представлено несколько рекомендаций для служб автоматизации Word.
Ограничение
Максимальное значение
Тип ограничения
Примечания
Размер входного файла
512 МБ
Граница
Максимально допустимый размер файла для
обработки в службах автоматизации Word.
149
Ограничение
Максимальное значение
Тип ограничения
Примечания
Частота запуска
преобразований (мин.)
1 мин. (рекомендуется)
Порог
Это значение определяет частоту выполнения
задания таймера служб автоматизации Word.
Слишком низкое значение влечет за собой более
быстрое выполнение заданий. По результатам
тестирования оптимальным является выполнение
задания таймера один раз в минуту.
Число запускаемых
преобразований для одного
процесса преобразования
Для форматов вывода
Порог
PDF/XPS: 30 x МДля всех
других форматов вывода: 72 x
М Здесь М — значение частоты
запуска преобразований в
минутах
Число запускаемых преобразований влияет на
пропускную способность служб автоматизации
Word.
Если установлено превышающее рекомендуемое
значение, возможны периодические сбои для
некоторых элементов преобразования, а также
истечение срока действия разрешений
пользователя. Срок действия разрешений
пользователя истекает спустя 24 часа с момента
запуска задания преобразования.
Размер задания
преобразования
100 000 элементов
преобразования
Задание преобразования может содержать один
или несколько элементов преобразования, каждый
из которых представляет отдельное
преобразование, выполняемое с отдельным
входным файлом в SharePoint. При запуске
задания преобразования (с использованием
метода ConversionJob.Start) само задание и все
его элементы передаются на сервер приложений,
где задание хранится в базе данных служб
автоматизации Word. Слишком большое число
элементов преобразования может привести к
увеличению времени выполнения метода Start, а
15 мин. (по умолчанию)
59 мин. (граница)
Поддерживаемое
ограничение
150
Ограничение
Максимальное значение
Тип ограничения
Примечания
также к росту объемов передаваемых на сервер
приложений данных.
Общее число активных
процессов преобразования
N-1, где N — число ядер на
каждом из серверов
приложений
Порог
Активный процесс преобразования может
занимать ресурсы одного ядра обработки. В связи
с этим максимальное число процессов
преобразования не должно превышать числа ядер
обработки на серверах приложений. Задания
таймера преобразования и другие операции
SharePoint также периодически используют ядро
обработки.
Рекомендуется всегда оставлять одно свободное
ядро, которое будет использоваться заданиями
таймера преобразования или приложением
SharePoint.
Размер базы данных служб
автоматизации Word
2 миллиона элементов
преобразования
Поддерживаемое
ограничение
В базе данных служб автоматизации Word
хранится постоянная очередь элементов
преобразования. Для каждого запроса на
преобразование создается одна или несколько
записей.
Службы автоматизации Word не поддерживают
автоматическое удаление записей из базы данных,
поэтому при отсутствии обслуживания ее размер
может увеличиваться до бесконечности.
Администраторы могут вручную удалять журнал
заданий преобразования с помощью командлета
Windows PowerShell RemoveSPWordConversionServiceJobHistory.
Дополнительные сведения см. в статье Remove-
151
Ограничение
Максимальное значение
Тип ограничения
Примечания
SPWordConversionServiceJobHistory.
Ограничения для SharePoint Workspace
В следующей таблице перечислены рекомендации для Microsoft SharePoint Workspace 2010.
Ограничение
Максимальное значение
Тип ограничения
Примечания
Синхронизация SharePoint Workspace
30 000 для каждого списка
Граница
В SharePoint
Workspace не
поддерживается
синхронизация
списков, содержащих
более 30 000
элементов. Это
ограничение связано с
тем, что длительность
загрузки такого списка
и объем используемых
при этом ресурсов
имеют слишком
высокое значение.
Синхронизация SharePoint Workspace
1800 документов в SharePoint Workspace
Граница
При наличии более
500 документов в
SharePoint
Workspace
отображается
предупреждение,
однако добавление
152
Ограничение
Максимальное значение
Тип ограничения
Примечания
документов попрежнему
поддерживается.
Ограничения для OneNote
В следующей таблице перечислены рекомендации для служб Microsoft OneNote.
Ограничение
Максимальное значение
Тип
ограничения
Примечания
Число разделов и групп разделов в
См. ограничения на число документов для
записной книжке OneNote (в SharePoint) списка и библиотеки
Каждый раздел учитывается в списке
как одна папка и один документ.
Каждая группа разделов учитывается в
списке как одна папка и один
документ.
Максимальный раздел документа
В соответствии с этим ограничением
для OneNote исключаются
изображения, внедренные файлы и
распечатки XPS, размер которых
превышает 100 КБ. Изображения и
внедренные файлы размером более
100 КБ разбиваются на отдельные
двоичные файлы. Это означает, что
раздел, содержащий 100 КБ
типизированных данных и четыре
внедренных документа Word
размеров по 1 МБ каждый, будет
учитываться как раздел размером в
Ограничение для параметра "Размер
файла" см. в ограничениях для списков и
библиотек
153
Ограничение
Максимальное значение
Тип
ограничения
Примечания
100 КБ.
Максимальный размер изображения,
Ограничение для параметра "Размер
внедренного файла и распечатки XPS для файла" см. в ограничениях для списков и
OneNote в разделе OneNote.
библиотек
Каждый элемент хранится в
отдельном двоичном файле и,
соответственно, подчиняется
ограничениям на размер файлов.
Каждая операция печати в OneNote
приводит к созданию одного файла
распечатки XPS, даже если
распечатка содержит несколько
страниц.
Максимальный размер всех изображений, По умолчанию это значение вдвое
Порог
внедренных файлов и распечаток XPS на превышает ограничение "Размер файла".
одной странице OneNote.
Применяется к внедренному контенту
на отдельной странице OneNote, а не
к разделу или записной книжке. При
превышении этого ограничения
отображается сообщение об ошибке
OneNote:
jerrcStorageUrl_HotTableFull
(0xE0000794). Чтобы обойти эту
ошибку, можно разбить внедренный
контент на разные страницы и удалить
предыдущую версию страницы. Если
пользователи изменяют это значение
("Максимальный размер таблицы
горячего резервирования"),
эффективное ограничение составляет
половину от устанавливаемого
абсолютного значения. Например,
если устанавливается размер таблицы
154
Ограничение
Максимальное значение
Тип
ограничения
Примечания
горячего резервирования, равный 400
МБ, максимальный размер всего
внедренного контента на странице
будет ограничен 200 МБ.
Операции объединения
Одна на ядро ЦП для каждого вебсервера
Граница
С помощью операций объединения в
OneNote объединяются изменения,
внесенные несколькими
пользователями в записную книжку в
процессе совместного
редактирования. Если отсутствуют
свободные ядра ЦП для выполнения
объединения, создается страница
конфликта, на которой запрашивается
принудительное выполнение
объединения пользователем вручную.
Это ограничение применяется
независимо от того, выполняется ли
OneNote в качестве клиентского
приложения или в качестве вебприложения Microsoft Office Web
Apps.
Ограничения для службы веб-приложений Office
В следующей таблице перечислены рекомендации для Office Web Apps. Если приложение выполняется в качестве вебприложения, также применяются ограничения, распространяющиеся на клиентские приложения Office.
155
Ограничение
Максимальное значение
Тип ограничения
Примечания
Размер кэша
100 ГБ
Порог
Пространство,
доступное для
отображения
документов,
создаваемое в
составе базы данных
контента. По
умолчанию
устанавливается
размер кэша для
отображения
документов, равный
100 ГБ. Увеличивать
это ограничение не
рекомендуется.
Отображения
Одно в секунду для каждого документа для
ядра ЦП на каждый сервер приложений
(максимум восемь ядер)
Граница
Это измеренное
среднее число
отображений
"типовых"
документов,
которые могут быть
выполнены на
каждом сервере
приложений за
период времени.
156
Ограничения для Project Server
В следующей таблице перечислены рекомендации для Microsoft Project Server. Дополнительные сведения о планировании для
Project Server см. в статье Planning and architecture for Project Server 2010.
Ограничение
Максимальное значение
Тип ограничения
Примечания
Время окончания проекта
Дата: 31.12.2049
Граница
Дата окончания
любых планов в
Project ограничена
31.12.2049.
Конечные результаты для каждого плана
проекта
1500 конечных результатов
Граница
Планы Project не
могут содержать
более 1500
конечных
результатов.
Число полей в представлении
256
Граница
Максимальное
число полей,
добавляемых в
определенное
пользователем
представление в
Project Web App,
составляет 256.
Число операторов в фильтре представления
50
Граница
Максимальное
число операторов в
фильтре,
добавляемом в
представление,
составляет 50.
157
Performance and capacity technical case studies (SharePoint
Server 2010) (на английском языке)
This section contains technical case studies that describe specific deployments of Microsoft SharePoint Server 2010. Compare the
scenarios in these documents to your planned workload and usage characteristics. If your planned design is similar, you can use the
documented deployment as a starting point for your own installation.
These articles include information about environments, such as:
 Environment specifications, such as hardware, farm topology, and configuration

The workload used for data generation, including the number and class of users, and farm usage characteristics

Farm dataset, including database contents, Search indexes, and external data sources

Health and performance data specific to the environment

Performance data and recommendations for how to determine the hardware, topology, and configuration you need to deploy a similar
environment, and how to optimize your environment for appropriate capacity and performance characteristics
Before reading these articles, it is important that you understand the key concepts behind capacity management in SharePoint Server
2010. For more information, see Capacity management and sizing for SharePoint Server 2010 (на английском языке).
In this section:
 Publishing


Среда публикации корпоративной интрасети Microsoft SharePoint Server 2010: пример технического внедрения
Describes the published intranet environment used by employees at Microsoft.
Enterprise Intranet Collaboration


Enterprise intranet collaboration environment technical case study (SharePoint Server 2010) (на английском языке)
Describes an environment that hosts mission-critical team sites and publishing portals for internal organizations, teams, and
projects.
Enterprise intranet collaboration environment lab study (SharePoint Server 2010) (на английском языке)
158

Describes lab testing performed on a similar environment to the enterprise Intranet collaboration environment.
Departmental Collaboration


Departmental collaboration environment technical case study (SharePoint Server 2010) (на английском языке)
Describes a departmental collaboration environment used by employees of one department inside Microsoft.
 Divisional portal environment lab study (SharePoint Server 2010) (на английском языке)
Describes lab testing performed on a similar environment to the departmental collaboration environment.
Social


Social environment technical case study (SharePoint Server 2010) (на английском языке)
Describes an environment that hosts My Sites that present employee information to the wider organization. The environment
serves as a central location for personal sites and shared documents.
Microsoft SharePoint Server 2010 social environment: Lab study
Provides guidance on performance and capacity planning for a My Site and social computing portal based on SharePoint Server
2010.
159
Среда публикации корпоративной интрасети Microsoft
SharePoint Server 2010: пример технического внедрения
В этом документе описывается конкретное развертывание Microsoft SharePoint Server 2010, в том числе следующие компоненты:
 Спецификации примера технического внедрения среды, в том числе оборудования, топологии фермы и конфигурации.

Рабочая нагрузка, включающая в себя число и типы пользователей или клиентов, а также характеристики использования
среды

Набор данных для примера технического внедрения фермы, включающий в себя контент базы данных и поисковые индексы
 Данные об исправности и производительности для описываемой среды
Содержание:
 Необходимые сведения

Общие сведения о среде

Спецификации

Рабочая нагрузка

Набор данных

Данные об исправности и производительности
Необходимые сведения
Перед прочтением этого документа убедитесь, что вам знакомы основные понятия управления емкостью в SharePoint Server
2010. В этой документации описывается рекомендуемый подход к управлению емкостью, приводится контекст, позволяющий
наиболее эффективно использовать содержащиеся в ней сведения, а также определяются термины, используемые в рамках
этого документа.
160
Более общие сведения о производительности и емкости, которые могут быть полезны в контексте понимания данных этого
примера технического внедрения, можно найти в следующих документах:
 Обзор управления емкостью и изменения размера для SharePoint Server 2010

Управление мощностью SharePoint Server 2010: ограничения, связанные с программным обеспечением
Общие сведения о среде
В этом техническом документе описывается реальная среда SharePoint Server 2010, развернутая в корпорации Майкрософт.
Данные, приведенные в этом документе, можно использовать в качестве основы для сравнительного анализа планируемых
характеристики рабочей нагрузки и использования. Если планируемая архитектура близка к описываемой, можно использовать
рассматриваемое в этом документе развертывание в качестве отправной точки для создания собственной установки.
В этом документе представлены следующие разделы:
 Спецификации — характеристики оборудования, топологии и конфигурации

Рабочая нагрузка — потребности фермы, включая число пользователей и характеристики использования

Набор данных — в том числе, размер базы данных
 Данные об исправности и производительности — в соответствии с конкретными характеристиками среды
Этот документ входит в состав серии документов Performance and capacity technical case studies (SharePoint Server 2010) (на
английском языке), посвященных средам SharePoint, развернутым в корпорации Майкрософт.
161
Рабочая среда SharePoint Server 2010, описываемая в этом документе, развернута в крупной географически распределенной
компании. Сотрудники компании просматривают большой объем разнообразного контента, в том числе новостей, технических
статей, профилей сотрудников, документации и обучающих материалов. Кроме того, в этой среде сотрудники выполняют
поисковые запросы ко всем средам SharePoint в компании. Также сотрудники ежедневно получают сообщения электронной
почты со ссылками на статьи этой в среде. Большая часть сотрудников использует рассматриваемую среду в качестве домашней
страницы браузера.
Ежедневно в среде работает до 48 000 уникальных пользователей, которые в часы наибольшей нагрузки отправляют до 345
запросов в секунду. Поскольку сайт располагается в интрасети, все пользователи проходят проверку подлинности. Несмотря на
то, что для публикации контента применяется модель с единой средой разработки на месте, в процедурах публикации для среды
публикация чернового контента осуществляется в заданное время по ночам в периоды минимальной нагрузки.
В этом документе описывается типовой день работы среды публикации корпоративной интрасети.
Спецификации
В этом разделе приведены подробные сведения об оборудовании, программном обеспечении, топологии и конфигурации этого
практического примера внедрения среды.
162
Оборудование
В этом разделе описываются используемые в среде серверы.
Примечание.
Эта среда масштабируется в соответствии с требованиями предварительных выпусков SharePoint Server 2010 и других продуктов.
Поскольку емкость развернутого оборудования превышает необходимую для обслуживания типовой для этой среды нагрузки, это
описание оборудования приводится исключительно в качестве дополнительного контекста, характеризующего среду, и может служить в
качестве отправной точки для планирования схожих сред.
Важно провести самостоятельный анализ требований к управлению емкостью на основе планируемых характеристик использования и
рабочей нагрузки. Дополнительные сведения о процессе управления емкостью см. в статье Обзор управления емкостью и изменения
размера для SharePoint Server 2010.
Веб-серверы
В ферме развернут четыре веб-сервера на базе идентичного оборудования, три из которых используются для обработки
контента, а четвертый выступает в качестве выделенного сервера для обхода контента при поиске.
Веб-сервер
WFE1-4
Процессоры
2 четырехъядерных процессора с тактовой частотой 2,33 ГГц
ОЗУ
32 ГБ
Операционная система
Windows Server 2008, 64-разрядная
Размер диска для SharePoint
300 ГБ
Число сетевых адаптеров
2
Скорость сетевого адаптера
1 гигабит
Проверка подлинности
Windows NTLM
163
Веб-сервер
WFE1-4
Тип службы балансировки нагрузки
Аппаратная балансировка нагрузки
Версия программного обеспечения
SharePoint Server 2010 (предварительная версия)
Запускаемые локально службы
Центр администрирования
Входящая электронная почта Microsoft SharePoint Foundation
Веб-приложение Microsoft SharePoint Foundation
Служба таймера рабочих процессов Microsoft SharePoint Foundation
Служба параметров сайтов и запросов поиска
SharePoint Server Search
Используемые службы из фермы федеративных служб
Служба профилей пользователей
Веб-служба Web Analytics
Служба подключения к бизнес-данным
Веб-служба управляемых метаданных
Сервер приложений
В ферме отсутствуют серверы приложений. Локальные службы размещаются на веб-серверах. Другие службы используются из
фермы федеративных служб.
Серверы баз данных
В среде развернут кластер SQL с двумя серверами баз данных на основе идентичного оборудования. Один из серверов
активный, а второй — пассивный и используется для резервирования.
Сервер базы данных
DB1-2
Процессоры
4 четырехъядерных процессора с тактовой частотой 2,4 ГГц
164
Сервер базы данных
DB1-2
ОЗУ
32 ГБ
Операционная система
Windows Server 2008, 64-разрядная
Система хранения и геометрия
(6 * 1,25 ТБ) + 3 ТБ
Диск 1-4: данные SQL
Диск 5: журналы
Диск 6: временная база данных
Число сетевых адаптеров
2
Скорость сетевого адаптера
1 гигабит
Проверка подлинности
Windows NTLM
Версия программного обеспечения
SQL Server 2008
Топология
На следующем рисунке показана топология фермы.
165
166
Конфигурация
В следующей таблице перечислены измененные параметры, которые влияют на производительность и емкость среды.
Параметр
Значение
Примечания
Администрирование
семейства сайтов:
Вкл.
Включение кэша вывода позволяет повысить эффективность работы сервера за счет
уменьшения числа обращений к базе данных для получения часто запрашиваемых данных.
Кэш вывода семейства вебсайтов
Профиль кэша семейства веб- Интрасеть
сайтов (выбор)
(сайт
совместной
работы)
Флажок "Разрешить авторам просматривать кэшированный контент" установлен, что
позволяет обойти стандартное поведение, при котором страницы пользователей, имеющих
разрешения на редактирование, не кэшируются.
Кэш объектов (Откл. | n МБ)
Вкл. – 500 МБ По умолчанию используется значение 100 МБ. Увеличение значения этого параметра
позволяет хранить дополнительные данные в памяти интерфейсного веб-сервера.
Служба использования:
5 дн.
По умолчанию используется значение 14 дн. Уменьшение значения этого параметра
позволяет сэкономить место на диске, на котором хранятся файлы журнала.
1с
По умолчанию используется значение 5 секунд. Уменьшение значения этого параметра
позволит сократить использование полосы пропускания и ресурсов ЦП на сервере базы
данных.
Журнал трассировки – число
дней хранения файлов
журнала (по умолчанию: 14
дн.)
Пороговое значение для
записи журнала:
Microsoft SharePoint
Foundation База данных –
присвойте параметру
QueryLoggingThreshold
значение, равное 1 с
167
Параметр
Значение
Примечания
Сервер базы данных –
экземпляр по умолчанию:
1
По умолчанию используется значение 0. Для обеспечения оптимальной производительности
настоятельно рекомендуется присвоить параметру максимальной степени параллелизма
значение 1 для серверов баз данных SharePoint Server 2010. Дополнительные сведения об
этой настройке см. в статье, посвященной параметру максимальной степени
параллелизма(http://go.microsoft.com/fwlink/?linkid=189030&clcid=0x419).
Максимальная степень
параллелизма
Рабочая нагрузка
В этом разделе описывается рабочая нагрузка, которая определяет потребности фермы, включая число пользователей и
характеристики использования
Характеристики рабочей нагрузки
Значение
Среднее число запросов в секунду
100
Среднее число запросов в секунду в периоды максимальной загрузки 226
(с 11 до 15 часов)
Общее число уникальных пользователей в день
33 580
Среднее число параллельных пользователей
172
Максимальное число параллельных пользователей
376
Общее число запросов за день
3 800 000
В этой таблице показано число запросов для каждого агента пользователя.
168
Агент пользователя
Запросы
Процент от итога
Веб-браузер
3 261 563
97,09%
DAV
2 418
0,07%
Поиск (обход контента)
92 322
2,75%
OneNote
1628
0,05%
Outlook
961
0,03%
Word
449
0,01%
Набор данных
В этом разделе описывается набор данных для примера внедрения фермы, в том числе размер базы данных и поисковые
индексы
Характеристики набора данных
Значение
Размер базы данных (совокупный)
49,9 ГБ
Размер большого двоичного объекта
22,2 ГБ
Число баз данных контента
3
Число веб-приложений
3
Число семейств веб-сайтов
4
Число сайтов
797
Размер индекса поиска (число элементов)
275 000
169
Данные об исправности и производительности
В этом разделе описываются данные об исправности и производительности для этого примера внедрения среды.
Общие счетчики
Метрика
Значение
Доступность (время работоспособности)
99,95%
Процент сбоев
0,05%
Средний объем использования памяти
1,08 ГБ
Максимальный объем использования памяти
2,60 ГБ
% трафика обхода контента при поиске (отношение числа клиентских 6%
поисковых запросов к общему числу запросов)
Запросов ASP.NET в очереди
0,00
На следующих рисунках показана средняя загрузка ЦП и средняя величина задержки для рассматриваемой среды.
170
171
В этом документе величина задержки разбита на четыре категории. 50-й процентиль задержки обычно определяет скорость
ответа сервера. Это означает, что половина запросов обслуживается в пределах указанной величины задержки. 95-й процентиль
задержки обычно определяет время ответа сервера. Это означает, что 95% запросов обслуживается в пределах указанного
времени ответа и, следовательно, лишь 5% обрабатывается дольше этой величины.
Счетчики базы данных
При интерпретации статистических характеристик базы данных для корпоративной среды публикации следует учитывать, что
большинство посетителей обладают только правами на чтение.
Метрика
Значение
Соотношение чтение/запись (операций ввода/вывода для базы
99,999:0,001
172
Метрика
Значение
данных)
Средняя длина дисковой очереди
0,35
Длина дисковой очереди: операций чтения
34
Длина дисковой очереди: операций записи
2,5
Обращений чтения с диска/сек
131,33
Обращений записи на диск/сек
278,33
Операций компиляции SQL/сек
2,36
Операций повторной компиляции SQL/сек
94,80
Операций блокировки SQL: среднее время ожидания
0 мс
Операций блокировки SQL: время ожидания блокировки
0 мс
Операций блокировки SQL: взаимных блокировок в секунду
0
Операций кратковременной блокировки SQL: среднее время
ожидания
0,25 мс
Коэффициент попадания в кэш SQL
>99%
173
Enterprise intranet collaboration environment technical case
study (SharePoint Server 2010) (на английском языке)
This article describes a specific deployment of Microsoft SharePoint Server 2010, that includes the following:
 Technical case study environment specifications, such as hardware, farm topology and configuration.

The workload, that includes the number, and types, of users or clients, and environment usage characteristics.

Technical case study farm dataset, that includes database contents and search indexes.
 Health and performance data that is specific to the environment.
In this article:
 Prerequisite information

Introduction to this environment

Specifications

Workload

Dataset

Health and Performance Data
Prerequisite information
Before reading this document, make sure that you understand the key concepts behind SharePoint Server 2010 capacity management.
The following documentation will help you learn about the recommended approach to capacity management and provide context for
helping you understand how to make effective use of the information in this document, and also define the terms used throughout this
document.
For more conceptual information about performance and capacity that you might find valuable in understanding the context of the data in
this technical case study, see the following documents:
174

Capacity management and sizing for SharePoint Server 2010 (на английском языке)

Управление мощностью SharePoint Server 2010: ограничения, связанные с программным обеспечением
Introduction to this environment
This white paper describes an actual SharePoint Server 2010 environment at Microsoft. Use this document to compare to your planned
workload and usage characteristics. If your planned design is similar, you can use the deployment described here as a starting point for
your own installation.
This document includes the following:
 Specifications, which include hardware, topology, and configuration.

Workload, which is the demand on the farm that includes the number of users, and the usage characteristics.

Dataset that includes database sizes.
 Health and performance data that is specific to the environment.
This document is part of a series of Performance and capacity technical case studies (SharePoint Server 2010) (на английском языке)
about SharePoint environments at Microsoft.
175
The SharePoint environment described in this document is a production environment at a large, geographically distributed company. The
environment hosts very important team sites and publishing portals for internal teams for enterprise collaboration, organizations, teams,
and projects. Sites created in this environment are used as communication portals, applications for business solutions, and general
collaboration. Self-service site creation is used to provision site collections. Custom code is not permitted.
As many as 88,900 unique users visit the environment on a busy day, generating up to 669 requests per second (RPS) during peak hours.
Because this is an intranet site, all users are authenticated.
The information that is provided in this document reflects the enterprise intranet publishing environment on a typical day.
Specifications
This section provides detailed information about the hardware, software, topology, and configuration of the case study environment.
Hardware
This section provides details about the server computers that were used in this environment.
Примечание.
This environment is scaled to accommodate pre-release builds of SharePoint Server 2010 and other products. Hence, the hardware
deployed has larger capacity than necessary to serve the demand typically experienced by this environment. This hardware is described
only to provide additional context for this environment and serve as a starting point for similar environments.
It is important to conduct your own capacity management based on your planned workload and usage characteristics. For more
information about the capacity management process, see Capacity management and sizing for SharePoint Server 2010 (на английском
языке).
Web Servers
There are four Web servers in the farm, each with identical hardware. Three serve content, and the fourth is a dedicated search crawl
target.
176
Web Server
WFE1-4
Processor(s)
2 quad core @ 2.33 GHz
RAM
32 GB
OS
Windows Server® 2008, 64 bit
Size of the SharePoint drive
205 GB
Number of network adapters
2
Network adapter speed
1 Gigabit
Authentication
Windows NTLM
Load balancer type
Hardware load balancing
Software version
SharePoint Server 2010 (pre-release version)
Services running locally
Central Administration
Microsoft SharePoint Foundation Incoming E-Mail
Microsoft SharePoint Foundation Web Application
Microsoft SharePoint Foundation Workflow Timer Service
Search Query and Site Settings Service
SharePoint Server Search
Services consumed from a federated Services farm
User Profile Service
Web Analytics Web Service
Business Data Connectivity Service
Managed Metadata Web Service
Application Server
There are four application servers in the farm, each with identical hardware.
177
Application Server
APP1-4
Processor(s)
4 six core @ 2.40 GHz
RAM
64 GB
OS
Windows Server 2008, 64 bit
Size of the SharePoint drive
300 GB
Number of network adapters
1
Network adapter speed
1 Gigabit
Authentication
Windows NTLM
Load balancer type
Hardware load balancing
Software version
SharePoint Server 2010 (pre-release version)
Services running locally
Office Web Apps
Excel
PowerPoint
Secure Store
Usage and Health
State Service
Database Servers
There is a SQL cluster with 2 database servers, each with identical hardware, one of the servers is active and the other is passive for
redundancy.
178
Database Server
DB1-2
Processor(s)
4 quad core @ 2.4 GHz
RAM
32 GB
OS
Windows Server 2008, 64-bit
Storage and geometry
(1.25 TB * 7) + 3 TB
Disk 1-4: SQL Data
Disk 5: Logs
Disk 6: TempDB
Number of network adapters
2
Network adapter speed
1 Gigabit
Authentication
Windows NTLM
Software version
SQL Server 2008
Topology
The following diagram shows the topology for this farm.
179
180
Configuration
The following table enumerates settings that were changed that affect performance or capacity in the environment.
Setting
Value
Notes
Usage Service
5 days
Trace Log – days to store log files
(default: 14 days)
The default is 14 days. Lowering this setting can save disk space on
the server where the log files are stored.
QueryLoggingThreshold
1 second
SharePoint Foundation Database
– change QueryLoggingThreshold
to 1 second
The default is 5 seconds. Lowering this setting can save bandwidth and
CPU on the database server.
Database Server – Default
Instance
Max degree of parallelism
The default is 0. To ensure optimal performance, we strongly
recommend that you set max degree of parallelism to 1 for database
servers that host SharePoint Server 2010 databases. For more
information about how to set max degree of parallelism, see max
degree of parallelism
Option(http://go.microsoft.com/fwlink/?LinkId=189030).
1
Workload
This section describes the workload, which is the demand on the farm that includes the number of users, and the usage characteristics.
Workload Characteristics
Value
Average Requests per Second (RPS)
157
Average RPS at peak time (11 AM-3 PM)
350
Total number of unique users per day
69,702
181
Workload Characteristics
Value
Average concurrent users
420
Maximum concurrent users
1,433
Total # of requests per day
18,866,527
This table shows the number of requests for each user agent.
User Agent
Requests
Percentage of Total
Search (crawl)
6,384,488
47%
DAV
2,446,588
18%
Browser
730,139
5%
OneNote
665,334
5%
Office Web Applications
391,599
3%
SharePoint Designer
215,695
2%
Dataset
This section describes the case study farm dataset that includes database sizes and Search indexes.
Dataset Characteristics
Value
Database size (combined)
7.5 TB
BLOB size
6.8 TB
182
Dataset Characteristics
Value
Number of content databases
87
Number of Web applications
2
Number of site collections
34,423
Number of sites
101,598
Search index size (number of items)
23 million
Health and Performance Data
This section provides health and performance data that is specific to the Case Study environment.
General Counters
Metric
Value
Availability (uptime)
99.1%
Failure Rate
0.9%
Average memory used
3.4 GB
Maximum memory used
16.1 GB
Search Crawl % of Traffic (Search client requests / total requests)
47%
ASP.NET Requests Queued
0.00
The following charts show the average CPU utilization and latency for this environment:
183
184
In this document, latency is divided into four categories. The 50th percentile latency is typically used to measure the server’s
responsiveness. It means that half of the requests are served within that response time. The 95th percentile latency is typically used to
measure spikes in server response times. It means that 95% of requests are served within that response time, and therefore 5% of the
requests experience slower response times.
Database counters
Metric
Value
Read/Write Ratio (IO Per Database)
99.8 : 0.2
Average Disk queue length
2.3
Disk Queue Length: Reads
2
185
Metric
Value
Disk Queue Length: Writes
0.3
Disk Reads/sec
131.33
Disk Writes/sec
278.33
SQL Compilations/second
9.9
SQL Re-compilations/second
0.07
SQL Locks: Average Wait Time
225 ms
SQL Locks: Lock Wait Time
507 ms
SQL Locks: Deadlocks Per Second
3.8
SQL Latches: Average Wait Time
14.3 ms
SQL Server: Buffer Cache Hit Ratio
74.3%
186
Enterprise intranet collaboration environment lab study
(SharePoint Server 2010) (на английском языке)
This article contains guidance on performance and capacity planning for an enterprise intranet collaboration solution that is based on
Microsoft SharePoint Server 2010. It includes the following:
 Lab environment specifications, such as hardware, farm topology and configuration

Test farm dataset

Test results analysis which should help you determine the hardware, topology and configuration that you must have to deploy a similar
environment, and optimize your environment for appropriate capacity and performance characteristics
In this article:
 Introduction to this environment

Glossary

Overview

Specifications

Results and Analysis
Introduction to this environment
This document provides guidance about scaling out and scaling up servers in a SharePoint Server 2010 enterprise intranet collaboration
solution, based on a testing environment at Microsoft. Capacity planning informs decisions on purchasing hardware and making system
configurations to optimize your solution.
Different scenarios have different requirements. Therefore, it is important to supplement this guidance with additional testing on your own
hardware and in your own environment. If your planned design and workload resembles the environment described in this document, you
can use this document to draw conclusions about scaling your environment up and out.
This document includes the following:
187

Specifications, which include hardware, topology, and configuration

The workload, which is the demand on the farm, includes the number of users, and the usage characteristics

The dataset, such as database sizes

Test results and analysis for scaling out Web servers

Test results and analysis for scaling up Web servers

Test results and analysis for scaling out database servers

Comparison between Microsoft Office SharePoint Server 2007 and SharePoint Server 2010 about throughput and effect on the
web and database servers
The SharePoint Server 2010 environment described in this document is a lab environment that mimics a production environment at a large
company. The production environment hosts very important team sites and publishing portals for internal teams for enterprise
collaboration, organizations, teams, and projects. Employees use that production environment to track projects, collaborate on documents,
and share information within their organization. The environment includes a large amount of small sites used for ad-hoc projects and small
teams. For details about the production environment, see Enterprise intranet collaboration environment technical case study (SharePoint
Server 2010) (на английском языке).
Before reading this document, make sure that you understand the key concepts behind capacity management in SharePoint Server 2010.
The following documentation will help you learn about the recommended approach to capacity management and provide context for
helping you understand how to make effective use of the information in this document, and also define the terms used throughout this
document.
 Обзор управления емкостью и изменения размера для SharePoint Server 2010
 Управление мощностью SharePoint Server 2010: ограничения, связанные с программным обеспечением
Also, we encourage you to read the following:
 Планирование и настройка рабочих характеристик хранилища и SQL Server (SharePoint Server 2010)
Glossary
There are some specialized terms that you will encounter in this document. Here are some key terms and their definitions.
 RPS: Requests per second. The number of requests received by a farm or server in one second. This is a common measurement of
server and farm load.
188

Note that requests differ from page loads; each page contains several components, each of which creates one or more requests when
the page is loaded. Therefore, one page load creates several requests. Typically, authentication checks and events using insignificant
resources are not counted in RPS measurements.
Green Zone: This is the state at which the server can maintain the following set of criteria:

The server-side latency for at least 75% of the requests is less than 1 second.

All servers have a CPU Utilization of less than 50%.
Примечание.
Because this lab environment did not have an active search crawl running, the database server was kept at 40% CPU Utilization or lower,
to reserve 10% for the search crawl load. This assumes Microsoft SQL Server Resource Governor is used in production to limit Search
crawl load to 10% CPU.


Failure rate is less than 0.01%.
Red Zone (Max): This is the state at which the server can maintain the following set of criteria:

HTTP request throttling feature is enabled, but no 503 errors (Server Busy) are returned.

Failure rate is less than 0. 1%.

The server-side latency is less than 3 seconds for at least 75% of the requests.

Database server CPU utilization is less than 80%, which allows for 10% to be reserved for the Search crawl load, limited by using
SQL Server Resource Governor.

AxBxC (Graph notation): This is the number of Web servers, application servers, and database servers respectively in a farm. For
example, 8x1x2 means that this environment has 8 Web servers, 1 application server, and 2 database servers.

MDF and LDF:
SQL Server physical files. For more information, see Files and Filegroups Architecture.
Overview
This section provides an overview to our scaling approach, to the relationship between this lab environment and a similar case study
environment, and to our test methodology.
189
Scaling approach
This section describes the specific order that we recommend for scaling servers in your environment, and is the same approach we took
for scaling this lab environment. This approach will enable you to find the best configuration for your workload, and can be described as
follows:
 First, we scaled out the Web servers. These were scaled out as far as possible under the tested workload, until the database server
became the bottleneck and was unable to accommodate any more requests from the Web servers.

Second, we scaled out the database server by moving half of the content databases to another database server. At this point, the
Web servers were not creating sufficient load on the database servers. Therefore, they were scaled out additionally.

In order to test scale up, we tried another option which is scaling up the Web servers instead of scaling them out. Scaling out the Web
servers is generally preferred over scaling them up because scaling out provides better redundancy and availability.
Correlating the lab environment with a production environment
The lab environment outlined in this document is a smaller scale model of a production environment at Microsoft, and although there are
significant differences between the two environments, it can be useful to examine them side by side because both are enterprise
collaboration environments where the patterns observed should be similar.
The lab environment contains a subset of the data from the production environment, and also some modifications to the workload. This
influences the test results with regard to Web server memory usage, because the object cache on the production environment receives a
larger amount of hits on unique sites, and therefore uses more memory. The lab environment also has less data, and most of it is cached
in memory as opposed to the production environment which carries over seven terabytes of data, so that the database server on the
production environment is required to perform more disk reads than the database server in the lab environment. Similarly, the hardware
that was used in the lab environment is significantly different from the production environment it models, because there is less demand on
those resources. The lab environment relies on more easily available hardware.
To get a better understanding of the differences between the environments, read the Specifications section in this document, and compare
it to the specifications in the Enterprise intranet collaboration environment technical case study (SharePoint Server 2010) (на английском
языке).
Methodology and Test Notes
This document provides results from a test lab environment. Because this was a lab environment and not a production environment, we
were able to control certain factors to show specific aspects of performance for this workload. In addition, certain elements of the
production environment, listed here, were left out of the lab environment to simplify testing overhead. We do not recommend omitting
these elements for production environments.
 Between test runs, we modified only one variable at a time, to make it easy to compare results between test runs.
190

The database servers that were used in this lab environment were not part of a cluster because redundancy was not necessary for the
purposes of these tests.

Search crawl was not running during the tests, whereas it might be running in a production environment. To take this into account, we
lowered the SQL Server CPU utilization in our definition of ‘Green Zone’ and ‘Max’ to accommodate the resources that a search crawl
would have consumed if it were running at the same time with our tests. To learn more about this, read Планирование и настройка
рабочих характеристик хранилища и SQL Server (SharePoint Server 2010).
Specifications
This section provides detailed information about the hardware, software, topology, and configuration of the lab environment.
Hardware
The following sections describe the hardware that was used in this lab environment.
Web and Application servers
There are from one to eight Web servers in the farm, plus one Application server.
Web Server
WFE1-8 and APP1
Processor(s)
2 quad-core 2.33 GHz processors
RAM
8 GB
Operating system
Windows 2008 Server R2
Size of the SharePoint drive
80 GB
Number of network adapters
2
Network adapter speed
1 Gigabit
Authentication
Windows NTLM
Load balancer type
Windows NLB
191
Web Server
WFE1-8 and APP1
Services running locally
WFE 1-8: Basic Federated Services. This included the following:
Timer Service, Admin Service, and Trace Service. APP1: Word
Automation Services, Excel and SandBoxed Code Services.
Database Servers
There are from two to three database servers, up to two running the default SQL Server instance housing the content databases, and one
running the logging database. The logging database is not tracked in this document.
Примечание.
If you enable usage reporting, we recommend that you store the logging database on a separate Logical Unit Number (LUN). For large
deployments and some medium deployments, a separate LUN will not be sufficient, as the demand on the server’s CPU may be too high.
In that case, you will need a separate database server box for the logging database. In this lab environment, the logging database was
stored in a separate instance of SQL Server, and its specifications are not included in this document.
Database Server – Default Instance
DB1-2
Processor(s)
4 dual-core 3.19 GHz processors
RAM
32 GB
Operating system
Windows 2008 Server R2
Storage and geometry
Direct Attached Storage (DAS)
Internal Array with 5 x 300GB 10krpm disk
External Array with 15 x 450GB 15krpm disk
6 x Content Data (External RAID0, 2 spindles 450GB each)
192
Database Server – Default Instance
DB1-2
2 x Content Logs (Internal RAID0, 1 spindle 300GB each)
1 x Temp Data (Internal RAID0, 2 spindles 150GB each)
1 x Temp Log (Internal RAID0, 2 spindles 150GB each)
2 x Backup drive (Internal RAID0, 1 spindle each, 300GB each)
Number of network adapters
1
Network adapter speed
1 Gigabit
Authentication
Windows NTLM
Software version
SQL Server 2008 R2 (pre-release version)
Topology
The following diagram shows the topology in this lab environment:
193
194
Configuration
To allow for the optimal performance, the following configuration changes were made in this lab environment.
Setting
Value
Notes
On
The default is Off. Enabling Blob Caching improves server efficiency by
reducing calls to the database server for static page resources that may
be frequently requested.
1
The default is 0. To ensure optimal performance, we strongly
recommend that you set max degree of parallelism to 1 for database
servers that host SharePoint Server databases. For more information
about how to set max degree of parallelism, see max degree of
parallelism Option(http://go.microsoft.com/fwlink/?LinkId=189030).
Site Collection
Blob Caching
Database Server – Default
Instance
Max degree of parallelism
Workload
The transactional mix for the lab environment described in this document resembles the workload characteristics of a production
environment at Microsoft. For more information about the production environment, see Enterprise intranet collaboration environment
technical case study (SharePoint Server 2010) (на английском языке).
Here are the details of the mix for the lab tests run against SharePoint Server 2010 compared to the production environment. Although
there are some minor differences in the workloads, both represent a typical transactional mix on an enterprise collaboration environment.
195
196
Dataset
The dataset for the lab environment described in this document is a subset of the dataset from a production environment at Microsoft. For
more information about the production environment, see Enterprise intranet collaboration environment technical case study (SharePoint
Server 2010) (на английском языке).
Dataset Characteristics
Value
Database size (combined)
130 GB
BLOB size
108.3 GB
Number of content databases
2
Number of site collections
181
Number of Web applications
1
Number of sites
1384
Results and Analysis
The following results are ordered based on the scaling approach described in the Overview section of this document.
Web Server Scale Out
This section describes the test results that were obtained when we scaled out the number of Web servers in this lab environment.
Test methodology

Add Web servers of the same hardware specifications, keeping the rest of the farm the same.

Measure RPS, latency, and resource utilization.
Analysis
In our testing, we found the following:
197

The environment scaled up to four Web servers per database server. However, the increase in throughput was non-linear especially
on addition of the fourth Web server.

After four Web servers, there are no additional gains to be made in throughput by adding more Web servers because the bottleneck at
this point was the database server CPU Utilization.

The average latency was almost constant throughout the whole test, unaffected by the number of Web servers and throughput.
Примечание.
The conclusions described in this section are hardware specific, and the same throughput might have been achieved by a larger number
of lower-end hardware, or a smaller number of higher-end hardware. Similarly, changing the hardware of the database server would affect
the results. To get an idea on how much of a difference the hardware of the Web servers can affect these results, see the Web Server
Scale Up section.
Results graphs and charts
In the following graphs, the x axis shows the change in the number of Web servers in the farm, scaling from one Web server (1x1x1) to
five Web servers (5x1x1).
1. Latency and RPS
The following graph shows how scaling out (adding Web servers) affects latency and RPS.
198
2. Processor utilization
The following graph shows how scaling out the Web servers affects processor utilization on the Web server(s) and the database server.
199
3. SQL Server I/O operations per section (IOPs) for MDF and LDF files
The following graphs show how the IOPs on the content databases change as the number of Web servers is scaled out. These are
measured by looking at the following performance counters:
 PhysicalDisk: Disk Reads / sec
200
 PhysicalDisk: Disk Writes / sec
In this lab environment, we determined that our data on IOPs was not representative of a production environment because our dataset
was so small that we could fit much more of it in cache than would be possible in the production environment we are modeling. We
calculated projected reads by multiplying the value of the data we had from the lab for writes/second by the ratio of reads to writes in our
production environment. The results in this section are averages. But there are also spikes that occur during certain operations which have
to be accounted for. To learn more about how to estimate IOPs needed, see Планирование и настройка рабочих характеристик
хранилища и SQL Server (SharePoint Server 2010).
Maximum:
201
Green Zone:
Example of how to read these graphs:
An organization with a workload similar to that described in this document that expects 300 RPS to be their green zone, could use 3x1x1
topology, and would use approximately 600 Physical Disk reads/sec on the MDF file.
Database Server Scale Out
This section describes the test results that were obtained when we scaled out the number of database servers in this lab environment.
Test methodology
202

Have two content databases on one database server, and then split them to two servers to effectively double the processor cores and
memory available to the database servers in the environment.

Keep the total IOPs capacity constant even while adding a database server. This means that the number of reads/sec and writes/sec
that the disks could perform for each content database did not change despite splitting the content onto two database servers instead
of one.
Analysis

The first bottleneck in the 4x1x2 environment was the database server CPU utilization. There was close to a linear scale when we
added more processor and memory power.

Scaling to four Web servers and 2 database servers did not provide much additional RPS because the CPU utilization on the Web
servers was close to 100%.

When we scaled out database servers (by adding one additional database server) and added four Web servers, performance scaled
almost linearly. The bottleneck at that point shifted from being the database server CPU utilization to the content database disk IOPs.

No additional tests were performed in this lab environment to scale out past 8x1x2. However we expect that additional IOPs capacity
would additionally increase throughput.

A correlation between the IOPs used and the RPS achieved by the tests was observed
Results graphs and charts
In the following graphs, the x axis is always showing four Web servers together with 1 application server and 1 database server (4x1x1)
scaling out to eight Web servers together with two database servers (8x1x2). Some also show 1x1x1 or 4x1x2.
1. Latency and RPS
The following graph shows how scaling out both Web servers and database servers affects latency and RPS.
203
2. Processor utilization
The following graphs show how scaling out affects processor utilization.
204
3. Memory utilization at scale out
Throughout our testing, we’ve observed that the larger the number of site collections in an environment, the more the memory consumed.
For example, in the tests here where 181 site collections were accessed, the main w3wp process used up 1.8 GB of RAM. For more
examples, see the Performance and capacity technical case studies (SharePoint Server 2010) (на английском языке). Additional content
about memory requirements for increased numbers of site collections is under development. Check back for new and updated content.
205
4. SQL Server I/O operations per section (IOPs) for MDF and LDF files
The following graphs show how the IOPs change as both the number of Web servers and the number of database servers is scaled out.
Maximum RPS
206
Green Zone RPS
Web server Scale Up
This section describes the test results that were obtained when we scaled up the Web servers in this lab environment.
Test methodology

Add more Web server processors, but keep the rest of the farm the same.
Analysis

Scale is linear up to eight processor cores.
207

Tests show that the environment can take advantage of a twenty-four core box, although there is some degradation as twenty-four
cores are approached.
Results graphs and charts
In the following graph, the x axis is the number of processors and the amount of RAM on the Web server. The following graph shows how
scaling up (adding processors) affects RPS on the Web server.
208
Comparing SharePoint Server 2010 and Office SharePoint Server 2007
This section provides information about how the capacity testing for this workload varied between SharePoint Server 2010 and Microsoft
Office SharePoint Server 2007.
Workload
To compare SharePoint Server 2010 with Office SharePoint Server 2007, a different test mix was used than the one outlined in the
Specifications section, because some SharePoint Server 2010 operations were not available in Office SharePoint Server 2007. The test
mix for Office SharePoint Server 2007 is inspired by the same production environment that the SharePoint Server 2010 tests follow.
However this was recorded before the upgrade to SharePoint Server 2010 on that environment.
The following graph shows the test mix for the lab and production environments for Office SharePoint Server 2007.
209
Test methodology

The tests performed for this comparison were performed by creating an Office SharePoint Server 2007 environment, testing it with the
workload outlined earlier in this section, and then upgrading the content databases to SharePoint Server 2010 without changing the
clients using the environment, nor doing a visual upgrade. This upgraded environment was then re-tested for the SharePoint Server
2010 results with the same test mix which includes only Office SharePoint Server 2007 operations.

The dataset was not modified after the content database upgrade for the SharePoint Server 2010 tests.

The test mix for Office SharePoint Server 2007 excludes any new SharePoint Server 2010 specific operations, and resembles the
enterprise intranet collaboration solution on the same production environment for Office SharePoint Server 2007, as described under
the Workload section.
Analysis

When the same number of Web servers are stressed to their maximum throughput on SharePoint Server 2010 and Office SharePoint
Server 2007, SharePoint Server 2010 achieves 20% less throughput compared to Office SharePoint Server 2007.

When the Web servers were scaled out to maximize the database server usage, SharePoint Server 2010 was able to achieve 25%
better throughput compared to Office SharePoint Server 2007. This reflects the improvements that were made in SharePoint Server
2010 to sustain larger deployments.

When the web servers were scaled out to maximize the database server usage, SharePoint Server 2010 was SQL Server CPU
Utilization bound, whereas Office SharePoint Server 2007 was Lock bound on the database tier. This means that increasing the
processing power available to the database servers enables SharePoint Server 2010 to achieve better throughput than would be
possible with the same hardware using Office SharePoint Server 2007. This is caused by the locking mechanisms in the database in
Office SharePoint Server 2007 which are unaffected by improved hardware so that we were unable to push the database server’s
CPU Utilization past 80%.

As a result of these findings outlined earlier in this section, on Office SharePoint Server 2007 the maximum throughput possible was
achieved in a 5x0x1 topology whereas in SharePoint Server 2010 the maximum throughput possible with the same workload was
achieved in a 7x0x1 topology, and yielded a 25% increased total RPS.
Results graphs and charts
The following graph shows the throughput without scaling out Web servers.
210
The following graph shows the throughput when Web servers were at maximum scale out.
211
212
Departmental collaboration environment technical case study
(SharePoint Server 2010) (на английском языке)
This document describes a specific deployment of Microsoft SharePoint Server 2010. It includes the following:
 Technical case study environment specifications, such as hardware, farm topology and configuration

The workload that includes the number, and types, of users or clients, and environment usage characteristics

Technical case study farm dataset that includes database contents and Search indexes
 Health and performance data that is specific to the environment
In this article:
 Prerequisite information

Introduction to this environment

Specifications

Workload

Dataset

Health and Performance Data
Prerequisite information
Before reading this document, make sure that you understand the key concepts behind SharePoint Server 2010 capacity management.
The following documentation will help you learn about the recommended approach to capacity management and provide context for
helping you understand how to make effective use of the information in this document, and also define the terms used throughout this
document.
For more conceptual information about performance and capacity that you might find valuable in understanding the context of the data in
this technical case study, see the following documents:
213

Обзор управления емкостью и изменения размера для SharePoint Server 2010

Управление мощностью SharePoint Server 2010: ограничения, связанные с программным обеспечением
Introduction to this environment
This white paper describes an actual SharePoint Server 2010 environment at Microsoft. Use this document to compare with your planned
workload and usage characteristics. If your planned design is similar, you can use the deployment described here as a starting point for
your own installation.
This document includes the following:
 Specifications, which include hardware, topology and configuration

Workload, which is the demand on the farm that includes the number of users, and the usage characteristics

Dataset that includes database sizes
 Health and performance data that is specific to the environment
This document is part of a series of Performance and capacity technical case studies (SharePoint Server 2010) (на английском языке)
about SharePoint environments at Microsoft.
214
The SharePoint Server 2010 environment described in this document is a production environment at a large, geographically distributed
company. Employees use this environment to track projects, collaborate on documents, and share information within their department.
This environment is also used for internal testing, and is frequently upgraded to the latest SharePoint Server pre-release versions as they
become available.
As many as 9,000 unique users visit the environment on a busy day, generating up to 470 requests per second (RPS) during peak hours.
Because this is an intranet site, all users are authenticated.
The information that is provided in this document reflects the departmental collaboration environment on a typical day.
Specifications
This section provides detailed information about the hardware, software, topology, and configuration of the case-study environment.
Hardware
This section provides details about the server computers that were used in this environment.
Примечание.
This environment is scaled to accommodate pre-release builds of SharePoint Server 2010 and other products. Hence, the hardware
deployed has larger capacity than necessary to serve the demand typically experienced by this environment. This hardware is described
only to provide additional context for this environment and serve as a starting point for similar environments.
It is important to conduct your own capacity management based on your planned workload and usage characteristics. For more
information about the capacity management process, see Обзор управления емкостью и изменения размера для SharePoint Server 2010.
Web Servers
There are four Web servers in the farm, each with identical hardware. Three serve content, and the fourth is a dedicated search crawl
target.
Web Server
WFE1-2
WFE3-4
Processor(s)
2 quad core @ 2.33 GHz
2 quad core @ 2.33 GHz
215
Web Server
WFE1-2
WFE3-4
RAM
32 GB
16 GB
Operating system
Windows Server 2008, 64 bit
Windows Server 2008, 64
bit
Size of the SharePoint drive
3x146GB 15K SAS (3 RAID 1 Disks) Disk 1: OS Disk
2: Swap and BLOB Cache Disk 3: Logs and Temp
directory
3x146GB 15K SAS (3
RAID 1 Disks) Disk 1: OS
Disk 2: Swap and BLOB
Cache Disk 3: Logs and
Temp directory
Number of network adapters
2
2
Network adapter speed
1 Gigabit
1 Gigabit
Authentication
Windows NTLM
Windows NTLM
Load balancer type
Hardware load balancing
Hardware load balancing
Software version
SharePoint Server 2010 (pre-release version)
SharePoint Server 2010
(pre-release version)
Services running locally
Search Query
WFE3 – No services
WFE4 – Search crawl
target
Application Server
There are four application servers in the farm.
Web Server
APP1-3
APP4
Processor(s)
2 quad core @ 2.33 GHz
2 quad core @ 2.33 GHz
216
Web Server
APP1-3
APP4
RAM
16 GB
16 GB
Operating system
Windows Server 2008, 64 bit
Windows Server 2008, 64
bit
Size of the SharePoint drive
3x146GB 15K SAS (3 RAID 1 Disks) Disk 1: OS Disk
2: Swap and BLOB Cache Disk 3: Logs and Temp
directory
2x136GB 15K SAS (RAID
0) 4x60GB SSD, SATA
(RAID 5) Disk 1: OS Disk
2: Swap and BLOB Cache
Disk 3: Logs and Temp
directory
Number of network adapters
2
2
Network adapter speed
1 Gigabit
1 Gigabit
Authentication
Windows NTLM
Windows NTLM
Load balancer type
Hardware load balancing
Hardware load balancing
Software version
SharePoint Server 2010 (pre-release version)
SharePoint Server 2010
(pre-release version)
Services running locally
APP1 – Central Administration and all applications
except for Office Web Applications
APP2 – All applications (including Office Web
Applications)
APP3 – Office Web Applications
Search Crawler
Database Servers
There are three database servers, one running the default SQL Server instance housing the content databases, one running the Usage
and Web Analytics databases, and one running the Search databases.
217
Database
DB1 – Default Instance
DB2
DB3
Processor(s)
4 quad core @ 3.2 GHz
2 quad core @ 3.2
GHz
2 quad core
@ 3.2 GHz
RAM
32 GB
16 GB
32 GB
Operating system
Windows Server 2008 SP1, 64 bit
Windows Server 2008 Windows
SP1, 64 bit
Server 2008
SP1, 64 bit
Storage and geometry
5x146GB 15K SAS + SAN
Disk 1: OS (2 disk RAID 10)
Disk 2: Swap (2 disk RAID 10)
Disk 3: Direct Attached Storage (16 disk RAID 10,
Temp DB data) SAS 146 GB 15K
Disk 4: Direct Attached Storage (16 disk RAID 10,
Temp DB data) SAS 146 GB 15K
Disk 5-15: SAN using fiber connection. When
possible, one database per two disks. Separating
logs and data between LUNs. 15K drives.
6x450GB 15K SAS
Directly attached
14x146GB 15K SAS
Disk 1: Usage logs
and OS
Disk 2: Usage data
218
2x136GB
15K SAS
(RAID 0)
6x60GB
SSD, SATA
(RAID 5)
Disk 1: OS
Disk 2:
Swap and
BLOB
Cache
Disk 3:
Logs and
Temp
directory.
Solid state
drives. 660GB Solid
state drives
(RAID 5)
Database
DB1 – Default Instance
DB2
DB3
Number of network adapters
2
2
2
Network adapter speed
1 Gigabit
1 Gigabit
1 Gigabit
Authentication
Windows NTLM
Windows NTLM
Windows
NTLM
Software version
SQL Server 2008
SQL Server 2008
SQL Server
2008 R2
Topology
The following diagram shows the topology for this farm.
219
220
Configuration
The following table enumerates settings that were made that affect performance or capacity in the environment.
Setting
Value
Notes
Site collection:
Object Caching (On | Off)
Anonymous Cache Profile
(select)
Anonymous Cache Profile
(select)
Object Cache (Off | n MB)
Cross List Query Cache
Changes (Every Time | Every
n seconds)
On
Disabled
Disabled
On – 100GB
Enabling the output cache improves server efficiency by
reducing calls to the database for data that is frequently
requested.
Site collection cache profile
(select)
Intranet (Collaboration Site)
“Allow writers to view cached content” is checked,
bypassing the ordinary behavior of not letting people with
edit permissions to have their pages cached.
Object Cache (Off | n MB)
On – 500 MB
The default is 100 MB. Increasing this setting enables
additional data to be stored in the front-end Web server
memory.
60 seconds
Usage Service:
5 days
Trace Log – days to store log
files (default: 14 days)
The default is 14 days. Lowering this setting can save disk
space on the server where the log files are stored.
Query Logging Threshold: 1 second
Microsoft SharePoint
Foundation Database –
configure
The default is 5 seconds. Lowering this setting can save
bandwidth and CPU on the database server.
221
Setting
Value
Notes
1
The default is 0. To ensure optimal performance, we
strongly recommend that you set max degree of parallelism
to 1 for database servers that host SharePoint Server 2010
databases. For more information about how to set max
degree of parallelism, see max degree of parallelism
Option (http://go.microsoft.com/fwlink/?LinkId=189030).
QueryLoggingThreshold to 1
second
Database Server – Default
Instance:
Max degree of parallelism
Workload
This section describes the workload, which is the demand on the farm that includes the number of users, and the usage characteristics.
Workload Characteristics
Value
Average Requests per Second (RPS)
165
Average RPS at peak time (11 AM-3 PM)
216
Total number of unique users per day
9186
Average concurrent users
189
Maximum concurrent users
322
Total # of requests per day
7,124,943
This table shows the number of requests for each user agent.
222
User Agent
Requests
Percentage of Total
Search (crawl)
4,373,433
67.61%
Outlook
897,183
13.87%
OneNote
456,917
7.06%
DAV
273,391
4.23%
Browser
247,303
3.82%
Word
94,465
1.46%
SharePoint Workspaces
70,651
1.09%
Office Web Applications
45,125
0.70%
Excel
8,826
0.14%
Access
1,698
0.03%
Dataset
This section describes the case study farm dataset that includes database sizes and Search indexes.
Dataset Characteristics
Value
Database size (combined)
1.8 TB
BLOB size
1.68 TB
Number of content databases
18
223
Dataset Characteristics
Value
Total number of databases
36
Number of site collections
7,499
Number of Web applications
7
Number of sites
42,457
Search index size (number of items)
4.6 million
Health and Performance Data
This section provides health and performance data that is specific to the case study environment.
General Counters
Metric
Value
Availability (uptime)
99.9995%
Failure Rate
0.0005%
Average memory used
0.89 GB
Maximum memory used
5.13 GB
Search Crawl % of Traffic (Search client requests / total requests)
82.5%
The following charts show the average CPU utilization and latency for this environment:
224
225
In this document, latency is divided into four categories. The 50th percentile latency is typically used to measure the server’s
responsiveness. It means that half of the requests are served within that response time. The 95th percentile latency is typically used to
measure spikes in server response times. It means that 95% of requests are served within that response time, and therefore, 5% of the
requests experience slower response times.
226
Database Counters
Metric
Value
Average Disk queue length
1.42
Disk Queue Length: Reads
1.38
Disk Queue Length: Writes
0.04
Disk Reads/sec
56.51
Disk Writes/sec
17.60
SQL Compilations/second
13.11
SQL Re-compilations/second
0.14
SQL Locks: Average Wait Time
294.56 ms
SQL Locks: Lock Wait Time
867.53 ms
SQL Locks: Deadlocks Per Second
1.87
SQL Latches: Average Wait Time
5.10 ms
SQL Cache Hit Ratio
99.77%
227
Divisional portal environment lab study (SharePoint Server
2010) (на английском языке)
This document provides guidance on performance and capacity planning for a divisional portal based on Microsoft SharePoint Server
2010. It includes the following:
 Test environment specifications, such as hardware, farm topology and configuration

Test farm dataset

Test data and recommendations for how to determine the hardware, topology and configuration that you must have to deploy a similar
environment, and how to optimize your environment for appropriate capacity and performance characteristics
In this article:
 Introduction to this environment

Glossary

Overview

Specifications

Results and analysis
Introduction to this environment
This document outlines the test methodology and results to provide guidance for capacity planning of a typical divisional portal. A
divisional portal is a SharePoint Server 2010 deployment where teams mainly do collaborative activities and some content publishing. This
document assumes a "division" to be an organization inside an enterprise with 1,000 to 10,000 employees.
Different scenarios will have different requirements. Therefore, it is important to supplement this guidance with additional testing on your
own hardware and in your own environment. If your planned design and workload resembles the environment described in this document,
you can use this document to draw conclusions about scaling your environment up and out.
When you read this document, you will understand how to do the following:
228

Estimate the hardware that is required to support the scale that you need to support: number of users, load, and the features enabled.

Design your physical and logical topology for optimal reliability and efficiency. High Availability/Disaster Recovery are not covered in
this document.
 Understand the effect of ongoing search crawls on RPS for a divisional portal deployment.
The SharePoint Server 2010 environment described in this document is a lab environment that mimics a production environment at a large
company. For details about the production environment, see Departmental collaboration environment technical case study (SharePoint
Server 2010) (на английском языке).
Before reading this document, make sure that you understand the key concepts behind capacity management in SharePoint Server 2010.
The following documentation will help you learn about the recommended approach to capacity management and provide context for
helping you understand how to make effective use of the information in this document, and also define the terms used throughout this
document.
 Обзор управления емкостью и изменения размера для SharePoint Server 2010
 Управление мощностью SharePoint Server 2010: ограничения, связанные с программным обеспечением
Also, we encourage you to read the following:
 Планирование и настройка рабочих характеристик хранилища и SQL Server (SharePoint Server 2010)
Glossary
There are some specialized terms that you will encounter in this document. Here are some key terms and their definitions.
 RPS: Requests per second. The number of requests received by a farm or server in one second. This is a common measurement of
server and farm load.
Note that requests differ from page loads; each page contains several components, each of which creates one or more requests when
the page is loaded. Therefore, one page load creates several requests. Typically, authentication checks and events using insignificant
resources are not counted in RPS measurements.
 Green Zone: This is the state at which the server can maintain the following set of criteria:

The server-side latency for at least 75% of the requests is less than .5 second.

All servers have a CPU Utilization of less than 50%.
229
Примечание.
Because this lab environment did not have an active search crawl running, the database server was kept at 40% CPU Utilization or lower,
to reserve 10% for the search crawl load. This assumes Microsoft SQL Server Resource Governor is used in production to limit Search
crawl load to 10% CPU.


Failure rate is less than 0.01%.
Red Zone (Max): This is the state at which the server can maintain the following set of criteria:

HTTP request throttling feature is enabled, but no 503 errors (Server Busy) are returned.

Failure rate is less than 0. 1%.

The server-side latency is less than 1 second for at least 75% of the requests.

Database server CPU utilization is less than or equal to 75%, which allows for 10% to be reserved for the Search crawl load,
limited by using SQL Server Resource Governor.

All Web servers have a CPU Utilization of less than or equal to 75%.

AxBxC (Graph notation): This is the number of Web servers, application servers, and database servers respectively in a farm. For
example, 2x1x1 means that this environment has 2 Web servers, 1 application server, and 1 database server.

MDF and LDF:
SQL Server physical files. For more information, see Files and Filegroups Architecture.
Overview
This section provides an overview to our assumptions and our test methodology.
Assumptions
For our testing, we made the following assumptions:
 In the scope of this testing, we did not consider disk I/O as a limiting factor. It is assumed that an infinite number of spindles are
available.

The tests model only peak time usage on a typical divisional portal. We did not consider cyclical changes in traffic seen with day-night
cycles. That also means that timer jobs which generally require scheduled nightly runs are not included in the mix.

There is no custom code running on the divisional portal deployment in this case. We cannot guarantee behavior of custom code/thirdparty solutions installed and running in your divisional portal.
230

For the purpose of these tests, all of the services databases and the content databases were put on the same instance of Microsoft
SQL Server. The usage database was maintained on a separate instance of SQL Server.

For the purpose of these tests, BLOB cache is enabled.

Search crawl traffic is not considered in these tests. But to factor in the effects of an ongoing search crawl, we modified definitions of a
healthy farm. (Green-zone definition to be 40 percent for SQL Server to allow for 10 percent tax from Search crawls. Similarly, we
used 80 percent SQL Server CPU as the criteria for max RPS.)
Test methodology
We used Visual Studio Team System for Test 2008 SP2 to perform the performance testing. The testing goal was to find the performance
characteristic of green zone, max zone and various system stages in between for each topology. Detailed definitions of "max zone" and
"green zone" are given in the Glossary as measured by specific values for performance counters, but in general, a farm configuration
performing around "max zone" breakpoint can be considered under stress, whereas a farm configuration performing "green zone"
breakpoint can be considered healthy.
The test approach was to start by using the most basic farm configuration and run a set of tests. The first test is to gradually increase the
load on the system and monitor its performance characteristic. From this test we derived the throughput and latency at various user loads
and also identified the system bottleneck. After we had this data, we identified at what user load did the farm exhibit green zone and max
zone characteristics. We ran separate tests at those pre-identified constant user loads for a longer time. These tests ensured that the farm
configuration can provide constant green zone and max zone performance at respective user loads, over longer period of time.
Later, while doing the tests for the next configuration, we scaled out the system to eliminate bottlenecks identified in previous run. We kept
iterating in this manner until we hit SQL Server CPU bottleneck.
We started off with a minimal farm configuration of 1 Web server /application server and 1 database server. Through multiple iterations,
we finally ended at 3 Web servers, 1 application server, 1 database server farm configuration, where the database server CPU was maxed
out. Below you will find a quick summary and charts of tests we performed on each iteration to establish green zone and max zone for that
configuration. That is followed by comparison of green zone and max zone for different iterations, from which we derive our
recommendations.
The SharePoint Admin Toolkit team has built a tool that is named "Load Test Toolkit (LTK)" which is publically available for customers to
download and use.
Specifications
This section provides detailed information about the hardware, software, topology, and configuration of the lab environment.
231
Hardware
The table that follows presents hardware specs for the computers that were used in this testing. Every Web server that was added to the
server farm during multiple iterations of the test complies with the same specifications.
Web server
Application Server
Database
Server
Processor(s)
[email protected]
[email protected]
4px4c@
3.19GHz
RAM
8 GB
8 GB
32 GB
Number of network adapters
2
2
1
Network adapter speed
1 Gigabit
1 gigabit
1 Gigabit
Load balancer type
F5 - Hardware load balancer
Not applicable
Not
applicable
ULS Logging level
Medium
Medium
Not
applicable
Software
The table that follows explains software installed and running on the servers that were used in this testing effort.
Web Server
Application Server
Database
Server
Operating System
Windows Server 2008 R2 x64
Windows
Server 2008 R2 x64
Windows
Server 2008
x64
Software version
SharePoint Server 2010 and Office Web
SharePoint Server
SQL Server
232
Web Server
Application Server
Applications, pre-release versions
2010 and Office Web 2008 R2
Applications, preCTP3
release versions
Authentication
Windows NTLM
Windows NTLM
Windows
NTLM
Load balancer type
F5 - Hardware load balancer
Not applicable
Not
applicable
ULS Logging level
Medium
Medium
Not
applicable
Anti-Virus Settings
Disabled
Disabled
Disabled
Services running locally
Microsoft SharePoint Foundation Incoming E-Mail
Microsoft SharePoint Foundation Web Application
Microsoft SharePoint Foundation Workflow Timer
Service
Search Query and Site Settings Service
SharePoint Server Search
Central Administration Not
applicable
Excel Services
Managed Metadata
Web Service
Microsoft SharePoint
Foundation Incoming
E-Mail
Microsoft SharePoint
Foundation Web
Application
Microsoft SharePoint
Foundation Workflow
Timer Service
PowerPoint Services
Search Query and
233
Database
Server
Web Server
Application Server
Database
Server
Site Settings Service
SharePoint Server
Search
Visio Graphics
Services
Word Viewing Service
The table indicates which services are provisioned in the test environment. Other services such as the User Profile service and Web
Analytics are not provisioned.
Topology and configuration
The following diagram shows the topology used for the tests. We changed the number of Web servers from 1 to 2 to 3, as we moved
between iterations, but otherwise the topology remained the same.
234
235
Dataset and disk geometry
The test farm was populated with about 1.62 Terabytes of content, distributed across five different sized content databases. The following
table explains this distribution:
Content database
1
2
3
4
5
Content database size
36 GB
135 GB
175
GB
1.2
terabytes
75 GB
Number of sites
44
74
9
9
222
Number of webs
1544
2308
2242 2041
1178
RAID configuration
0
0
0
0
0
Number of spindles for MDF
1
1
5
3
1
Number of spindles for LDF
1
1
1
1
1
Transactional mix
The following are important notes about the transactional mix:
 There are no My Sites provisioned on the divisional portal. Also, the User Profile service, which supports My Sites, is not running on
the farm. The transactional mix does not include any My Site page/web service hits or traffic related to Outlook Social Connector.

The test mix does not include any traffic generated by co-authoring on documents.

The test mix does not include traffic from Search Crawl. However this was factored into our tests by modifying the Green-zone
definition to be 40 percent SQL Server CPU usage instead of the standard 50 percent to allow for 10 percent for the search crawl.
Similarly, we used 80 percent SQL Server CPU as the criteria for max RPS.
The following table describes the overall transaction mix. The percentages total 100.
236
Feature or Service
Operation
Read/write
Percentage of
mix
ECM
Get static files
r
8.93%
View home page
r
1.52%
Display/Edit upsize list item and new forms
r
0.32%
Download file by using "Save as"
r
1.39%
Microsoft OneNote 2010
Open Microsoft Office OneNote 2007 file
r
13.04%
Search
Search through OSSSearch.aspx or
SearchCenter
r
4.11%
Workflow
Start autostart workflow
w
0.35%
Render Visio file in PNG/XAML
r
0.90%
Office Web Applications - PowerPoint
Render Microsoft PowerPoint, scroll to 6 slides
r
0.05%
Office Web Applications - Word
Render and scroll Microsoft Word doc in
PNG/Silverlight
r
0.24%
Microsoft SharePoint Foundation
List – Check out and then check in an item
w
0.83%
List - Get list
r
0.83%
List - Outlook sync
r
1.66%
List - Get list item changes
r
2.49%
List - Update list items and adding new items
w
4.34%
Get view and view collection
r
0.22%
Get webs
r
1.21%
Microsoft InfoPath
Microsoft Visio
237
Feature or Service
Operation
Read/write
Percentage of
mix
Browse to Access denied page
r
0.07%
View Browse to list feeds
r
0.62%
Browse to viewlists
r
0.03%
Browse to default.aspx (home page)
r
1.70%
Browse to Upload doc to doc lib
w
0.05%
Browse to List/Library's default view
r
7.16%
Delete doc in doclib using DAV
w
0.83%
Get doc from doclib using DAV
r
6.44%
Lock and Unlock a doc in doclib using DAV
w
3.32%
Propfind list by using DAV
r
4.16%
Propfind site by using DAV
r
4.16%
List document by using FPSE
r
0.91%
Upload doc by using FPSE
w
0.91%
Browse to all site content page
r
0.03%
View RSS feeds of lists or wikis
r
2.03%
Excel
Render small/large Excel files
r
1.56%
Workspaces
WXP - Cobalt internal protocol
r
23.00%
Full file upload using WXP
w
0.57%
238
Results and analysis
This section describes the test methodology and results to provide guidance for capacity planning of a typical divisional portal.
Results from 1x1 farm configuration
Summary of results

On a 1 Web server and 1 database server farm, in addition to Web server duties, the same computer was also acting as application
server. Clearly this computer (still called Web server) was the bottleneck. As presented in the data here, the Web server CPU reached
around 86% utilization when the farm was subjected to user load of 125 users by using the transactional mix described earlier in this
document. At that point, the farm exhibited max RPS of 101.37.

Even at a small user load, Web server utilization was always too high to consider this farm as a healthy farm. For the workload and
dataset that we used for the test, we do not recommend this configuration as a real deployment.

Going by definition of "green zone", there is not really a "green zone" for this farm. It is always under stress, even at a small load. As
for "max zone", at the smallest load, where the farm was in "max zone", the RPS was 75.

Because the Web server was the bottleneck due to its dual role as an application server, for the next iteration, we separated out the
application server role onto its own computer.
Performance counters and graphs
The following table presents various performance counters captured during testing a 1x1 farm at different steps in user load.
User Load
50
75
100
RPS
74.958
89.001
95.79 101.37
Latency
0.42
0.66
0.81
0.81
Web server CPU
79.6
80.1
89.9
86
Application server CPU
N/A
N/A
N/A
N/A
Database server CPU
15.1
18.2
18.6
18.1
75th Percentile (sec)
0.3
0.35
0.55
0.59
239
125
User Load
50
75
100
125
95th Percentile (sec)
0.71
0.77
1.03
1
The following chart shows the RPS and latency results for a 1x1 configuration.
240
The following chart shows performance counter data in a 1x1 configuration.
Results from 1x1x1 farm configuration
Summary of results
241

On a 1 Web server, 1 application server and 1 database server farm, the Web server was the bottleneck. As presented in the data in
this section, the Web server CPU reached around 85% utilization when the farm was subjected to user load of 150 users by using the
transactional mix described earlier in this document. At that point, the farm exhibited max RPS of 124.1.

This configuration delivered "green zone" RPS of 99, with 75th percentile latency being 0.23 sec, and the Web server CPU hovering
around 56 % utilization. This indicates that this farm can healthily deliver an RPS of around 99. "Max zone" RPS delivered by this farm
was 123 with latencies of 0.25 sec and the Web server CPU hovering around 85%.

Because the Web server CPU was the bottleneck in this iteration, we relived the bottleneck by adding another the Web server for the
next iteration.
Performance counters and graphs
The following table presents various performance counters captured during testing a 1x1x1 farm, at different steps in user load.
User Load
25
50
75
RPS
53.38
91.8
Latency
34.2
Web server CPU
125
150
112.2 123.25
123.25
124.1
56
71.7
81.5
84.5
84.9
23.2
33.8
34.4
32
30.9
35.8
Application server CPU
12.9
19.7
24.1
25.2
23.8
40.9
Database server CPU
0.22
0.23
0.27
0.32
0.35
0.42
75th Percentile (sec)
0.54
0.52
0.68
0.71
0.74
0.88
The following chart shows RPS and latency results for a 1x1x1 configuration.
242
100
The following chart shows performance counter data in a 1x1x1 configuration.
243
Results from 2x1x1 farm configuration
Summary of results

On a 2 Web server, 1 application server and 1 database server farm, the Web server was the bottleneck. As presented in the data in
this section, Web server CPU reached around 76% utilization when the farm was subjected to user load of 200 users by using the
transactional mix described earlier in this document. At that point, the farm exhibited max RPS of 318.
244

This configuration delivered "green zone" RPS of 191, with 75th percentile latency being 0.37 sec, and Web server CPU hovering
around 47 % utilization. This indicates that this farm can healthily deliver an RPS of around 191. "Max zone" RPS delivered by this
farm was 291 with latencies of 0.5 sec and Web server CPU hovering around 75%.

Because the Web server CPU was the bottleneck in this iteration, we relived the bottleneck by adding another Web server for the next
iteration.
Performance counters and graphs
The following table presents various performance counters captured during testing a 2x1x1 farm, at different steps in user load.
User Load
40
80
115
150
175
200
RPS
109
190
251
287
304
318
Latency
0.32
0.37
0.42
0.49
0.54
0.59
Web server CPU
27.5
47.3
61.5
66.9
73.8
76.2
Application server CPU
17.6
29.7
34.7
38
45
45.9
Database server CPU
21.2
36.1
43.7
48.5
52.8
56.2
75th Percentile (sec)
0.205
0.23
0.27
0.3
0.305 0.305
95th Percentile (sec)
0.535
0.57
0.625 0.745 0.645 0.57
The following chart shows RPS and latency results for a 2x1x1 configuration.
245
The following chart shows performance counter data in a 2x1x1 configuration.
246
Results from 3x1x1 farm configuration
Summary of results

On a 3 Web server, 1 application server and 1 database server farm, finally, the database server CPU was the bottleneck. As
presented in the data in this section, database server CPU reached around 76% utilization when the farm was subjected to user load
of 226 users by using the transactional mix described earlier in this document. At that point, the farm exhibited max RPS of 310.
247

This configuration delivered "green zone" RPS of 242, with 75th percentile latency being 0.41 sec, and database server CPU hovering
around 44% utilization. This indicates that this farm can healthily deliver an RPS of around 242. "Max zone" RPS delivered by this
farm was 318 with latencies of 0.5 sec and database server CPU hovering around 75%.
 This was the last configuration in the series.
Performance counters and graphs
The following table presents various performance counters captured during testing a 3x1x1 farm, at different steps in user load.
User Load
66
103
141
RPS
193.8
218.5
269.8 275.5 318.25
310
Latency
0.3
0.41
0.47
0.58
0.54
0.78
Web server CPU
33
38.3
45.8
43.3
51
42.5
Application server CPU
28
32.6
46.5
40
45.1
43.7
Database server CPU
41.6
44.2
52.6
48
61.8
75
75th Percentile (sec)
0.22
0.24
0.30
0.65
0.78
0.87
95th Percentile (sec)
0.49
0.57
0.72
1.49
0.51
1.43
The following chart shows RPS and latency results in a 3x1x1 configuration.
248
17
202
226
The following chart shows performance counter data for a 3x1x1 configuration.
249
Comparison
From the iterative tests we performed, we found out the points at which a configuration enters max zone or green zone. Here’s a table of
those points.
The table and charts in this section provide a summary for all the results that were presented earlier in this article.
250
Topology
1x1
1x1x1
2x1x1
3x1x1
Max RPS
75
123
291
318
Green Zone RPS
Not applicable
99
191
242
Max Latency
0.29
0.25
0.5
0.5
Green Zone Latency
0.23
0.23
0.37
0.41
The following chart shows a summary of RPS at different configurations.
251
The following chart shows a summary of latency at different configurations.
252
A note on disk I/O
Disk I/O based bottlenecks are not considered while prescribing recommendations in this document. However, it is still interesting to
observe the trend. Here are the numbers:
253
Configuration
1x1
1x1x1
2x1x1
3x1x1
Max RPS
75
154
291
318
Reads/Sec
38
34
54
58
Writes/Sec
135
115
230
270
Because we ran the tests in durations of 1 hour and the test uses only a fixed set of sites/webs/document libraries and so on, SQL Server
could cache all the data. Thus, our testing caused very little Read IO. We see more write I/O operations that read. It is important to be
aware that this is an artifact of the test methodology, and not a good representation of real deployments. Most of the typical divisional
portals would have more read operations 3 to 4 times more than write operations.
The following chart shows I/Ops at different RPS.
254
Tests with Search incremental crawl
As we mentioned before, all the tests until now were run without Search crawl traffic. In order to provide information about how ongoing
search crawl can affect performance of a farm, we decided to find out the max user RPS and corresponding user latencies with search
crawl traffic in the mix. We added a separate Web server to 3x1x1 farm, designated as a crawl target. We saw a 17% drop in RPS
compared to original RPS exhibited by 3x1x1.
255
In a separate test, on the same farm, we used Resource Governor to limit available resources to search crawl 10%. We saw that as
Search uses lesser resources, the max RPS of the farm climbs up by 6%.
Baseline 3x1x1
Only Incremental
Crawl
No
Resource
Governor
10%
Resource
Governor
RPS
318
N/A
276
294.5
Percent RPS difference from baseline
0%
N/A
83%
88%
Database server CPU (%)
83.40
8.00
86.60
87.3
SA Database server CPU (%)
3.16
2.13
3.88
4.2
Web server CPU (%)
53.40
0.30
47.00
46.5
Application server CPU (%)
22.10
28.60
48.00
41.3
Crawl Web server CPU (%)
0.50
16.50
15.00
12.1
The following chart shows results from tests with incremental Search crawl turned on.
256
257
Важно!
Here we are only talking about incremental crawl, on a farm where there are not very many changes to the content. It is important to be
aware that 10% resource utilization will be insufficient for a full search crawl. It may also prove to be less if there are too many changes. It
is definitely not advised to limit resource utilization to 10% if you are running a full search crawl, or your farm generally sees a high volume
of content changes between crawls.
Summary of results and recommendations
To paraphrase the results from all configurations we tested:
 With the configuration, dataset and test workload we had selected for the tests, we could scale out to maximum 3 Web servers before
SQL Server was bottlenecked on CPU. The absolute max RPS we could reach that point was somewhere around 318.

With each additional Web server, increase in RPS was almost linear. We can extrapolate that as long as SQL Server is not
bottlenecked, you can add more Web servers and additional increase in RPS is possible.

Latencies are not affected much as we approached bottleneck on SQL Server.
 Incremental Search crawl directly affects RPS offered by a configuration. The effect can be minimized by using Resource Governor.
Using the results, here are few recommendations on how to achieve even larger scale if you must have more RPS from your divisional
portal:
 1x1 farm can deliver up to 75 RPS. However, it is usually stressed. It’s not a recommended configuration for a divisional portal in
production.

Separate out content databases and services databases on separate instances of SQL Server: In the test workload used in tests,
when SQL Server was bottlenecked on CPU, only 3% of the traffic was to the services databases. Thus this step would have achieved
slightly better scale out than what we saw. But, in general, increase in scale out by separating out content databases and services
databases is directly proportional to the traffic to services database in your farm.

Separate out individual content databases on separate instances of SQL Server. In the dataset used for testing, we had 5 content
databases, all located on the same instance of SQL Server. By separating them out on different computers, you will be spreading
CPU utilization across multiple computers. Therefore, you will see much larger RPS numbers.

Finally when SQL Server is bottlenecked on CPU, adding more CPU to SQL Server can increase RPS potential of the farm almost
linearly.
258
How to translate these results into your deployment
In this article, we discussed results as measured by RPS and latency, but how do you apply these in the real world? Here’s some math
based on our experience from divisional portal internal to Microsoft.
A divisional portal in Microsoft which supports around 8000 employees collaborating heavily, experiences an average RPS of 110. That
gives a Users to RPS ratio of ~72 (that is, 8000/110). Using the ratio, and the results discussed earlier in this article, we can estimate how
many users a particular farm configuration can support healthily:
Farm configuration
"Green Zone" RPS
Approximate number of
users it can support
1x1x1
99
7128
2x1x1
191
13452
3x1x1
242
17424
Of course, this is only directly applicable if your transactional mix and hardware is exactly same as the one used for these tests. Your
divisional portal may have different usage pattern. Therefore, the ratio may not directly apply. However, we expect it to be approximately
applicable.
About the authors
Gaurav Doshi is a Program Manager for SharePoint Server at Microsoft.
Raj Dhrolia is a Software Test Engineer for SharePoint Server at Microsoft.
Wayne Roseberry is a Principal Test Lead for SharePoint Server at Microsoft.
259
Social environment technical case study (SharePoint Server
2010) (на английском языке)
This document describes a specific deployment of Microsoft SharePoint Server 2010. It includes the following:
 Technical case study environment specifications, such as hardware, farm topology and configuration

The workload that includes the number, and types, of users or clients, and environment usage characteristics

Technical case study farm dataset that includes database contents and Search indexes
 Health and performance data that is specific to the environment
In this article:
 Prerequisite information

Introduction to this environment

Specifications

Workload

Dataset

Health and Performance Data
Prerequisite information
Before reading this document, make sure that you understand the key concepts behind SharePoint Server 2010 capacity management.
The following documentation will help you learn about the recommended approach to capacity management and provide context for
helping you understand how to make effective use of the information in this document, and also define the terms used throughout this
document.
For more conceptual information about performance and capacity that you might find valuable in understanding the context of the data in
this technical case study, see the following documents:
260

Обзор управления емкостью и изменения размера для SharePoint Server 2010

Управление мощностью SharePoint Server 2010: ограничения, связанные с программным обеспечением
Introduction to this environment
This white paper describes an actual SharePoint Server 2010 environment at Microsoft. Use this document to compare with your planned
workload and usage characteristics. If your planned design is similar, you can use the deployment described here as a starting point for
your own installation.
This document includes the following:
 Specifications, which include hardware, topology and configuration

Workload, which is the demand on the farm that includes the number of users, and the usage characteristics

Dataset that includes database sizes
 Health and performance data specific to the environment
This document is part of a series of Performance and capacity technical case studies (SharePoint Server 2010) (на английском языке)
about SharePoint environments at Microsoft.
261
The SharePoint Server 2010 environment described in this document is a production environment at a large, geographically distributed
company. This environment hosts SharePoint My Sites that connect employees with one another and the information that they need.
Employees use this environment to present personal information such as areas of expertise, past projects, and colleagues to the wider
organization. The environment also hosts personal sites and documents for viewing, editing, and collaboration. My Sites are integrated
with Active Directory Domain Services (AD DS) to provide a central location that can be accessed from the browser and various client
applications.
As many as 72,000 unique users visit the environment on a busy day, generating up to 180 requests per second (RPS) during peak hours.
Because this is an intranet site, all users are authenticated.
The information that is provided in this document reflects the enterprise social environment on a typical day.
Specifications
This section provides detailed information about the hardware, software, topology, and configuration of the case-study environment.
Hardware
This section provides details about the server computers that were used in this environment.
Примечание.
This environment is scaled to accommodate pre-release builds of SharePoint Server 2010 and other products. Hence, the hardware
deployed has larger capacity than necessary to serve the demand typically experienced by this environment. This hardware is described
only to provide additional context for this environment and serve as a starting point for similar environments.
It is important to conduct your own capacity management based on your planned workload and usage characteristics. For more
information about the capacity management process, see Обзор управления емкостью и изменения размера для SharePoint Server 2010.
Web Servers
There are three Web servers in the farm, each with identical hardware. Two serve content, and the third is a dedicated search crawl
target.
262
Web Server
WFE1-3
Processor(s)
2 quad core @ 2.33 GHz
RAM
16 GB
Operating system
Windows Server 2008, 64 bit
Size of the SharePoint drive
400 GB
Number of network adapters
2
Network adapter speed
1 Gigabit
Authentication
Windows NTLM
Load balancer type
Hardware load balancing
Software version
SharePoint Server 2010 (pre-release version)
Services running locally
Central Administration
Microsoft SharePoint Foundation Incoming E-Mail
Microsoft SharePoint Foundation Web Application
Microsoft SharePoint Foundation Workflow Timer Service
Search Query and Site Settings Service
SharePoint Server Search
Services consumed from a federated services farm
User Profile Service
Web Analytics Web Service
Business Data Connectivity Service
Managed Metadata Web Service
Application Server
There are two application servers in the farm, each with identical hardware.
263
Application Server
APP1-4
Processor(s)
2 quad core @ 2.33 GHz
RAM
16 GB
OS
Windows Server 2008, 64 bit
Size of the SharePoint drive
400 GB
Number of network adapters
1
Network adapter speed
1 Gigabit
Authentication
Windows NTLM
Load balancer type
Hardware load balancing
Software version
SharePoint Server 2010 (pre-release version)
Services running locally
Office Web Apps
Excel
PowerPoint
Secure Store
Usage and Health
State Service
Database Servers
There is a SQL cluster with two database servers, each with identical hardware. One of the servers is active and the other is passive for
redundancy.
264
Database Server
DB1-2
Processor(s)
4 quad core @ 2.4 GHz
RAM
64 GB
Operating system
Windows Server 2008, 64 bit
Storage and geometry
(1.25 TB * 6)
Disk 1-4: SQL Data
Disk 5: Logs
Disk 6: TempDB
Number of network adapters
2
Network adapter speed
1 @ 100MB, 1 @ 1GB
Authentication
Windows NTLM
Software version
SQL Server 2008
Topology
The following diagram shows the topology for this farm.
265
266
Configuration
The following table enumerates settings that were changed that affect performance or capacity in the environment.
Setting
Value
Notes
Usage Service:
5 days
Trace Log – days to store log files
(default: 14 days)
The default is 14 days. Lowering this setting can save disk space on
the server where the log files are stored.
QueryLoggingThreshold
1 second
Microsoft SharePoint Foundation
Database – configure
QueryLoggingThreshold to 1
second
The default is 5 seconds. Lowering this setting can save bandwidth and
CPU on the database server.
Database Server – Default
Instance
Max degree of parallelism
The default is 0. To ensure optimal performance, we strongly
recommend that you set max degree of parallelism to 1 for database
servers that host SharePoint Server 2010 databases. For more
information about how to set max degree of parallelism, see max
degree of parallelism
Option(http://go.microsoft.com/fwlink/?LinkId=189030).
1
Workload
This section describes the workload, which is the demand on the farm that includes the number of users, and the usage characteristics.
Workload Characteristics
Value
Average Requests per Second (RPS)
64
267
Workload Characteristics
Value
Average RPS at peak time (11 AM-3 PM)
112
Total number of unique users per day
69,814
Average concurrent users
639
Maximum concurrent users
1186
Total # of requests per day
4,045,677
This table shows the number of requests for each user agent.
User Agent
Requests
Percentage of Total
Outlook Social Connector Browser
1,808,963
44.71%
Search (crawl)
704,569
17.42%
DAV
459,491
11.36%
OneNote
266,68
6.59%
Outlook
372,574
9.21%
Browser
85,913
2.12%
Word
38,556
0.95%
Excel
30,021
0.74%
Office Web Applications
20,314
0.50%
268
User Agent
Requests
Percentage of Total
SharePoint Workspaces
19,017
0.47%
Dataset
This section describes the case study farm dataset that includes database sizes and Search indexes.
Dataset Characteristics
Value
Database size (combined)
1.5 TB
BLOB size
1.05 TB
Number of content databases
64
Number of Web applications
1
Number of site collections
87,264
Number of sites
119,400
Search index size (number of items)
5.5 million
Health and Performance Data
This section provides health and performance data that is specific to the case study environment.
General Counters
269
Metric
Value
Availability (uptime)
99.61%
Failure Rate
0.39%
Average memory used
0.79 GB
Maximum memory used
4.53 GB
Search Crawl % of Traffic (Search client requests / total requests)
17.42%
The following charts show average CPU utilization and latency for this environment.
270
271
In this document, latency is divided into four categories. The 50th percentile latency is typically used to measure the server’s
responsiveness. It means that half of the requests are served within that response time. The 95th percentile latency is typically used to
measure spikes in server response times. It means that 95% of requests are served within that response time, and therefore, 5% of the
requests experience slower response times.
Database Counters
Metric
Value
Read/Write Ratio (IO Per Database)
99.854 : 0.146
Average Disk queue length
8.702
Disk Queue Length: Reads
30.518
272
Metric
Value
Disk Queue Length: Writes
4.277
Disk Reads/sec
760.886
Disk Writes/sec
180.644
SQL Compilations/second
3.129
SQL Re-compilations/second
0.032
SQL Locks: Average Wait Time
125 ms
SQL Locks: Lock Wait Time
33.322 ms
SQL Locks: Deadlocks Per Second
0
SQL Latches: Average Wait Time
0 ms
SQL Cache Hit Ratio
20.1%
273
Результаты тестирования производительности и емкости и
рекомендации (SharePoint Server 2010)
В этом разделе представлен ряд технических документов и статей, описывающих влияние на производительность и емкость,
оказываемое определенными наборами включенных в Microsoft SharePoint Server 2010 компонентов. Эти документы и статьи
содержат сведения о характеристиках производительности и емкости компонента и о его тестировании Microsoft, в том числе:
 Тестирование характеристик фермы

Результаты тестирования

Рекомендации

Диагностика проблем производительности и масштабируемости
Примечание.
Технические документы обновляются и публикуются повторно в виде статей. Загруженный с этой страницы технический документ после
его публикации в виде статьи может содержать обновленные сведения.
Прежде чем приступать к чтению этих технических документов и статей, необходимо ознакомиться с основными понятиями
управления емкостью в SharePoint Server 2010. Дополнительные сведения см. в статье Capacity management and sizing for
SharePoint Server 2010 (на английском языке).
В следующей таблице описаны доступные технические документы и статьи. Технические документы доступны в виде документов
Microsoft Word на странице рекомендаций и результатов тестирования емкости и производительности SharePoint Server 2010
(Возможно, на английском языке).
274
Тема
Описание
Access
Описание влияния использования служб Access Services на
применяемые топологии SharePoint Server 2010. См. статью Estimate
performance and capacity requirements for Access Services in
SharePoint Server 2010 (на английском языке).
Службы Business Connectivity Services
Описание влияния использования служб Business Connectivity Services
на применяемые топологии SharePoint Server 2010. Загрузите
технический документ (Возможно, на английском языке)
(BCSCapacityPlanningDoc.docx).
Обзор типов кэша
Сведения о том, как три типа кэша SharePoint Server 2010 позволяют
масштабировать и расширять возможности продукта в соответствии с
потребностями бизнес-приложения. Загрузите технический документ
(Возможно, на английском языке)
(SharePointServerCachesPerformance.docx).
Службы Excel в Microsoft SharePoint Server 2010
Руководство по планированию для Excel в Microsoft SharePoint Server
2010. См. статью Estimate performance and capacity requirements for
Excel Services in SharePoint Server 2010 (на английском языке).
Службы InfoPath Forms
Описание влияния использования служб InfoPath Forms на
применяемые топологии SharePoint Server 2010. Загрузите технический
документ (Возможно, на английском языке)
(InfoPath2010CapacityPlanningDoc.docx).
Большие списки
Описание производительности больших библиотек документов и
списков. Этот документ относится к SharePoint Server 2010, однако
обсуждаемые вопросы регулирования и ограничений, также относятся к
Microsoft SharePoint Foundation 2010. Загрузите технический документ
(Возможно, на английском языке)
(DesigningLargeListsMaximizingListPerformance.docx).
275
Тема
Описание
Крупномасштабные хранилища документов
Описание производительности крупномасштабных хранилищ документов
в связи с SharePoint Server 2010. Загрузите технический документ
(Возможно, на английском языке)
(LargeScaleDocRepositoryCapacityPlanningDoc.docx).
Личные сайты и социальные компоненты
Описание влияния использования личных сайтов и других социальных
компонентов на применяемые топологии SharePoint Server 2010.
Загрузите технический документ (Возможно, на английском языке)
(MySitesSocialComputingCapacityPlanningDoc.docx).
Office Web Apps
Описание влияния использования Office Web Apps на применяемые
топологии SharePoint Server 2010. Загрузите технический документ
(Возможно, на английском языке)
(OfficeWebAppsCapacityPlanningDoc.docx).
PerformancePoint Services
Описание влияния использования служб PerformancePoint Services на
применяемые топологии SharePoint Server 2010. См. статью Оценка
требований производительности и емкости для PerformancePoint
Services.
Поиск
Сведения о планировании емкости для различных систем поиска в
SharePoint Server 2010, включая малые, средние и большие фермы.
Загрузите технический документ (Возможно, на английском языке)
(SearchforSPServer2010CapacityPlanningDoc.docx).
Если в качестве решения для поиска в корпоративной среде используется
FAST Search Server 2010 для SharePoint, см. Plan for performance and
capacity (FAST Search Server 2010 for SharePoint).
Службы Visio
Описание влияния использования служб Visio на применяемые
топологии SharePoint Server 2010. Загрузите технический документ
(Возможно, на английском языке)
276
Тема
Описание
(VisioServicesCapacityPlanningDoc.docx).
Веб-аналитика
Описание влияния использования веб-аналитики на применяемые
топологии SharePoint Server 2010. См. статью Capacity requirements for
Web Analytics Shared Service in SharePoint Server 2010 (на
английском языке).
Управление веб-контентом
Сведения о планировании производительности и емкости для решения
управления веб-контентом. См. статью Оценка требований к
производительности и емкости для управления веб-контентом в
SharePoint Server 2010.
Word Automation Services
Сведения о планировании емкости для Word Automation Services в
SharePoint Server 2010. Загрузите технический документ (Возможно, на
английском языке) (WASCapacityPlanningDoc.docx).
Рабочий процесс
Описание влияния использования рабочих процессов на применяемые
топологии SharePoint Server 2010. Загрузите технический документ
(Возможно, на английском языке) (WorkflowCapacityPlanningDoc.docx).
277
Estimate performance and capacity requirements for Access
Services in SharePoint Server 2010 (на английском языке)
This article provides guidance on the footprint that usage of Access в Microsoft SharePoint Server 2010 has on topologies that are
running Microsoft SharePoint Server 2010.
In this article:
 Test farm characteristics

Test results

Recommendations

Troubleshooting
Test farm characteristics
This section describes the dataset that was used during the testing; the workloads that were placed on the product during performance
gathering; the hardware that was used during the testing; and the topology for how that hardware was deployed.
Dataset
Access capacity and performance is highly dependent on the makeup of the applications that are hosted on the service. The size of tables
and the complexity of queries often have the most effect on capacity and performance. The testing used representative sizes and
complexities, but every application and dataset is different. The capacity and performance will depend on the applications that are being
used, their specific complexity, and the data size.
To evaluate the capacity profile, Access applications were simulated on a farm dedicated to Access (no other SharePoint tests were
running). The farm contained the following representative sites:
 1,500 Access applications that have a “Small” size profile; 100 items maximum per list.

1,500 Access applications that have a “Medium” size profile; 2,000 items maximum per list.

1,500 Access applications that have a “Large” size profile; 10,000 items maximum per list.
278
Each application is made up of multiple lists, and the other lists are appropriately sized based on this largest list. Access can handle more
data than 10,000 items. This number for the “Large” profile was chosen because it was expected that larger applications would not be
common.
The applications were evenly distributed among the following applications:
 Contacts A simple contact management application, dominated by a single list.

Projects A simple task and project tracking applications, dominated by two lists (projects and tasks associated with each project).

Orders A simple order entry system, similar to the Northwind Traders sample of Microsoft Access, but scaled down, and included
many interrelated lists (orders, order details, invoices, invoice details, purchase orders, purchase order details, and so on).
Workload
To simulate application usage, workloads were created to perform one or more of the following operations:
 Opening forms

Paging through the forms

Filtering and sorting data sheets

Updating, deleting and inserting records

Publishing application
 Render reports
Each workload includes “think time” between user actions, ranging from 5 to 20 seconds. This differs from other SharePoint capacity
planning documents. Access is stateful; memory cursors and record sets were maintained between user interactions. It was important to
simulate a full user session and not merely individual requests. For a single user workload, there is an average of two requests per
second.
The following table shows the percentages used to determine which application and which size of application to use.
Small
Medium
Large
Contacts
16%
10%
9%
Projects
18%
12%
10%
Orders
11%
8%
6%
279
Green and red zone definitions
For each configuration, two tests were ran to determine a “green zone” and a “red zone.” The green zone is the recommended throughput
that can be sustained. The red zone is the maximum throughput that can be tolerated for a short time, but should be avoided.
The green zone was defined as a point at which the test being run consumes at most half the bottlenecking resource. In this case, the
bottlenecking resource was %CPU on any of the three tiers: front-end Web server, application server (Access Data Services), or database
server (SQL Server). First, the bottleneck was identified for a particular configuration. If the bottleneck was Access Data Services CPU, we
made sure that the green zone test consumed CPU on the Access Data Services computers in a range between 40 and 50 percent.
For the red zone, a point was selected at which the maximum throughput was reached. This proved to be a CPU range between 80 and
90 percent. When searching for bottleneck, we looked at %CPU, memory usage (private bytes), disk queue length, network I/O, and other
resources that could result in a bottleneck.
Both the green and red zone tests were run for 1 hour at a fixed user load.
Your results might vary
The specific capacity and performance figures presented in this article will differ from figures in a real-world environment. This simulation
is only an estimate of what actual users might do. The figures presented are intended to provide a starting point for the design of an
appropriately scaled environment. After you have completed the initial system design, you should test the configuration to determine
whether the system will support the factors in your environment.
Hardware setting and topology
Lab Hardware
To provide a high level of test-result detail, several farm configurations were used for testing. Farm configurations ranged from one to four
front-end Web servers, one to four application servers (if there is Access or Access Data Services), and a single database server
computer that is running Microsoft SQL Server 2008. In addition, testing was performed by using four client computers. All server
computers were 64-bit. All client computers were 32-bit.
The following table lists the specific hardware that was used for the testing.
Machine role
CPU
Memory
Network
Disk
Front-end Web server
2 processor, 4 core 2.33 GHz
8 GB
1 gig
2 spindles
RAID 5
280
Machine role
CPU
Memory
Network
Disk
Application server (Access Data Services)
2 processor, 4 core 2.33 GHz
8 GB
1 gig
2 spindles
RAID 5
Database server (SQL Server)
4 processor, 4 core 2.6 GHz
32GB
1 gig
Direct
Attached
Storage
(DAS)
attached
RAID 0 for
each
Logical
Unit
Number
(LUN)
Topology
From our experience, CPU on the application sever tier, where Access Data Services is running, is an important limiting factor for
throughput. We varied our topology by adding additional Access Data Services computers until it was no longer the bottleneck, and then
added a front-end Web server to obtain even more throughput.
 1x1: One front-end Web server computer to one Access Data Services computer

1x2: One front-end Web server computer to two Access Data Services computers

1x3: One front-end Web server computer to three Access Data Services computers

1x4: One front-end Web server computer to four Access Data Services computers

2x1: Two front-end Web server computers to one Access Data Services computer

2x2: Two front-end Web server computers to two Access Data Services computers

2x4: Two front-end Web server computers to four Access Data Services computers
281
The computer running SQL Server is a relatively strong computer and at no time did it become the bottleneck (although it started to
approach CPU saturation on our 2x4 test), so we did not vary this in our topologies. Depending on the queries that are a part of a realworld application mix, it is expected that the database server (SQL Server) tier could become the bottleneck.
Reporting Services was running in connected mode for all of our tests, running in the application server (Access Data Services) tier.
Test results
The following tables show the test results of Access. For each group of tests, only certain specific variables are changed to show the
progressive impact on farm performance.
All the tests reported in this article were conducted with think time or wait time. This differs from the capacity planning results for other
parts of SharePoint.
For information about bottlenecks of Access, see Common bottlenecks and their causes later in this article.
Overall scale
The following table and graph summarize the impact of adding additional front-end Web servers and dedicated Active Data Services
computers to the farm. These throughput numbers are specifically for the Active Data Services computers. They do not reflect the impact
on the overall farm.
Topology
Baseline solution maximum (RPS)
Baseline recommended
(RPS)
1x1
25
15
1x2
54
29
1x3
82
45
1x4
88
48
2x1
25
15
2x2
55
29
2x4
116
58
282
283
Recommended results
The following graph shows the results for recommended sustainable throughput.
284
As described earlier in this article, adding the fourth Access Data Services computer shifts the bottleneck to the front-end Web server, and
that adding a second front-end Web server resolves the resource constraint on the front-end Web server tier. This would imply, that 1x1,
1x2, and 1x3 are reasonable configurations. However, when the fourth Access Data Services computer is added, a front-end Web server
should also be added. Because scaling is in a linear manner (straight line between from 1x1 to 1x4), it can be assumed that the addition of
a seventh Access Data Services computer would also imply the addition of a third front-end Web server, and so on, to satisfy the needs of
the farm.
Remember that these results are based on a simulated work load only, and that an actual deployment should be monitored to find the
point at which additional front-end Web servers are needed to support additional Access Data Services computers. Also, the front-end
Web servers are dedicated to Access, and in reality the front-end Web servers are likely shared with other SharePoint workloads. The
following graph shows the results.
285
The following graph shows the response time at this throughput level. The response time is very fast, at less than ¼ second on average
per request.
286
These results show that the SQL Server computer was not a bottleneck, because adding a second front-end Web server resolved the
resource shortage, and the SQL Server CPU was always less than 50 percent. However, be aware that the instance of SQL Server is
287
shared with other SharePoint services and SharePoint itself, and so the cumulative effect might drive CPU or disk I/O queue lengths to the
point that they do become a bottleneck.
Maximum
The following graph shows the results, in which throughput was pushed beyond what could be sustained.
In this graph we see that again a second front-end Web server was needed to maximum the usefulness of the fourth Access Data
Services computer. Again, your results might vary, because this is highly dependent on the applications and their usage patterns.
288
289
In this case, the response time is increased, as the overall system is under stress. However, these levels are still approximately one
second, and acceptable to most users.
It might seem odd that with four Access Data Services computers, two front-end Web servers have an increased response time than one
front-end Web server. This is because the overall throughput of the system is increased with two front-end Web servers.
290
SQL Server is again not a limiting factor here, because adding the second front-end Web server put us back on a linear scaling line.
However, we are reaching almost 90 percent CPU usage on the instance of SQL Server. Therefore, there is very little headroom
remaining. If we were to add a fifth Access Data Services computer, the SQL Server computer likely would have become the bottleneck.
291
Detailed results
The following tables show the detailed results for the recommended configurations.
292
Overall
1x1
1x2
1x3
1x4
2x1
2x2
2x4
Req/Sec
14.96
28.76
45.22
48.01
14.85
28.77
58.02
Tests/Sec
2.00
3.81
6.11
6.42
1.99
3.81
7.80
Average Latency
235.80
241.21
247.21
244.87
240.70
242.26
250.94
Average front-end Web server 1x1
tier
1x2
1x3
1x4
2x1
2x2
2x4
%CPU
13.82
24.40
41.02
43.62
6.31
12.48
26.18
Max w3wp Private Bytes
9.46E+08
2.31E+08
1.49E+09
1.55E+09
8.43E+08
9.84E+08
1.19E+09
Average application server
(Access Data Services) tier
1x1
1x2
1x3
1x4
2x1
2x2
2x4
%CPU
46.30
42.83
43.74
34.51
46.56
43.45
42.13
%CPU w3wp
33.61
31.15
30.71
24.29
33.48
31.64
29.72
%CPU RS
8.62
7.94
9.17
6.84
9.03
8.02
8.71
Max total Private Bytes
4.80E+09
4.89E+09
4.91E+09
4.62E+09
5.32E+09
4.82E+09
5.07E+09
Max w3wp Private Bytes
2.10E+09
1.97E+09
2.04E+09
1.86E+09
2.00E+09
2.00E+09
2.07E+09
Max RS Private Bytes
1.78E+09
2.00E+09
1.97E+09
1.86E+09
2.30E+09
1.89E+09
2.02E+09
293
Database server (SQL Server) 1x1
tier (single computer)
1x2
1x3
1x4
2x1
2x2
2x4
%CPU
12.07
18.64
32.53
36.05
9.89
21.42
47.46
Avg Private Bytes
2.96E+10
3.22E+10
3.25E+10
3.25E+10
2.89E+10
3.22E+10
3.25E+10
Max Private Bytes
3.26E+10
3.25E+10
3.25E+10
3.25E+10
3.25E+10
3.25E+10
3.25E+10
1.18
1.64
1.77
0.67
1.24
2.18
Avg Disk Queue Length Total 0.74
The following tables show the detailed results for the maximum configurations.
Overall
1x1
1x2
1x3
1x4
2x1
2x2
2x4
Req/Sec
14.96
28.76
45.22
48.01
14.85
28.77
58.02
Tests/Sec
2.00
3.81
6.11
6.42
1.99
3.81
7.80
Average Latency
235.80
241.21
247.21
244.87
240.70
242.26
250.94
Average front-end Web server 1x1
tier
1x2
1x3
1x4
2x1
2x2
2x4
%CPU
13.82
24.40
41.02
43.62
6.31
12.48
26.18
Max w3wp Private Bytes
9.46E+08
2.31E+08
1.49E+09
1.55E+09
8.43E+08
9.84E+08
1.19E+09
294
Average application server
(Access Data Services) tier
1x1
1x2
1x3
1x4
2x1
2x2
2x4
%CPU
46.30
42.83
43.74
34.51
46.56
43.45
42.13
%CPU w3wp
33.61
31.15
30.71
24.29
33.48
31.64
29.72
%CPU RS
8.62
7.94
9.17
6.84
9.03
8.02
8.71
Max total Private Bytes
4.80E+09
4.89E+09
4.91E+09
4.62E+09
5.32E+09
4.82E+09
5.07E+09
Max w3wp Private Bytes
2.10E+09
1.97E+09
2.04E+09
1.86E+09
2.00E+09
2.00E+09
2.07E+09
Max RS Private Bytes
1.78E+09
2.00E+09
1.97E+09
1.86E+09
2.30E+09
1.89E+09
2.02E+09
Database server (SQL Server) 1x1
tier (single computer)
1x2
1x3
1x4
2x1
2x2
2x4
%CPU
12.07
18.64
32.53
36.05
9.89
21.42
47.46
Avg Private Bytes
2.96E+10
3.22E+10
3.25E+10
3.25E+10
2.89E+10
3.22E+10
3.25E+10
Max Private Bytes
3.26E+10
3.25E+10
3.25E+10
3.25E+10
3.25E+10
3.25E+10
3.25E+10
1.18
1.64
1.77
0.67
1.24
2.18
Avg Disk Queue Length Total 0.74
Recommendations
This section provides general performance and capacity recommendations.
Access capacity and performance is highly dependent on the makeup of the applications that are hosted on the service. The size of tables
and the complexity of queries often have the most effect. The testing used representative sizes and complexities, but every application
295
and dataset is different. Therefore, the capacity and performance will depend on the applications in use, their specific complexity, and the
data size.
Hardware recommendations
Access uses standard hardware for both front-end Web servers and application servers; no special requirements are necessary. General
SharePoint Server 2010 guidelines for CPU number, speed, and memory are applicable for computers in the application server (Access
Data Services) tier.
Scaled-up and scaled-out topologies
To increase the capacity and performance of one of the starting-point topologies, you can do one of two things. You can either scale up by
increasing the capacity of your existing servers or scale out by adding additional servers to the topology. This section describes the
general performance characteristics of several scaled-out topologies.
The sample topologies represent the following common ways to scale out a topology for an Access scenario:
 To provide for more user load, check the CPU for the existing Access application servers. Add additional CPUs or cores, or both, to
these servers if it is possible. Add more Access server computers as needed. This can be done to the point that the front-end Web
server has become the bottleneck, and then add front-end Web servers as needed.

In our tests, memory on the front-end Web server tier and application server (Access Data Services) tier was not a bottleneck.
Depending on the size of the result sets, memory could become an issue. However, we do not expect that to be the norm. Track the
private bytes for the Access Data Services w3wp process, as described here.

In our tests, SQL Server was not a bottleneck. However, our tests were run in isolation from other SharePoint Server 2010 services.
SQL Server CPU and disk I/O should be monitored and additional servers or spindles added as needed.
Performance-related Access Services settings
One way to control the performance characteristics of Access is to limit the size and complexity of queries that can be performed. Access
provides a set of configurable throttles for controlling queries. Each of the following queries can be set through SharePoint Central
Administration. (In the Application Management section, click Manage Service Applications, and then click Access.)
In general, how much data that has to be retrieved from SharePoint to perform a query will have a significant effect on performance. This
can be controlled in several ways. First, the inputs to a query can be limited:
 Maximum Sources per Query
 Maximum Records per Table
Second, the resulting size of a query can be limited:
296

Maximum Columns per Query

Maximum Rows per Query
 Allow Outer Joins
In addition to the size of the query (data size in and out), the processing complexity on the data can be controlled, to reduce the CPU load
on the application server (Access Data Services) tier:
 Maximum Calculated Columns per Query
 Maximum Order by Clauses per Query
Obviously, the previous settings will affect the applications that can be run on the server. For example, if an application is written with 40
output columns from a query, and the settings are below this level, the application will throw a runtime error. A balance between user need
and acceptable performance must be struck, and is highly dependent on the kind of Access applications that are expected to be run on
the farm.
One additional, more extreme measure can be taken. SharePoint Server 2010 supports a set of query operations natively, which Access
augments to cover a broader set of application scenarios. For Access to improve queries from SharePoint, there is the potential that a
large amount of data might have to be retrieved from the SharePoint content database. Instead, Access can be set to stick with only query
operations, which can be natively supported by SharePoint. Therefore, avoiding the data fetch required for more complex operations:
 Allow Non-Remotable Queries
Optimizations
Common bottlenecks and their causes
During performance testing, several different common bottlenecks were revealed. A bottleneck is a condition in which the capacity of a
particular constituent of a farm is reached. This causes a plateau or decrease in farm throughput.
The table in Troubleshooting later in this article lists some common bottlenecks and describes their causes and possible resolutions.
Performance monitoring
To help you determine when you have to scale up or scale out the system, use performance counters to monitor the health of the system.
Use the information in the following tables to determine which performance counters to monitor, and to which process the performance
counters should be applied.
Front-end Web servers
The following table shows performance counters and processes to monitor for Web servers in your farm.
297
Performance counter
Apply to object
Notes
% Processor Time
Processor(_Total)
Shows the percentage of
elapsed time that this
thread used the processor
to execute instructions.
Private Bytes
Process(w3wp)
This value should not
approach the Max Private
Bytes set for w3wp
processes. Iif it does,
additional investigation is
needed into what
component is using the
memory.
Access Data Services
The following table shows performance counters and processes to monitor for application servers, or Access Data Services (Access Data
Services) in this case, within your farm.
Performance counter
Apply to object
Notes
% Processor Time
Processor(_Total)
Shows the percentage of
elapsed time that this
thread used the processor
to execute instructions.
% Processor Time
Process(w3wp)
The Access Data Services
runs within its own w2wp
process, and it will be
obvious which w2wp
process this is as it will be
298
Performance counter
Apply to object
Notes
getting the bulk of the CPU
time.
Avg. Disk Queue Length
PhysicalDisk(_Total)
Watch for too much disk
writing because of logging.
% Processor Time
Process(ReportingServicesService)
Reports are handled by
отчетов SQL Server. If too
many reports are being
run, or if the reports are
very complex, then the
CPU and Private Bytes for
this process will be high.
Private Bytes
Process(w3wp)
Access caches the results
of queries in memory, until
the user’s session expires
(the time-out for which is
configurable). If a large
amount of data is being
processed through the
Access Data Services,
memory consumption for
the Access Data Services’
w3wp will increase.
Private Bytes
Process(ReportingSrevicesService)
Reports are handled by
отчетов SQL Server. If too
many reports are being
run, or reports are very
complex, the CPU and
Private Bytes for this
process will be high.
299
Database servers
The following table shows performance counters and processes to monitor for database servers in your farm.
Performance counter
Apply to object
Notes
% Processor Time
Processor(_Total)
Shows the percentage of
elapsed time that this
thread used the processor
to execute instructions.
% Processor Time
Process(sqlservr)
Average values larger than
80 percent indicate that
processor capacity on the
database server is
insufficient.
Private Bytes
Process(sqlservr)
Shows the average
amount of memory being
consumed by SQL Server.
Avg. Disk Queue Length
PhysicalDisk(_Total)
Shows the average disk
queue length; the
database requests waiting
to be committed to disk.
This is often a good
indicator that the instance
of SQL Server is becoming
overloaded, and that
possibly additional disk
spindles would help
distribute the load.
300
Troubleshooting
The following table lists some common bottlenecks and describes their causes and possible resolutions.
Bottleneck
Cause
Resolution
Access Data Services CPU
Access depends on a large amount Increase the number of CPUs or cores, or both, in the existing
of processing in the application
Access Data Services computers. Add additional Access Data
server tier. If a 1x1, 1x2, or 1x3
Services computers if possible.
configuration is used, the first
bottleneck encountered will likely be
the CPU on the Access Data
Services servers.
Web server CPU usage
When a Web server is overloaded
with user requests, average CPU
usage will approach 100 percent.
This prevents the Web server from
responding to requests quickly and
can cause timeouts and error
messages on client computers.
Database server disk I/O
When the number of I/O requests to Distributing data files across multiple physical drives allows
for parallel I/O. The blog SharePoint Disk Allocation and Disk
a hard disk exceeds the disk’s I/O
capacity, the requests will be queued. I/O (http://go.microsoft.com/fwlink/?LinkId=129557) contains
useful information about resolving disk I/O issues.
As a result, the time to complete
each request increases.
отчетов CPU utilization
The отчетов process is using a large Dedicate a computer to отчетов, taking load from the
share of the CPU resources.
application server (Access Data Services) tier (connected
mode) or the front-end Web server tier (local mode).
301
This issue can be resolved in one of two ways. You can add
more Web servers to the farm to distribute user load, or you
can scale up the Web server or servers by adding higherspeed processors.
Estimate performance and capacity requirements for Excel
Services in SharePoint Server 2010 (на английском языке)
This article describes the effects of using Excel в Microsoft SharePoint Server 2010 on topologies running Microsoft SharePoint Server
2010. You can use this information to better scale your deployments based on your latency and throughput requirements.
Примечание.
It is important to be aware that the specific capacity and performance figures presented in this article will differ from the figures in realworld environments. The figures presented are intended to provide a starting point for the design of an appropriately scaled environment.
After you have completed your initial system design, test the configuration to determine whether the system will support the needs of your
environment.
In this article:
 Test farm characteristics

Test Results
 Recommendations
For general information about how to plan and run your capacity planning for SharePoint Server 2010, see Capacity management and
sizing for SharePoint Server 2010 (на английском языке).
Test farm characteristics
This section describes the dataset, workloads, hardware settings, topology, and test definitions that were used during the performance
and capacity testing of Excel.
302
Dataset
Excel capacity and performance is highly dependent on the makeup of the workbooks that are hosted on the service. The size of the
workbook and the complexity of calculations have the most impact. Our testing used representative sizes and complexities, but every
workbook is different, and your capacity and performance depends on the actual workbooks you use, and their specific size and
complexity.
We simulated Excel workbooks on a farm dedicated to Excel to evaluate our capacity profile. Note that no other SharePoint Server tests
were running during our capacity profile tests. Within this farm, we used three buckets of workbooks – Small, Large, and Very Large –
based on workbook size and complexity:
Workbook Characteristics
Small
Large
Very
Large
Sheets
1-3
1-5
1-20
Columns
10-20
10-500
10-1,000
Rows
10-40
10-10,000
10030,000
Calculated Cells
0-20%
0-70%
0-70%
Number of Formats
1-10
1-15
1-20
Tables
0-1
0-2
0-5
Charts
0-1
0-4
0-4
Workbook Uses External Data
0%
20%
50%
Workbook Uses a Pivot Table
0%
3%
3%
Workbook Uses Conditional Formats
0%
10%
20%
303
This test farm included 2,000 SharePoint Server sites. Each site contained one small, one large, and one very large workbook. The
distribution of the workbooks on the SharePoint Server pages was 10% small workbooks and 90% large and very large workbooks.
Additionally, the test farm dataset included SharePoint Server pages that contained 1-5 Excel Web Parts.
Workload
To simulate application usage, workloads were created to perform one or more of the following operations:
Action Mix
Small Workbook
Large Workbook
View
50%
70%
Edit
35%
15%
Collaborative Viewing
10%
10%
Collaborative Editing
5%
5%
In addition, 17% of all the workbooks included external data. For large and very large workbooks that included external data, refreshes
were performed 80% of the time; small workbooks do not include external data.
Each workload includes think time between user actions of 10 seconds. Think time refers to user action delays that simulate how long a
user might take to perform the actions. This differs from other SharePoint Server 2010 capacity planning documents. Excel is stateful —
the workbook is maintained in memory between user interactions — making it important to simulate a full user session and not merely
individual requests. On average, there are 0.2 requests per second for a single user workload.
We randomly selected one of the 2,000 sites to run the test for each workload. We used the percentages in the following table to select
application and application size, within that site.
Workbook Selection
Use Percentage
Small Workbook
30%
Large Workbook
55%
Dashboard
10%
304
Workbook Selection
Use Percentage
Very Large Workbook
5%
Green and Red Zone definitions
For each configuration two zones were determined before throughput tests were performed. One zone was the green zone or
recommended zone in which throughput can be sustained. The other zone was the red zone or maximum zone in which throughput can
be tolerated for a short time but should be avoided.
To determine our red and green zone user loads, we first conducted a step test and then stopped when the following conditions were met:
 Green zone We stopped at the point when any of the computers in our farm (Web front-end, вычислений Excel, or Microsoft SQL
Server) exceeded 50% CPU usage or the response time for the overall system exceeded 1 second.

Red Zone We stopped at the point where the successful RPS for the вычислений Excel computers in the farm was at a maximum.
Past this point, the overall throughput for the farm started to decrease and/or we would start to see failures from one of the tiers. Often
the maximum private bytes in вычислений Excel would be exceeded when throughput was in the red zone.
After conducting the step tests, we retreated from these maximum values to run a longer constant load test of 1 hour. We stopped the
green zone test when 75% of the load was used. We peaked in the red zone step test when we used 65% of the load. If the green zone
test was limited by memory, and the CPU usage percentage never exceeded 50%, we instead used 75% of the load number calculated
for the red zone.
The average response time was less than .25 seconds for both green and red zones, and for both scale-out and scale-up tests.
Hardware Settings and Topology
This section describes the kinds of computer hardware we used in our lab and the farm configuration topologies that we used in our tests.
Lab Hardware
Several farm configurations were used for our testing to provide a high level of test-result detail. The farm configurations ranged from one
to three Web front-end servers, one to three application servers for Excel and вычислений Excel, and a single database server computer
that is running Microsoft SQL Server 2008. Additionally, our tests used four client computers. All servers were 64-bit, and the client
computers were 32-bit.
The following table lists the specific hardware that we used for testing.
305
Machine Role
CPU
Memory
Network
Web front-end server
2 proc/4 core 2.33 GHz Intel Xeon
8 GB
1 gig
вычислений Excel
2 proc/4 core 2.33 GHz Intel Xeon
8 GB
1 gig
SQL Server
4 proc/4 core 2.6 GHz Intel Xeon
16 GB
1 gig
Topology
Our testing experience indicates that memory on the вычислений Excel tier and CPU on the Web front-end server tier are the most
important limiting factors for throughput. Be aware that your experience may vary. As a result, we varied the number of computer servers
in both tiers for the scale-out tests.
We deployed a topology of 1:1 for the вычислений Excel and Web front-end servers for the scale-up tests, and then varied the number of
processors and available memory in the вычислений Excel computers.
вычислений Excel is not especially demanding on the SQL Server instance running SharePoint Server 2010, as the workbook is read a
binary large object (BLOB) from SharePoint Server 2010 and put in memory on the вычислений Excel tier (and additionally disk cached).
At no time did SQL Server become a bottleneck. For all tests, bottleneck is defined as a state in which the capacity of a particular
component of a farm is reached.
Test Results
The following tables show the test results of Excel в Microsoft SharePoint Server 2010. For each group of tests, only certain specific
variables are changed to show the progressive effect on farm performance.
Note that all the tests reported on in this article were conducted with think or wait time (think time equals 10 seconds between user
actions). This differs from the capacity planning results for other parts of SharePoint Server 2010.
For information about Excel bottlenecks, see the Common bottlenecks and their causes section in this article.
Overall Scale
The table here summarizes the effect of adding additional Web Front-End and dedicated вычислений Excel computers to the farm. These
throughput numbers are specifically for the вычислений Excel computers, and do not reflect the effect on the overall farm.
306
Topology
Baseline Maximum (RPS)
Baseline Recommended
(RPS)
1x1
38
31
1x2
35
26
1x3
28
21
2x1
57
35
2x2
62
46
2x3
52
39
3x1
51
32
3x2
81
69
3x3
83
64
307
308
Recommended Results
The following chart shows our results for recommended sustainable throughput.
309
310
The previous chart shows that there is overhead associated with adding Web front-end computers to the farm. However, this is offset as
вычислений Excel computers are added. A single Web front-end became the bottleneck after adding two additional вычислений Excel
computers. This Web front-end bottleneck reversed any benefit that was gained from the additional capacity of adding a second and third
вычислений Excel computer. Also notice that three Web front-end computers did not add any more throughput, as вычислений Excel
became the limiting factor.
311
312
Notice in the previous chart that as Web front-end computers are added, the CPU load on each computer is reduced significantly. Note
too, that with two Web front-end computers and three вычислений Excel computers, the CPU load is reaching the maximum seen for a
single Web front-end computer. This implies that adding another вычислений Excel computer would make the Web front-end tier the
limiting factor. Remember that these results are for the “recommended” load. This is why the CPU load is maxing out at around 35%
instead of at an increased level.
Maximum Results
The following chart shows our results for maximum peak throughput.
313
314
Similar to our recommended results, we see that a single Web front-end computer is the limiting factor as we add a second and third
вычислений Excel computer. Also notice that exactly as with the recommended results, adding a third Web front-end computer does not
add to throughput as вычислений Excel is the limiting factor after the second Web front-end computer is added.
315
316
The results in the previous chart show that multiple Web front-end computers do not become as heavily loaded as a single Web front-end
computer configuration. This indicates that the вычислений Excel computers are the bottleneck after the second Web front-end computer
is added.
Detailed Results
This section shows details for the recommended and maximum results obtained in our tests.
Recommended Results
The following tables show the recommended results of our tests.
Overall
1x1
1x2
1x3
Client Successful RPS
30.56
34.55
31.67 26.03 45.94 68.37 20.71 38.82 63.70
Client Response Time (sec.)
0.22
0.18
0.19
0.16
0.19
0.20
0.15
0.15
0.17
TPS
1.58
1.77
1.61
1.40
2.38
3.54
1.08
2.03
3.25
Web Front-end Tier
1x1
1x2
1x3
3x2
3x3
37.64
33.84 14.61 23.95 36.90 7.54 13.12 21.75
% CPU (average over all Web Front- 33.73
end computers
вычислений
Excel Tier
1x1
% CPU
30.56
(average over
all вычислений
Excel
2x1
2x1
2x2
2x2
2x3
3x1
2x3
3x1
3x2
3x3
1x2
1x3
2x1
2x2
2x3
3x1
3x2
3x3
34.55
31.67
26.03
45.94
68.37
20.71
38.82
63.70
317
вычислений
Excel Tier
1x1
1x2
1x3
2x1
2x2
2x3
3x1
3x2
3x3
5.82E+09
5.79E+09
5.87E+09
6.09E+09
5.92E+09
5.79E+09
5.91E+09
5.85E+09
computers)
Peak Private
5.94E+09
Bytes
(maximum over
all вычислений
Excel
computers)
Maximum Results
The following tables show the maximum results of our tests.
Overall
1x1
1x2
1x3
Client Successful RPS
37.85
56.70
51.17 35.19 62.04 81.31 27.79 51.62 82.58
Client Response Time (sec.)
0.19
0.28
0.23
0.16
0.20
0.25
0.16
0.16
0.22
TPS
1.92
2.96
2.59
1.81
3.21
4.60
1.41
2.72
4.30
Web Front-end Tier
1x1
1x2
1x3
2x1
2x2
2x3
3x1
3x2
3x3
67.78
58.59 19.44 34.11 45.97 10.19 17.79 28.69
% CPU (average over all Web Front- 41.08
end computers
318
2x1
2x2
2x3
3x1
3x2
3x3
1x2
1x3
2x1
2x2
2x3
3x1
3x2
3x3
% CPU
24.99
(average over
all вычислений
Excel
computers)
18…44
10.96
23.57
20.56
17.77
18.97
17.04
18.10
Peak Private
Bytes
(maximum
over all
вычислений
Excel
computers)
5.85E+09
5.91E+09
5.88E+09
5.99E+09
6.502E+09
5.94E+09
5.94E+09
6.04E+09
вычислений
Excel Tier
1x1
5.91E+09
Scale Up Test results
We also measured the effect of adding CPUs and memory to the вычислений Excel tier. For these tests, a 1x1 topology was used.
319
Our results in the previous chart show that adding additional CPUs was helpful but did not significantly affect the overall throughput.
320
321
The red zone line in the previous chart shows however, that adding memory does have a significant effect on throughput, especially at
peak times. In this test, the same hardware was used throughout. However, the Maximum Private Bytes for the Excel process was limited.
Since workbooks are kept in memory, the size of the workbooks has a significant effect on how many workbooks, and also how many
users, any вычислений Excel computer can support.
Recommendations
This section provides general performance and capacity recommendations for hardware, Excel settings, common bottlenecks and
troubleshooting.
Note that Excel capacity and performance is highly dependent on the makeup of the workbooks that are hosted on the service. The size of
the workbook and the complexity of calculations have the most effect. Our testing used representative sizes and complexities, but every
workbook is different, and your capacity and performance depends on the specific size and complexity of the workbooks you use.
Hardware Recommendations
Excel uses standard hardware for both Web front-end servers and application servers, there are no special requirements. General
SharePoint Server 2010 guidelines on CPU number, speed, and memory are applicable for computers in the вычислений Excel tier. Note
that one of the first bottlenecks an вычислений Excel computer is likely to encounter is memory and this may require you to add
resources. Before you do, we recommend that you test with a representative set of workbooks from your organization, as the size and
complexity of workbooks have a large effect on how much more capacity the addition of memory is likely to have.
To increase the capacity and performance of one of the starting-point topologies, you can do one of two things. You can either scale up by
increasing the capacity of your existing servers or scale out by adding additional servers to the topology. This section describes the
general performance characteristics of several scaled-out topologies.
The sample topologies represent the following common ways to scale out a topology for an Excel scenario:
 To provide for more user load, check the CPU and memory for the existing Excel application servers. Add additional memory if the
CPU is not a concern, or add CPUs if memory is not a concern. If both memory and CPU are reaching their upper limits, additional
вычислений Excel computers may be necessary. Add additional вычислений Excel or application servers until the point that the Web
front-end servers become the bottleneck, and then add Web front-end servers as needed.

In our tests, SQL Server was not a bottleneck. Excel does not make large demands on the database tier, as workbooks are read and
written as whole documents, and also workbooks are held in memory throughout the user’s session.
322
Performance-Related Excel Settings
One of the ways to control the performance characteristics of Excel is to control how memory is used. Each of the global settings in the
following list are set through SharePoint Server 2010 Central Administration > Application Management: Manage Service Applications >
Excel > Global Settings:
 Maximum Private Bytes — By default, вычислений Excel will use up to 50% of the memory on the computer. If the computer is
shared with other services, it may make sense to lower this number. If the computer is not being shared and is dedicated to
вычислений Excel, and is indicating that memory may be a limiting factor, increasing this number may make sense. In any event,
experimenting by adjusting this number can guide the administrator to making the necessary changes in order to better scale up.

Memory Cache Threshold — вычислений Excel will cache unused objects (for example, read-only workbooks for which all sessions
have timed out) in memory. By default, вычислений Excel will use 90% of the Maximum Private Bytes for this purpose. Lowering
this number can improve overall performance if the server is hosting other services in addition to вычислений Excel. Increasing this
number increases the chances that the workbook being requested will already be in memory and will not have to be reloaded from the
SharePoint Server content database.

Maximum Unused Object Age — By default, вычислений Excel will keep objects in the memory cache as long as possible. To
reduce the вычислений Excel memory usage, in particular with other services that are running on the same computer, it may make
more sense to impose a limit on how long objects are cached in memory.
There are also settings available to control the maximum size of a workbook and the lifetime of a session, which in turn control how long a
workbook is held in memory. These settings are associated with each trusted location and are not global. These settings can be set
through SharePoint Server 2010 Central Administration > Application Management: Manage Service Applications > Excel > Trusted
Locations, and then edit the settings for each trusted location in the Workbook Properties section on the Edit Trusted File Location page.

Maximum Workbook Size
 Maximum Chart or Image Size
By default, вычислений Excel is limited to 10 MB or smaller workbooks and 1 MB or smaller charts/images. Obviously using larger
workbooks and larger charts/images puts more strain on the available memory of the вычислений Excel tier computers. However, there
may be users in your organization that need these settings to be increased for вычислений Excel to work with their particular workbooks.
 Session Timeout — By decreasing the session time out, memory is made available for either the unused object cache or other
services faster.

Volatile Function Cache Lifetime — Volatile functions are functions that can change their value with each successive recalculation
of the workbook, for example date/time functions, random number generators, and so on. Because of the load this could generate on
the server, вычислений Excel does not recalculate these values for each recalculation, instead caching the last values for a short time
323
period. Increasing this lifetime can reduce the load on the server. However, this depends on having workbooks that use volatile
functions.

Allow External Data — вычислений Excel can draw on external data sources. However, the time that is required to draw upon the
external source can be significant, with potentially a large amount of data returned. If external data is allowed, there are several
additional settings that can help throttle the effect of this feature.
Common bottlenecks and their causes
During performance testing, several different common bottlenecks were revealed. Bottlenecks are defined as a state in which the capacity
of a particular component of a farm is reached. This causes a plateau or decrease in farm throughput.
The following table lists some common bottlenecks and describes their causes and possible resolutions.
Troubleshooting performance and scalability
Bottleneck
Cause
Resolution
вычислений Excel Memory
Excel holds each workbook in memory throughout the
user's session. A large number of workbooks, or large
workbooks, can cause вычислений Excel to consume
all available memory causing the actually consumed
"Private Bytes" to exceed "Maximum Private Bytes."
Scale Up with more
memory in the вычислений
Excel tier computers, or
Scale Out with the addition
of more вычислений Excel
computers. The choice will
partly depend on if CPU is
also reaching a maximum.
вычислений Excel CPU
Excel can depend on a large amount of processing in Increase the number of
the application tier, depending on the number and
CPUs and/or cores in the
complexity of workbooks.
existing вычислений Excel
computers, or add
вычислений Excel
computers.
Web server CPU usage
When a Web server is overloaded with user requests, This issue can be resolved
average CPU usage will approach 100 percent. This in one of two ways. You
prevents the Web server from responding to requests can add Web servers to
324
Bottleneck
Cause
Resolution
quickly and can cause timeouts and error messages
on client computers.
the farm to distribute user
load, or you can scale up
the Web server or servers
by adding faster
processors.
Performance monitoring
To help you determine when you have to scale up or scale out the system, use performance counters to monitor the health of the system.
Use the information in the following tables to determine which performance counters to monitor, and to which process the performance
counters should be applied.
Front-end Web server
The following table shows performance counters and processes to monitor for front-end Web servers in your farm.
Performance Counter
Apply to object
Notes
% Processor Time
Processor (w3wp)
Shows the percentage of
elapsed time that this
thread used the processor
to execute instructions.
% Processor Time
Processor (_Total)
Shows the percentage of
elapsed time that all
threads on the server
computer that used the
processor to execute
instructions.
Private Bytes
Process (w3wp)
This value should not
approach the Max Private
Bytes set for w3wp
325
Performance Counter
Apply to object
Notes
processes. If it does,
additional investigation is
needed into what
component is using the
memory.
вычислений Excel
The following table shows performance counters and processes to monitor for application servers, or in this case вычислений Excel,
within your farm.
Performance Counter
Apply to object
Notes
% Processor Time
Processor (_Total)
Shows the percentage of
elapsed time that all
threads on the server that
used the processor to
execute instructions.
% Processor Time
Processor (w3wp)
The вычислений Excel
runs within its own w3wp
process, and it will be
obvious which w3wp
process this is as it will be
getting the bulk of the CPU
time.
Average Disk Queue Length
PhysicalDisk(_Total)
Watch for too much disk
writing because of logging.
Private Bytes
Process(w3wp)
Excel caches workbooks in
memory, until the user's
326
Performance Counter
Apply to object
Notes
session expires (the time
out for which is
configurable). If a large
amount of data is being
processed through the
вычислений Excel, memory
consumption for the
вычислений Excel w3wp
will increase.
SQL Server
As we have previously described, Excel is light on the SQL Server tier, as workbooks are read once into memory on the вычислений
Excel tier during the user's session. Follow general SharePoint Server guidelines for monitoring and troubleshooting of the SQL Server
tier.
327
Оценка требований производительности и емкости для
PerformancePoint Services
В этой статье описывается воздействие от использования PerformancePoint Services на производительность топологий, в которых
выполняется Microsoft SharePoint Server 2010.
Примечание.
Необходимо отметить, что конкретные значения емкости и производительности, представленные в данной статье, могут отличаться от
значений в реальных средах. Представленные данные могут использоваться в качестве отправной точки при проектировании среды с
соответствующим масштабированием. После завершения первоначального этапа разработки системы протестируйте созданную
конфигурацию, чтобы убедиться, что система будет поддерживать факторы, характерные для данной среды.
Содержание:
 Тестирование характеристик фермы

Результаты тестирования
 Рекомендации
Общие сведения о планировании и выполнении планирования емкости для SharePoint Server 2010 см. в статье Capacity
management and sizing for SharePoint Server 2010 (на английском языке).
Тестирование характеристик фермы
Набор данных
Набор данных состоит из корпоративного портала, созданного с помощью SharePoint Server 2010 и PerformancePoint Services,
который содержит одну панель мониторинга среднего размера. Панель мониторинга состоит из двух фильтров, связанных с
328
одной системой показателей, двумя диаграммами и сеткой. Панель мониторинга создана на основе одного источника данных
аналитики Microsoft SQL Server 2008 (SSAS), использующего образец базы данных AdventureWorks для куба аналитики SQL
Server 2008.
В следующей таблице описываются типы и размеры каждого элемента панели мониторинга.
Имя
Описание
Размер
Фильтр № 1
Фильтр выбора элементов
7 элементов измерения
Фильтр № 2
Фильтр выбора элементов
20 элементов измерения
Система показателей
Система показателей
15 элементов измерения
по 4 столбца (2 ключевых
показателя эффективности)
Диаграмма № 1
График
3 ряда по 12 столбцов
Диаграмма № 2
Линейчатая диаграмма с накоплением
37 рядов по 3 столбца
Сетка
Аналитическая таблица
5 строк по 3 столбца
Средняя панель мониторинга использует шаблон "Заголовок и два столбца". Размер элементов панели мониторинга
настраивается автоматически или указывается в процентном соотношении относительно размера панели мониторинга. Каждый
элемент на панели мониторинга отображается с произвольным значением высоты и ширины (от 400 до 500 пикселей) для
имитации различий размеров окна веб-браузера. Поскольку диаграммы отображаются исходя из размеров окна веб-браузера,
возможность изменения высоты и ширины каждого элемента панели мониторинга является обязательной.
Сценарии и процессы тестирования
В этом разделе описываются сценарии тестирования и обсуждается процесс тестирования, используемый в каждом сценарии.
Подробные сведения, например результаты тестирования и конкретные параметры, приведены в разделах "Результаты
тестирования" настоящей статьи.
329
Имя теста
Описание теста
Отображение панели мониторинга и случайное изменение значения 1. Отображает панель мониторинга.
одного из двух фильтров пять раз через каждые 15 секунд.
2. Выбирает один из двух фильтров, случайным образом
выбирает значение фильтра и дожидается обновления
панели мониторинга.
3. Повторяет предыдущее действие еще четыре раза.
Отображение панели мониторинга, выбор диаграммы,
1. Отображает панель мониторинга.
разворачивание и сворачивание элемента диаграммы пять раз через 2. В случайном порядке выбирает элемент диаграммы и
каждые 15 секунд.
разворачивает его.
3. В случайном порядке выбирает другой элемент диаграммы
и сворачивает его.
4. В случайном порядке выбирает другой элемент диаграммы
и разворачивает его.
5. В случайном порядке выбирает другой элемент диаграммы
и сворачивает его.
Отображение панели мониторинга, выбор сетки, разворачивание и
сворачивание элемента сетки пять раз через каждые 15 секунд.
1. Отображает панель мониторинга. В случайном порядке
выбирает элемент сетки и разворачивает его.
2. В случайном порядке выбирает другой элемент сетки и
разворачивает его.
3. В случайном порядке выбирает другой элемент сетки и
сворачивает его.
4. В случайном порядке выбирает другой элемент сетки и
разворачивает его.
Использовался тестовый набор, состоящий из нескольких тестов со следующими процентными соотношениями.
330
Имя теста
Тестовый набор
Отображение панели мониторинга и случайное изменение значения 80 %
одного из двух фильтров пять раз.
Отображение панели мониторинга, выбор диаграммы,
разворачивание и сворачивание элемента диаграммы пять раз.
10 %
Отображение панели мониторинга, выбор сетки, разворачивание и
сворачивание элемента сетки пять раз.
10 %
Для создания набора веб-тестов и нагрузочных тестов, имитирующих изменение значений фильтров в случайном порядке
пользователями и переходы по сетками и диаграммам, использовались средства Microsoft Visual Studio 2008 Load Testing. В
тестах, описанных в этой статье, используются 15-секундные паузы между итерациями (время на обдумывание). Для реализации
средней двухсекундной задержки, требуемой для отображения системы показателей или отчета, применялась дополнительная
нагрузка. Среднее время ответа измерялось в течение 15 минут после первых 10 минут с момента запуска.
В каждой итерации теста учетная запись выбирается из 5 000 учетных записей, а IP-адрес — из 2 200 IP-адресов (с помощью
Visual Studio IP Switching).
Тестовый набор запускался два раза для одной и той же панели мониторинга среднего размера. При первом запуске тестового
набора для доступа к источнику данных использовалась автоматическая учетная запись службы, которая использует общую
учетную запись для запроса данных. Получаемые результаты идентичны для всех пользователей. Для повышения
производительности PerformancePoint Services может использовать кэширование. При втором запуске тестового набора для
доступа к источнику данных использовалась индивидуальная проверка подлинности пользователей, а куб аналитики SQL Server
был настроен для использования динамической безопасности. В этой конфигурации для запроса данных PerformancePoint
Services использует удостоверение пользователя. Поскольку результаты могли отличаться, нельзя было использовать
кэширование для совместного использования результатов разными пользователями. Если для аналитики не настроена
динамическая безопасность и роли аналитики, которым назначены пользователи и группы Microsoft Windows, являются
идентичными, можно использовать кэширование для индивидуальных удостоверений пользователей.
Настройки оборудования и топология
Оборудование лаборатории
331
Для получения детализированных результатов тестирования использовались разные конфигурации фермы. Конфигурации
фермы варьировались от одного до трех веб-серверов, от одного до четырех серверов приложений и с одним сервером баз
данных, запущенным на Microsoft SQL Server 2008. Для SharePoint Server 2010 был выбран вариант установки в организации по
умолчанию.
В следующей таблице перечислено оборудование, используемое при тестировании.
Веб-сервер
Сервер приложений
Компьютер, на
котором работает
SQL Server
Компьютер, на
котором работает
аналитики
Процессоры
2 процессора по 4 ядра с частотой
2,66 ГГц
2 процессора по 4 2 процессора по 4 4 процессора по 6
ядра с частотой 2,66 ядра с частотой 2,66 ядер с частотой 2,4
ГГц
ГГц
ГГц
ОЗУ
16 ГБ
32 ГБ
16 ГБ
64 ГБ
Операционная система
Windows Server 2008 R2
Корпоративная
Windows
Server 2008 R2
Корпоративная
Windows
Server 2008 R2
Корпоративная
Windows
Server 2008 R2
Корпоративная
Сетевой адаптер
1x1 гигабит
1x1 гигабит
1x1 гигабит
1x1 гигабит
Проверка подлинности
NTLM и Kerberos
NTLM и Kerberos
NTLM и Kerberos
NTLM и Kerberos
После масштабирования фермы на несколько веб-серверов для аппаратной балансировки нагрузки использовался метод
сходства адреса и источника. Этот метод записывает IP-адрес источника входящих запросов и узел службы, для которого
распределяется нагрузка, и выделяет для всех последующих транзакций один узел.
Топология
Начальная топология состоит из двух физических серверов, один из которых выступает в роли веб-сервера и сервераприложений, а второй — в роли сервера баз данных. Эта начальная топология считается топологией, состоящей из двух
компьютеров (2M), или топологией "1-0-1", где первое число — количество выделенных веб-серверов, второе число —
количество выделенных серверов приложений, а третье число — количество серверов баз данных.
332
Далее в настоящей статье веб-серверы также называются интерфейсными веб-серверами (WFE). Нагрузка применялась до
момента обнаружения ограничивающих факторов. Как правило, ограничивающим фактором на веб-сервере или сервере
приложений является ЦП, поэтому для устранения этого ограничения были добавлены дополнительные ресурсы.
Ограничивающие факторы и топологии существенно отличаются в зависимости от конфигурации проверки подлинности при
доступе к источнику данных (автоматическая учетная запись службы или индивидуальное удостоверение пользователя с
динамической защитой куба).
Результаты тестирования
Результаты измерений содержат три важных показателя, позволяющих определить емкость PerformancePoint Services.
Показатель
Описание
Число пользователей
Общее число пользователей по данным Visual Studio.
Запросов в секунду (RPS)
Общее число запросов в секунду по данным Visual Studio, в которое входят
все запросы, включая запросы статических файлов, например изображений и
таблиц стилей.
Представлений в секунду (VPS)
Общее число представлений, которое PerformancePoint Services может
обработать. Представление — это любой фильтр, система показателей, сетка
или диаграмма, отображаемая PerformancePoint Services, или любой вебзапрос к URL-адресу службы отображения, который содержит параметр
RenderWebPartContent или CreateReportHtml. Дополнительные сведения
о параметрах CreateReportHtml и RenderWebPartContent см. в документе,
содержащем спецификацию протокола PerformancePoint Services
RenderingService (Возможно, на английском языке)
(http://go.microsoft.com/fwlink/?linkid=200609&clcid=0x419) (Возможно, на
английском языке).
Для упрощения планирования емкости PerformancePoint Services можно
анализировать запросы по журналам служб IIS. При использовании этого
средства получаемое значение практически не зависит от формирования
333
Показатель
Описание
панели мониторинга. Панель мониторинга с двумя представлениями можно
сравнить с панелью мониторинга с десятью представлениями.
Совет.
Если для доступа к источнику данных используется автоматическая учетная запись службы, необходимо придерживаться следующего
соотношения выделенных серверов: один веб-сервер на каждые два сервера приложений, на которых запущены PerformancePoint
Services.
Совет.
Если источник данных настроен для индивидуальной проверки подлинности, необходимо придерживаться следующего соотношения
выделенных серверов: один веб-сервер на каждые четыре или более серверов приложений, на которых запущены PerformancePoint
Services.
Если число серверов приложений больше четырех, возможно, узким местом станет сервер аналитики. Рассмотрите возможность
мониторинга ЦП и времени обработки запросов к серверу аналитики, чтобы определить, следует ли масштабировать аналитики
на несколько серверов. Любая задержка обработки запроса на сервере аналитики приведет к существенному повышению
среднего времени ответа PerformancePoint Services (более двух секунд).
В следующей таблице приведены общие результаты для проверки подлинности с помощью автоматической учетной записи
службы и индивидуальной проверки подлинности пользователей при масштабировании с двух до семи серверов. Более
подробные результаты, содержащие дополнительные счетчики производительности, приведены в следующих разделах
настоящего документа.
Сводные данные для проверки подлинности с помощью автоматической учетной записи службы
334
Топология (WFE x APP x SQL)
Пользователи
Запросов в секунду
(RPS)
Просмотров в
секунду (VPS)
2M (1x0x1)
360
83
50
3M (1x1x1)
540
127
75
4M (1x2x1)
840
196
117
5M (1x3x1)
950
215
129
6M (2x3x1)
1250
292
175
7M (2x4x1)
1500
346
205
Сводные данные для индивидуальной проверки подлинности пользователей
Топология (WFE x APP x SQL)
Пользователи
Запросов в секунду
(RPS)
Просмотров в
секунду (VPS)
2M (1x0x1)
200
47
27
3M (1x1x1)
240
56
33
4M (1x2x1)
300
67
40
5M (1x3x1)
325
74
44
Топологии 2M и 3M
Чтобы оценить коэффициент использования оборудования на одну транзакцию и проанализировать кривую времени ответа,
нагрузочные тесты запускались четыре раза с повышающимися пользовательскими нагрузками (до максимальной нагрузки) в
топологиях 2M и 3M.
335
Проверка подлинности с помощью автоматической учетной записи службы
Число пользователей
50
150
250
360
Ср. для ЦП WFE/APP
19,20 %
57,70 %
94,00 %
96,70 %
RPS
18
53
83
83
Просмотров в секунду
10,73
31,72
49,27
49,67
Ср. время ответа (сек.)
0,12
0,15
0,38
2
336
Индивидуальная проверка подлинности пользователей
337
Число пользователей
50
100
150
200
Ср. для ЦП WFE/APP
30,80 %
61,30 %
86,50 %
93,30 %
RPS
17
32
43
47
Просмотров в секунду
10,3
19,32
26,04
27,75
Ср. время ответа (сек.)
0,28
0,45
0,81
2
338
Ферма 3M (1x1x1)
Проверка подлинности с помощью автоматической учетной записи службы
339
Число пользователей
100
250
400
540
RPS
36
87
124
127
Просмотров в секунду
21
52
74
75
Ср. время ответа (сек.)
0,12
0,18
0,65
2
Ср. для ЦП WFE
11 %
28 %
43 % 46 %
Макс. число байтов исключительного пользования 0,7 ГБ
рабочим процессом SharePoint Server Internet
Information Services (IIS) W3WP.
1,4 ГБ
2,0 ГБ 2,4 ГБ
Ср. для ЦП APP
62 %
94 % 95 %
10,8 ГБ
14,1
ГБ
25 %
Макс. число байтов исключительного пользования 5,9 ГБ
PerformancePoint Services W3WP
340
14,6
ГБ
Индивидуальная проверка подлинности пользователей
341
Число пользователей
50
120
180
240
RPS
17
39
52
56
Просмотров в секунду
10
23
31
33
Ср. время ответа (сек.)
0,28
0,48
0,91
2
Ср. для ЦП WFE
5%
12 %
17 % 19 %
Макс. число байтов исключительного пользования 0,78 ГБ
SharePoint Server W3WP
1,3 ГБ
1,6 ГБ 1,9 ГБ
Ср. для ЦП APP
57 %
81 % 81 %
20,1 ГБ
20,5
ГБ
25 %
Макс. число байтов исключительного пользования 19 ГБ
PerformancePoint Services W3WP
342
20,9
ГБ
343
Результаты 4M+ для проверки подлинности с помощью
автоматической учетной записи службы
Для получения среднего времени ответа 2 секунды, требуемого на отображение системы показателей или отчета, начиная с
топологии 4M применялась нагрузка. Затем для устранения ограничивающего фактора (ЦП на веб-сервере или сервере
приложений) был добавлен дополнительный сервер. После этого тестовый набор был запущен повторно. Эта операция
повторялась до тех пор, пока число серверов не стало равно семи.
4M (1x2x1)
5M (1x3x1)
6M
(2x3x1)
7M
(2x4x1)
Число пользователей
840
950
1250
1500
RPS
196
216
292
346
Просмотров в секунду
117
131
175
206
Ср. для ЦП WFE
77 %
63 %
54 %
73 %
Макс. число байтов исключительного
пользования SharePoint Server W3WP
2,1 ГБ
1,7 ГБ
2,1 ГБ
2,0 ГБ
Ср. для ЦП APP
83 %
94 %
88 %
80 %
Макс. число байтов исключительного
16 ГБ
пользования PerformancePoint Services W3WP
12 ГБ
15 ГБ
15 ГБ
Результаты 4M+ для индивидуальной проверки подлинности
пользователей
Тот же самый тест был выполнен для источника данных, настроенного для индивидуальной проверки подлинности
пользователей. Обратите внимание, что при добавлении сервера приложений для создания топологии с четырьмя серверами
344
приложений число пользователей или запросов в секунду, которые могут поддерживаться PerformancePoint Services, не
повышается, поскольку аналитики вносит задержку запроса.
3M (1x1x1)
4M (1x2x1)
5M
(1x3x1)
6M
(1x4x1)
Число пользователей
240
300
325
325
RPS
56
67
74
74
Просмотров в секунду
33
40
44
45
Ср. для ЦП WFE
19 %
24 %
26 %
12 %
Макс. число байтов исключительного
пользования SharePoint Server W3WP
2,1 ГБ
1,9 ГБ
1,9 ГБ
1,5 ГБ
Ср. для ЦП APP
89 %
68 %
53 %
53 %
Макс. число байтов исключительного
20 ГБ
пользования PerformancePoint Services W3WP
20 ГБ
20 ГБ
20 ГБ
ЦП аналитики
44 %
57 %
68 %
17 %
345
Рекомендации
Рекомендации к оборудованию
346
Для определения требований к оборудованию при установке PerformancePoint Services необходимо использовать счетчики
памяти и процессора из таблиц тестирования. Применительно к веб-серверам службы PerformancePoint Services ориентируются
на требования к оборудованию, предъявляемые SharePoint Server 2010. Требования к оборудованию сервера приложений могут
изменяться, если PerformancePoint Services использует большой объем памяти. Эта ситуация может возникнуть в случае, если
источники данных настроены для индивидуальной проверки подлинности пользователей, или если сервер приложений запускает
несколько панелей мониторинга с источником данных, имеющим большое время ожидания.
По результатам тестов сервер баз данных не является узким местом. Пиковая нагрузка на сервер приходится при загрузке
процессора на 31 % в топологии 7M с проверкой подлинности с помощью автоматической учетной записи службы. Определения
контента PerformancePoint Services, например отчеты, системы показателей и ключевые показатели эффективности, хранятся в
списках SharePoint и кэшируются в памяти PerformancePoint Services, сокращая нагрузку на сервер базы данных.
Потребление памяти
В некоторых конфигурациях PerformancePoint Services может потреблять много памяти. Кроме того, важно отслеживать
потребление памяти пулом приложений PerformancePoint Services. Службы PerformancePoint Services кэшируют несколько
элементов в памяти, включая результаты запросов к аналитики и другим источникам данных, на время, равное времени жизни
кэша (по умолчанию 10 минут). Если используется источник данных, который настроен для проверки подлинности с помощью
автоматической учетной записи службы, результаты запросов сохраняются только один раз и совместно используются
несколькими пользователями. Однако, если используется источник данных, настроенный для индивидуальной проверки
подлинности пользователей, а также настроена динамическая защита куба аналитики, результаты выполнения запроса
сохраняются один раз для одного представления, отображаемого одному пользователю (т. е. для каждого фильтра).
PerformancePoint Services использует API кэша ASP.NET. Преимущество использования этого API заключается в том, что для
предотвращения ошибок переполнения памяти ASP.NET управляет кэшем и удаляет элементы (это также называется усечением
кэша) исходя из предельного объема памяти. По умолчанию предельный объем памяти составляет 60 % от объема физической
памяти. После достижения предельного значения PerformancePoint Services еще отображает представления, однако время
ответа существенно повышается в течение небольшого периода, когда ASP.NET удаляет записи кэша.
Счетчик производительности "Приложения ASP.NET \ Округленные значения API кэша" пула приложений размещенных служб
PerformancePoint Services может использоваться для отслеживания усечений кэша ASP.NET, которые возникают из-за
чрезмерного нехватки памяти. Если значение этого счетчика больше нуля, сведения об устранении этой проблемы см. в
следующей таблице.
Проблема
Низкий коэффициент использования процессора сервера
Решение
Добавьте физическую память или установите ограничение на
347
Проблема
Решение
приложений, на сервере приложений запущены другие службы.
использование памяти кэша ASP.NET.
Низкий коэффициент использования процессора сервера
приложений, на сервере приложений запущены только службы
PerformancePoint Services.
При наличии возможности настройте параметры кэша ASP.NET,
чтобы увеличить объем памяти кэша, или добавьте физическую
память.
Высокий коэффициент использования процессора сервера
приложений.
Установите дополнительный сервер приложений.
Источник данных, настроенный для использования индивидуальной проверки подлинности пользователей, может совместно
использовать результаты выполнения запроса и записи кэша, если наборы членства в роли аналитики для пользователей
идентичны и не настроена динамическая защита куба. Это новая функция для PerformancePoint Services в Microsoft SharePoint
Server 2010. Например, если пользователю A назначены роли 1 и 2, пользователю B — роли 1 и 2, а пользователю C — роли 1, 2
и 3, то только пользователи A и B могут совместно использовать записи кэша. Если настроена динамическая защита куба,
пользователи A, B и C не смогут совместно использовать записи кэша.
Службы аналитики
При тестировании служб PerformancePoint Services с индивидуальной проверкой подлинности пользователей для повышения
производительности были изменены два свойства служб аналитики. В следующей таблице показаны измененные свойства, а
также новые значения каждого свойства.
Свойство аналитики
Значение
Память \ HeapTypeForObjects
0
Память \ MemoryHeapType
2
Чтобы вместо собственной кучи аналитики использовали кучу Windows, потребовалось изменить значения двух свойств. До
изменения значений этих свойств и добавления пользовательской нагрузки наблюдалось существенное повышение времени
348
ответа с 0,2 секунд до 30 секунд, а нагрузка на ЦП на веб-сервере, сервере приложений и сервере аналитики оставалась низкой.
Для устранения этой проблемы с помощью динамических административных представлений (DMV) аналитики были собраны
значения времени выполнения запроса, которые показали, что время выполнения отдельного запроса повысилось с 10 мс до 5
000 мс. На основании этих результатов были изменены параметры памяти, указанные выше.
Важно отметить, что несмотря на то, что пропускная способность была существенно увеличена, по данным группы
разработчиков аналитики, изменение этих параметров внесло незначительный, но измеримый вклад в показатели
эффективности обработки запроса на одного пользователя.
Прежде чем приступить к изменению какого-либо свойства аналитики, ознакомьтесь с руководством по повышению
производительности служб Analysis Services (техническая статья по SQL Server)
(http://go.microsoft.com/fwlink/?linkid=165486&clcid=0x419) для получения рекомендаций по повышению пропускной способности.
Распространенные узкие места и причины их возникновения
В ходе тестирования производительности было обнаружено несколько узких мест. Узкое место — это состояние, при котором
достигается предельная емкость отдельного компонента фермы. Узкие места снижают пропускную способность фермы. Если
узким местом являет высокий коэффициент использования процессора, для устранения этого узкого места необходимо добавить
дополнительные серверы. В следующей таблице перечислены некоторые распространенные узкие места и приведены
возможные решения (предполагается, что коэффициент использования процессора низкий и не является узким местом).
Возможное узкое место
Причина возникновения и
методы обнаружения узкого
места
Решение
Куча памяти аналитики
По умолчанию вместо кучи
Windows аналитики
использует собственную кучу
памяти, которая обеспечивает
низкую пропускную
способность в
многопользовательских
средах. С помощью
динамических
Настройте аналитики для использования кучи Windows. Инструкции см. в
разделе "Службы аналитики" настоящей статьи и руководстве по повышению
производительности служб аналитики (техническая статья по SQL Server)
(http://go.microsoft.com/fwlink/?linkid=165486&clcid=0x419).
349
Возможное узкое место
Причина возникновения и
методы обнаружения узкого
места
Решение
административных
представлений (DMV)
получите значение времени
запроса аналитики, чтобы
выяснить, увеличивается ли
время выполнения запроса
при повышении
пользовательской нагрузки и
низком коэффициенте
использования процессора
для аналитики.
Запрос и обработка потоков По умолчанию аналитики
аналитики
ограничивает число запросов
и обработку потоков для
запросов. Запросы с большим
временем выполнения и
высокая пользовательская
нагрузка могут использовать
все доступные потоки.
Отследите простаивающие
потоки и просмотрите
значения счетчиков
производительности очереди
заданий в разделе "MSAS
2008. Категории потоков".
Увеличьте число потоков для запроса и процесса. Инструкции см. в разделе
"Службы аналитики" настоящей статьи и в руководстве по повышению
производительности служб аналитики (техническая статья по SQL Server)
(http://go.microsoft.com/fwlink/?linkid=165486&clcid=0x419).
Память сервера
приложений
Увеличьте объем памяти или повысьте предельный размер кэша ASP.NET.
Дополнительные сведения см. в разделе "Потребление памяти" настоящей
Службы PerformancePoint
Services кэшируют в памяти
350
Возможное узкое место
Причина возникновения и
методы обнаружения узкого
места
Решение
результаты запросов к
статьи. Кроме того, см. статью, посвященную параметрам кэширования
аналитики и другим
элементов ASP.NET
источникам данных на время, (http://go.microsoft.com/fwlink/?linkid=200610&clcid=0x419), и записи блога
равное времени жизни кэша Томаса Маркуардта (Thomas Marquardt) на веб-странице, содержащей
источника данных. Эти
сведения о предельном размере кэша ASP.NET (Возможно, на английском
элементы могут потреблять
языке) (http://go.microsoft.com/fwlink/?linkid=200611&clcid=0x419) (Возможно,
большой объем памяти. Чтобы на английском языке).
определить, выполняет ли
ASP.NET очистку кэша или
усечение кэша из-за нехватки
памяти, понаблюдайте за
счетчиком
производительности
"Приложения ASP.NET \
Округленные значения API
кэша" пула приложений
PerformancePoint Services.
Параметры регулирования Службы PerformancePoint
WCF
Services реализованы в
качестве службы WCF.
Служба WCF ограничивает
максимальное число
одновременных вызовов.
Несмотря на то, что запросы с
большим временем
выполнения могут привести к
возникновению узкого места,
При необходимости измените поведение регулирования Windows
Communication Foundation (WCF). Дополнительные сведения см. в статьях,
посвященных поведению регулирования службы WCF (Возможно, на
английском языке) (http://go.microsoft.com/fwlink/?linkid=200612&clcid=0x419)
(Возможно, на английском языке), и записи блога Венлонга Донга (Wenlong
Dong) о регулировании запросов WCF и масштабировании серверов
(Возможно, на английском языке)
(http://go.microsoft.com/fwlink/?linkid=200613&clcid=0x419) (Возможно, на
английском языке).
351
Возможное узкое место
Причина возникновения и
методы обнаружения узкого
места
Решение
данная причина не является
распространенной.
Понаблюдайте за счетчиком
производительности "WCF /
модель службы" для
PerformancePoint Services и
сравните его с текущим
максимальным значением
одновременных вызовов.
Мониторинг производительности
Чтобы определить, когда необходимо масштабировать или уменьшать систему, используйте счетчики производительности для
отслеживания состояния исправности системы. PerformancePoint Services является службой ASP.NET WCF, поэтому для
мониторинга можно использовать такие же счетчики производительности, как и для любой другой службы ASP.NET WCF. Для
получения сведений о дополнительных счетчиках производительности и процессах, к которым необходимо применять счетчики
производительности, используйте сведения, представленные в следующей таблице.
Счетчик производительности
Экземпляр счетчика
Примечания
Приложения ASP.NET / Округленные Пул приложений
PerformancePoint
значения API кэша
Services
Если значение больше нуля, ознакомьтесь с разделом "Потребление
памяти".
MSAS 2008. Потоки /
Бездействующих потоков в пуле
запросов
Если значение равно нулю, ознакомьтесь с разделом "Службы аналитики" и
руководством по повышению производительности служб аналитики
(техническая статья по SQL Server)
Не определен
352
Счетчик производительности
Экземпляр счетчика
Примечания
(http://go.microsoft.com/fwlink/?linkid=165486&clcid=0x419).
MSAS 2008. Потоки / Длина очереди Не определен
заданий пула запросов
Если значение больше нуля, ознакомьтесь с разделом "Службы аналитики" и
техническим документом по SQL Server 2008, содержащим руководство по
службам аналитики
(http://go.microsoft.com/fwlink/?linkid=165486&clcid=0x419).
MSAS 2008. Потоки /
Бездействующих потоков в пуле
обработки
Не определен
Если значение больше нуля, ознакомьтесь с разделом "Службы аналитики" и
техническим документом по SQL Server 2008, содержащим руководство по
службам аналитики
(http://go.microsoft.com/fwlink/?linkid=165486&clcid=0x419).
MSAS 2008. Потоки / Длина очереди Не определен
заданий пула обработки
Если значение больше нуля, ознакомьтесь с разделом "Службы аналитики" и
техническим документом по SQL Server 2008, содержащим руководство по
службам аналитики
(http://go.microsoft.com/fwlink/?linkid=165486&clcid=0x419).
WCF CountersServiceModelService
3.0.0.0(*)\Необработанных вызовов
Экземпляр службы
PerformancePoint
Если значение больше нуля, ознакомьтесь со статьей, посвященной
регулированию запросов WCF и масштабированию серверов (Возможно, на
английском языке)
(http://go.microsoft.com/fwlink/?linkid=200613&clcid=0x419) (Возможно, на
английском языке).
См. также
Другие ресурсы
Plan for PerformancePoint Services (SharePoint Server 2010)
353
Capacity requirements for Web Analytics Shared Service in
SharePoint Server 2010 (на английском языке)
Initial capacity testing was performed for a simulated midsized deployment of Microsoft SharePoint Server 2010 and other applications
that included 30,000 SharePoint entities. This article describes the results of the capacity testing activities and contains guidance on
capacity management for the Web Analytics service application in SharePoint Server 2010.
In SharePoint Server 2010, the Web Analytics service application enables you to collect, report, and analyze the usage and effectiveness
of SharePoint Server 2010 sites. Web Analytics features include reporting, Web Analytics workflow, and Web Analytics Web Part. For
more information, see Reporting and usage analysis overview.
The aspects of capacity planning that are described in this article include the following:
 Description of the architecture and topology.

Capacity planning guidelines based on the key factors such as total expected traffic and number of SharePoint components.
 Description of the other factors that affect the performance and capacity requirements.
Before you continue to read this article, make sure that you understand key concepts related to SharePoint Server 2010 capacity
management. The resources that are listed in this section can help you learn about frequently used terms and get an overview of the
recommended approach to capacity management. These resources can also help you use the information that is provided in this article
more effectively.
For more conceptual information about performance and capacity management, see the following articles:
 Управление производительностью и емкостью (SharePoint Server 2010)
 Capacity management and sizing for SharePoint Server 2010 (на английском языке)
In this article:
 Introduction

Hardware specifications and topology

Capacity requirements
354
Introduction
Overview
As part of SharePoint Server 2010, the Web Analytics service application is a set of features that you can use to collect, report, and
analyze the usage and effectiveness of a SharePoint Server 2010 deployment. You can organize SharePoint Web Analytics reports into
three main categories:
 Traffic

Search
 Inventory
SharePoint Web Analytics reports are typically aggregated for various SharePoint entities, such as sites, site collections, and W eb
applications for each farm. To view an architectural overview of the Web Analytics service application in a SharePoint deployment, see
Architectural overview later in this article.
The Web Analytics shared service requires resources primarily at the application server and database server level. This article does not
cover the Web Server layer capacity planning, because the Web Analytics service’s capacity requirements are minimal at this level.
This article contains the capacity requirements for several application servers and Microsoft SQL Server based computers, according to
the following criteria:
 Total expected site traffic (clicks, search queries, ratings).
 Number of SharePoint components (Site, Site Collection, and Web Application) for each farm.
Other less significant factors which can affect the capacity requirements are summarized in Other factors later in this article.
Architectural overview
The following diagram (Figure 1) shows the flow of the site usage data from a Web browser to the analytics databases, and then back to
the Web browser as reports. The usage data is logged to the usage files on the Web servers. The usage timer job calls the Logging Web
Service to submit the raw data from the usage files. The Logging Web Service writes it to the staging database, where the raw data is
stored for seven days (this is not configurable). The Web Analytics components Log Batcher and User Behavior Analyzer clean and
process the raw data on the staging database. The Report Consolidator runs one time every 24 hours. The Report Consolidator
aggregates the raw data from the staging database on various dimensions, and then writes it to the reporting database. The aggregated
data is stored in the reporting database for a default period of 25 months (this is configurable).
355
Figure 1. SharePoint Server 2010 Web Analytics architectural overview
356
The performance of the Logging Web Service primarily depends on the number of application servers. (Scaling out is available for the
application servers.) The performance of the Log Batcher and User Behavior Analyzer depends primarily on the analytics staging
database. The Read and Write activities that are performed by all the different components can cause the analytics staging database to
slow down the process. (Scaling out is available for the staging database.) The performance of the Report Consolidator also primarily
depends on the reporting database. (Scaling out of reporting database is not supported.)
Hardware specifications and topology
This section provides detailed information about the hardware, software, topology, and configuration of a case study environment.
Hardware
Примечание.
This environment is scaled to accommodate prerelease builds of SharePoint Server 2010 and other products. Therefore, the deployed
hardware has larger capacity than necessary to serve the demand typically experienced by this environment. This hardware is described
only to provide additional context for this environment and serve as a starting point for similar environments. It is important to conduct your
own capacity management based on your planned workload and usage characteristics. For more information about the capacity
management process, see Управление производительностью и емкостью (SharePoint Server 2010).
Web servers
This article does not cover the Web server layer capacity planning, because the Web Analytic service’s capacity requirements are minimal
at this level.
Application servers
The following table describes the configuration of each application server. Based on the site traffic and the number of SharePoint
components that are involved, users will need one or more application servers.
Application server
Minimum requirement
Processors
4 quad core @ 2.33 GHz
357
Application server
Minimum requirement
RAM
8 GB
Operating system
Windows Server 2008, 64 bit
Size of the SharePoint drive
300 GB
Number of network adapters
1
Network adapter speed
1 GB
Authentication
NTLM
Load balancer type
SharePoint Load Balancer
Software version
SharePoint Server 2010 (prerelease version)
Services running locally

Central Administration

Microsoft SharePoint Foundation Incoming E-mail

Microsoft SharePoint Foundation Web Application

Microsoft SharePoint Foundation Workflow Timer Service

Search Query and Site Settings Service

SharePoint Server Search

Web Analytics Data Processing Service

Web Analytics Web Service
Database servers
The following table describes the configuration of each database server. Instances of SQL Server were required for both the staging and
reporting databases.
358
Database server
Minimum requirement
Processors
4 quad core @ 2.4 GHz
RAM
32 GB
Operating system
Windows Server 2008, 64-bit
Disk size
3 terabytes
Примечание.
Although we used this disk size for our capacity testing, your
environment will likely require a much larger disk size to support
Web Analytics.
Number of network adapters
1
Network adapter speed
1 GB
Authentication
NTLM
Software version
SQL Server 2008
Topology
The following diagram (Figure 2) shows the Web Analytics topology.
359
Figure 2. Web Analytics topology
360
Capacity requirements
Testing methodology
This section presents the capacity requirements with regard to the total amount of site traffic (this is measured by number of clicks, search
queries, and ratings) per day that can be supported by different numbers of application servers and SQL Server based computers. The
numbers presented currently are for a midsize SharePoint deployment that has about 30,000 SharePoint entities. The Web Analytics
shared service aggregates the data for each day. Therefore, the data volume that is presented corresponds to the total number of records
(this is measured by number of clicks, search queries, and ratings) that the SharePoint farm is expected to receive each day.
This section provides diagrams that show the daily site traffic that can be supported by one, two, or three application servers (Figure 3)
and the daily site traffic that can be supported that corresponds to the various database configurations (Figure 4). In the diagrams, data is
shown by using two colors:
 Green Green values indicate the safe limit for the site traffic that can be processed for the corresponding number of application
servers and SQL Server based computers.

Yellow Yellow values indicate the expected limit for the site traffic that can be processed for the corresponding number of application
servers and SQL Server based computers.
The green and yellow values are estimates that are based on two key factors:
 Total site traffic, measured by number of page view clicks, search queries, and ratings.
 Number of SharePoint entities, such as sites, site collections, and Web applications, for each farm.
The estimates also depend on other properties of the data and the data retention period in the reporting database. For testing, the other
properties of the data were maintained as constant as described in Dataset description later in this section.
Also, in smaller SharePoint deployment environments, you can share the application servers and SQL Server based computers together
with other SharePoint services and databases. This article contains information about the capacity of the application servers and the SQL
Server based computers that are in a test environment so that the Web Analytics shared service is the only major service that is running
on the servers. The actual performance results for environments that actively use other shared services at the same time running might
vary.
To determine the capacity requirements for your environment, make sure that you estimate the expected daily site traffic and the number
of components that you might use for a SharePoint deployment. Then, the number of application servers and SQL Server based
computers should be estimated independently, as shown in Figure 3 and Figure 4.
Dataset description
361
The dataset that was selected for the test environment is a mid-sized dataset that has approximately 30,000 SharePoint components,
which includes all web applications, site collections, and sites. Other characteristics of the data that were kept constant in the environment
are also listed in the following table.
Dataset characteristics
Value
Number of SharePoint components
30,000
Number of unique users
117,000
Number of unique queries
68,000
Number of unique assets
500,000
Data size in the reporting database
200 GB
The total site traffic, measured by number of clicks, search queries, and ratings, was increased as part of this case study to establish the
number of records that can be supported by the corresponding topology.
Важно!
Some typically used topologies generally exceed the capacity planning guidance. Those topologies include the following:
 Team sites

My Site Web sites
 Self-provisioning portals
If you anticipate that you might exceed the capacity planning guidelines, we recommend that you turn off the Web Analytics service
application. For more information about how to turn off a service application, see Starting or stopping a service.
Application servers
The following diagram (Figure 3) shows the daily site traffic that can be supported by one, two, or three application servers. The site traffic
is represented in millions of records (each click, search query, or rating makes up a record) each day. The yellow line represents the
362
expected number of records for the corresponding topology, whereas the green line represents the safe assumption for the number of
records.
363
Figure 3. Daily site traffic vs. the application servers topology
364
The application servers are not very CPU-intensive or memory intensive. Thus, the CPU and the memory usage are not summarized for
this section.
SQL Server based computers
The following diagram (Figure 4) shows the daily site traffic that can be supported that corresponds to the following configurations:
 One instance of SQL Server for both staging and reporting databases (1S+R).

Two instances of SQL Server, one staging database and one reporting database (1S1R).
 Three instances of SQL Server, two staging databases and one reporting database (2S1R).
The site traffic is represented in millions of records (each click, search, or rating makes up a record) each day. The yellow line represents
the expected number of records for the corresponding topology, whereas the green line represents the safe assumption for the number of
records.
365
Figure 4. Daily site traffic vs. SQL Server topology
366
The following table summarizes the CPU and memory usage of the various components on the instances of SQL Server that are hosting
the staging database and the reporting database.
Configuration
1S+R
1S1R
1S1R
2S1R
2S1R
Staging + Reporting
Staging
Reporting
Staging
Reporting
Total sum of percentage of processor time 19
for 8 processor computer
192
5.78
100
13.4
SQL Server buffer hit ratio
99
100
100
100
100
% Disk time
7,142
535
5.28
59.3
98.2
Disk queue length
357
28.6
0.26
2.97
4.91
Other factors
Many other factors can affect the performance of various analytics components and can affect the capacity planning. These factors
primarily affect the performance of the Report Extractor component because they can affect the size of the data aggregated each day. The
total size of the data in the reporting database also affects the performance of the Reporting Extractor, although this is not significant
because the data is partitioned daily. Some of these other factors are as follows:
 Number of unique queries each day.

Number of unique users each day.

Total number of unique assets clicked each day.
 Existing data size in the reporting warehouse, based on the data retention in the warehouse.
The overall effect of these factors is less significant than the total data volume and the number of site entities. However, it is important to
conduct your own capacity management based on your planned workload and usage characteristics. For more information about the
capacity management process, see Управление производительностью и емкостью (SharePoint Server 2010).
Remaining issues
367
There are current known issues that significantly affect the current performance of the Web Analytics service application for deployments
that have a large site hierarchy, which includes approximately 100,000 or more SharePoint components. This article might be updated
with the capacity requirements for larger site hierarchies when more information is available.
См. также
Понятия
Управление производительностью и емкостью (SharePoint Server 2010)
Другие ресурсы
SharePoint 2010 Administration Toolkit (SharePoint Server 2010)
368
Оценка требований к производительности и емкости для
управления веб-контентом в SharePoint Server 2010
В данной статье приводится руководство по управлению емкостью для сайтов Microsoft SharePoint Server 2010, для которых
включена инфраструктура публикации. Данный документ предназначен для SharePoint Server 2010, и содержащиеся в нем
сведения неприменимы к SharePoint Foundation.
В статье рассматриваются указанные ниже сценарии.
 Сайт, опубликованный в Интернете, — веб-представительство организации.
Сайты такого типа публикуются в Интернете и позволяют анонимным пользователям Интернета находить сведения о
корпорации. Подобные сайты снабжаются фирменной символикой, а их контент строго контролируется.
 Сайт, опубликованный в интрасети, — внутренний новостной сайт.
Сайты такого типа публикуются внутри организации и используются в основном для обмена информацией между
прошедшими проверку пользователями. Данные в одних разделах такого сайта могут контролироваться более строго, в
других — менее строго.
 Корпоративный вики-сайт — репозиторий знаний.
Корпоративный вики-сайт представляет собой сайт на основе одной фермы, растущий по мере создания участниками новых
страниц и вставки ссылок на другие страницы, которые могут быть еще не созданы. Как правило, корпоративные вики-сайты
публикуются внутри организации и позволяют сотрудникам компании обмениваться знаниями с другими пользователями с
помощью решения, интегрированного в среду SharePoint и поддерживающего расширенные возможности этой среды.
Изучив данный документ, вы получите представление об указанных ниже понятиях.
 Ключевой показатель (пропускная способность), значение которого следует максимизировать для поддержки большого
количества операций чтения.

Потенциальные узкие места, связанные с развертыванием средств управления веб-контентом SharePoint Server 2010.

Важность кэша вывода для максимизации пропускной способности.

Влияние операций записи на чтение данных конечными пользователями.
369
Содержание:
 Необходимые сведения

Сведения о тестах и используемом подходе

Развертывание средств управления веб-контентом

Направления оптимизации

Результаты тестов и рекомендации

Об авторах
Необходимые сведения
Перед тем как приступить к изучению данного документа, убедитесь, что вы владеете ключевыми понятиями, лежащими в основе
управления емкостью SharePoint Server 2010. В приведенной ниже документации описывается рекомендуемый подход к
управлению емкостью и дается необходимый контекст для эффективного использования сведений, содержащихся в данном
документе.
Дополнительные сведения о понятиях, связанных с производительностью и емкостью, которые могут оказаться полезными для
понимания контекста данной статьи, можно найти в указанных ниже документах.
 Управление емкостью и настройка размеров для SharePoint Server 2010 (Возможно, на английском языке)

Практические примеры по управлению производительностью и емкостью (SharePoint Server 2010) (Возможно, на английском
языке)
Сведения о тестах и используемом подходе
В каждом тесте переменные величины, взятые из реального мира, абстрагированы, для того чтобы можно было дать конкретные
рекомендации. Следовательно, крайне важно провести тестирование и мониторинг в собственной среде, чтобы убедиться, что
масштабирование было выполнено в соответствии с ожидаемым объемом запросов. Дополнительные сведения о понятиях,
связанных с управлением емкостью, см. в статье Обзор управления емкостью и изменения размера для SharePoint Server 2010.
В данной статье рассматриваются вопросы, связанные с производительностью компонентов семейства сайтов, инфраструктуры
публикации SharePoint Server и кэширования вывода. Эти функции доступны только при включенной инфраструктуре публикации
SharePoint Server. Для порталов публикации этот компонент включен по умолчанию.
370
Набор данных
Тесты проводились с использованием набора данных, имеющего общие характеристики с фактически развернутыми средствами
управления веб-контентом. Хотя нагрузка была постоянной, запрашивались различные страницы. В приведенной ниже таблице
описан набор данных, использовавшийся для тестирования.
Набор данных
Объект
Сайт публикации
Размер баз данных контента
2,63 ГБ
Число баз данных контента
1
Число семейств веб-сайтов
1
Число веб-приложений
1
Число сайтов
50
Число страниц
20 000 страниц, разбитых на 20 папок по 1000 страниц в каждой
Структура страниц
Страницы статей на языке HTML (только базовые возможности) с
двумя ссылками на рисунки
Размер страницы
42 КБ без сжатия; 12 КБ со сжатием
Изображения
3 000 рисунков размером от 30 КБ до 1,3 МБ
Службы IIS (Internet Information Services) рекомендуется настроить на постоянное сжатие файлов, а не использовать настроенное
по умолчанию динамическое сжатие. При динамическом сжатии службы IIS сжимают страницы до тех пор, пока загрузка ЦП не
превысит определенный порог, после чего службы IIS перестают сжимать страницы, пока загрузка ЦП не упадет ниже этого
порога. Тесты в данной статье проводились при постоянно включенном сжатии.
371
В тестовом наборе данных использовались только компоненты 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
372
В приведенной ниже таблице описано оборудование сервера базы данных, использовавшееся для тестирования.
Характеристики оборудования для серверов базы данных
Сервер базы данных
Процессоры
4 четырехъядерных процессора с тактовой частотой 3,19 ГГц
ОЗУ
16 ГБ
Операционная система
Windows Server 2008, 64-разрядная
Хранилище
15 дисков по 300 ГБ со скоростью вращения шпинделя 15 000
об/мин
Число сетевых адаптеров
2
Скорость сетевого адаптера
1 гигабит
Проверка подлинности
NTLM
Версия программного обеспечения
Microsoft SQL Server 2008
Глоссарий
В данном документе используется ряд специальных терминов. Ниже приведены определения ключевых терминов.
 Запросов/сек Запросов в секунду. Количество запросов, полученных фермой или сервером за одну секунду. Это основной
показатель нагрузки на сервер или ферму.
Обратите внимание, что количество запросов отличается от количества загрузок страниц; каждая страница состоит из
нескольких компонентов, каждый из которых при загрузке страницы создает один или несколько запросов. Таким образом,
одной загрузке страницы соответствует несколько запросов. Как правило, при измерении количества запросов в секунду не
учитываются запросы, выполняемые при проверке подлинности, и события, в которых используются малозначимые ресурсы.
 Зеленая зона Это состояние, в котором сервер удовлетворяет указанным ниже условиям.
373

Задержка на стороне сервера для не менее чем 75% запросов не превышает одной секунды.

Уровень использования ЦП на всех серверах не превышает 50%.

Процент сбоев не превышает 0,01%.
Развертывание средств управления веб-контентом
Существуют две модели создания контента на сайтах публикации SharePoint, влияющие на выбор топологии фермы серверов.
В модели присутствия автора авторы и посетители совместно используют одно семейство сайтов. Авторы могут создавать и
обновлять контент в любой момент, что приводит к неравномерному распределению операций чтения и записи в течение дня.
Такая ферма серверов, как правило, обрабатывает большое количество операций чтения и небольшое количество операций
записи.
На приведенной ниже схеме показана работа модели присутствия автора с точки зрения топологии.
В модели развертывания контента одни семейства сайтов выделены исключительно для разработки, а другие — для
публикации контента. Контент создается и обновляется в среде разработки, после чего развертывается по расписанию в среде
публикации, где становится доступен посетителям. Среда публикации в основном обрабатывает запросы на чтение, за
исключением случая развертывания контента из среды разработки. В отличие от модели присутствия автора нагрузку на сервер,
возникающую при развертывании контента, можно запланировать на указанные интервалы времени.
На приведенной ниже схеме показана работы модели развертывания контента с точки зрения топологии.
Эти две модели являются взаимоисключающими.
374
Хотя для сайтов публикации в Интернете и сайтов публикации в интрасети можно использовать как модель присутствия автора,
так и модель развертывания контента, для корпоративных вики-сайтов наиболее эффективна модель присутствия автора. Как
правило, корпоративный вики-сайт обрабатывает больше операций записи по сравнению с количеством операций чтения из-за
большего количества пользователей, которые могут редактировать страницы. Страницы корпоративного вики-сайта отличаются
от страниц с опубликованными статьями и обладают другими характеристиками производительности.
Направления оптимизации
В данном разделе рассматриваются вопросы оптимизации среды управления веб-контентом. Для оптимизации среды
необходимо понимать принципы управления пропускной способностью, узкими местами и кэшированием.
Содержание:
 Пропускная способность — ключевой показатель

Узкие места и их устранение

Рекомендации по кэшированию
Пропускная способность — ключевой показатель
Пропускная способность и время отклика являются основными показателями, которые необходимо оптимизировать при
планирования емкости для развернутых средств управления веб-контентом SharePoint Server 2010. Пропускная способность —
это количество операций, выполняемых фермой серверов в секунду (измеряется в запросах в секунду).
Узкие места и их устранение
Узким местом называется системный ресурс, при максимальной загрузке которого ферма серверов не может обрабатывать
дополнительные запросы. На приведенной ниже схеме показаны элементы фермы серверов и ресурсы, которые могут стать
узкими местами в системе. Такие ресурсы необходимо отслеживать.
375
376
Загрузка ЦП на веб-сервере
ЦП веб-сервера не должен быть узким местом в грамотно настроенной топологии, поскольку этот компонент легче всего
масштабировать. Подсистема балансировки нагрузки маршрутизирует запросы между веб-серверами таким образом, чтобы ни
один из серверов не был загружен значительно больше, чем другие.
Хотя пользователи могут заходить на веб-сайт даже при максимальной загрузке ЦП веб-сервера, время отклика сервера для
пользователей увеличивается. Такое поведение позволяет эффективно обрабатывать пиковые нагрузки в общем потоке
запросов. Однако длительная нагрузка, превышающая возможности фермы серверов, в конце концов приведет к тому, что
количество невыполненных запросов превысит пороговое значение для количества ожидающих запросов. Когда это происходит,
веб-серверы перестают обрабатывать запросы и возвращают ошибку HTTP 503. На приведенном ниже рисунке показано, как
уменьшается время отклика сервера после превышения порогового значения для количества ожидающих запросов, поскольку в
этом случае обрабатываются только ошибки HTTP.
377
На схеме отражены указанные ниже изменения.
378
1. По мере того как уровень загрузки ЦП на веб-сервере приближается к 100%, время отклика увеличивается.
2. После превышения порогового значения для количества ожидающих запросов все последующие запросы обрабатываются с
ошибками.
Другие узкие места
Если ЦП веб-сервера не является узким местом, на наличие узких мест следует проверить топологию фермы, конфигурацию
фермы и контент обрабатываемых страниц. Потенциальные узкие места этих элементов перечислены ниже.
1. Сеть Большой объем трафика может привести к перегрузке сети даже между веб-сервером и сервером базы данных или
между веб-сервером и конечными пользователями. Во избежание подобной ситуации на веб-серверах рекомендуется
установить двухгигабитные сетевые адаптеры.
2. ЦП сервера базы данных Если ЦП сервера базы данных становится узким местом, добавление в ферму серверов
дополнительных веб-серверов не приводит к увеличению максимальной пропускной способности фермы. Узкое место,
связанное с ЦП сервера базы данных, а не веб-сервера, может указывать на одну из двух описанных ниже ситуаций.
a) Неоптимальные параметры кэша либо наличие очень медленных страниц, особенно страниц, для которых отключено
кэширование вывода. Признаком такой ситуации является высокая загрузка ЦП сервера базы данных при низком или
среднем трафике либо низкой загруженности веб-сервера.
b) На сервере базы данных достигнута максимальная пропускная способность, поддерживаемая фермой. Признаком
такой ситуации является высокая загрузка ЦП веб-сервера и сервера базы данных при высоком трафике.
Рекомендации по кэшированию
В SharePoint Server 2010 используются три типа кэширования. Кэширование предназначено для повышения производительности
путем сокращения количества вызовов к базе данных для часто запрашиваемых данных. Последующие запросы к странице
можно обрабатывать из кэша на веб-сервере, что позволяет значительно снизить нагрузку на ресурсы веб-серверов и серверов
баз данных.
Три типа кэширования перечислены ниже.
 Кэш вывода В этом кэше, размещенном в оперативной памяти веб-сервера, хранится контент запрошенной страницы.
Дополнительные сведения о кэше вывода см. в статье, посвященной кэшированию вывода и профилям кэша
(http://go.microsoft.com/fwlink/?linkid=121543&clcid=0x419).

Кэш объектов В этом кэше, размещенном в оперативной памяти веб-сервера, хранятся объекты SharePoint, например
метаданные веб-элементов и элементов списков. Дополнительные сведения о кэше объектов см. в статье, посвященной
кэшированию объектов (http://go.microsoft.com/fwlink/?linkid=123948&clcid=0x419).
379

Дисковый кэш для больших двоичных объектов В этом кэше, размещенном на диске, хранятся изображения, звуки,
видеоролики и другие большие двоичные файлы. Дополнительные сведения о кэше больших двоичных объектов см. в
статье, посвященной дисковому кэшированию для больших двоичных объектов
(http://go.microsoft.com/fwlink/?linkid=123947&clcid=0x419).
Каждый из этих типов кэша важен для поддержания высокой пропускной способности, однако кэширование вывода играет самую
большую роль и поэтому рассматривается в данной статье более подробно.
Результаты тестов и рекомендации
В данном разделе рассказывается о конкретных протестированных областях и приводятся рекомендации на основе результатов
тестов.
Содержание:
 Влияние включения кэша вывода

Анонимные пользователи и пользователи, прошедшие проверку

Характеристики масштабирования для операций чтения и записи

Вопросы, связанные с кэшем вывода

Влияние объема считанных данных на загрузку ЦП и время отклика

Влияние операций записи на пропускную способность

Влияние развертывания контента

Влияние моментальных снимков базы данных во время экспорта контента

Характеристики контента
Влияние включения кэша вывода
Кэш вывода полезно использовать для оптимизации решения SharePoint Server 2010 для обработки большого количества
операций чтения.
В этих тестах для определения максимального количества запросов в секунду количество активных пользователей,
выполняющих запросы на ферме, увеличивалось до тех пор, пока загрузка ЦП на сервере базы данных или веб-серверах не
достигала 100% и ЦП не становился узким местом. Тест проводился в топологиях фермы 1x1 (1 веб-сервер и 1 сервер базы
данных), 2x1, 4x1 и 8x1, чтобы продемонстрировать зависимость коэффициента попадания в кэш вывода от масштабирования
веб-серверов.
380
Коэффициент попадания в кэш вывода
Коэффициент попадания в кэш вывода представляет собой отношение количества попаданий в кэш к количеству промахов.
 Попадание в кэш — это ситуация, когда кэш получает запрос данных объекта, которые уже хранятся в кэше.

Промах кэша — это ситуация, когда кэш получает запрос данных объекта, которые отсутствуют в кэше. В случае промаха
кэш пытается сохранить запрошенные данные объекта, чтобы при последующих запросах происходило попадание в кэш.
Запрос страницы может привести к промаху кэша по ряду причин, которые перечислены ниже.
 Страницы, не настроенные на использование кэша вывода.

Персонализированные страницы, например, страницы с данными, уникальными для текущего пользователя.

Первый просмотр для ключа варианта кэша вывода.
 Первый просмотр после истечения срока действия кэшированного контента.
На приведенной ниже схеме показано влияние кэширования вывода на пиковую пропускную способность в фермах, включающих
от одного до четырех веб-серверов и один сервер базы данных.
381
382
Примечание.
Точка данных для максимального количества запросов в секунду в ферме серверов с топологией 4x1 со стопроцентным коэффициентом
попадания в кэш была получена путем экстраполяции и фактически не наблюдалась. Объем запросов к ферме серверов достиг предельной
пропускной способности сети, т. е. скорость передачи данных приблизилась к 1 гигабиту в секунду. Во всех случаях загрузка ЦП вебсервера составляла 100%.
В приведенной ниже таблице отражено влияние коэффициента попадания в кэш вывода для топологий фермы, включающей от
одного до четырех веб-серверов и один сервер базы данных.
Влияние коэффициента попадания в кэш вывода в различных топологиях фермы
1x1
2x1
4x1
Макс. кол-во запросов/сек
3 463
7 331
11 032
Использование ЦП SQL
Server
0%
0%
0%
Макс. кол-во запросов/сек
2 137
3 945
5 937
Использование ЦП SQL
Server
5,93%
12,00%
21,80%
Коэффициент Значение
попадания в
кэш вывода
100%
95%
383
1x1
2x1
4x1
Макс. кол-во запросов/сек
1 518
2 864
4 518
Использование ЦП SQL
Server
7,12%
14,40%
28,00%
Макс. кол-во запросов/сек
459
913
1 596
Использование ЦП SQL
Server
9,86%
19,50%
42,00%
Макс. кол-во запросов/сек
172
339
638
Использование ЦП SQL
Server
9,53%
19,00%
36,30%
Коэффициент Значение
попадания в
кэш вывода
90%
50%
0%
Выводы и рекомендации по использованию кэша вывода
Более высокое значение коэффициента попадания в кэш вывода соответствует существенному увеличению максимального
количества запросов в секунду. Таким образом, для оптимизации решения публикации SharePoint Server 2010 рекомендуется
включить кэш вывода. Параметры кэша вывода настраиваются на странице "Параметры кэша вывода" семейства сайтов.
384
Дополнительные сведения см. в статье, посвященной улучшению отрисовки страниц путем настройки кэширования вывода
(http://go.microsoft.com/fwlink/?linkid=205058&clcid=0x419) на сайте Office.Microsoft.com.
В тестах с включенным кэшированием вывода первый запрос, при котором кэшировалась страница, исключался, таким образом,
определенный процент страниц уже хранился в кэше. При первом обращении пользователя к некэшированной странице эта
страница добавлялась в кэш. При приближении к максимальной емкости кэша из кэша удалялись наиболее редко
запрашиваемые данные.
Нулевой коэффициент попадания в кэш соответствует короткому времени, в течение которого включенный в среде кэш вывода
заполняется после очистки. Например, такая ситуация возникает в реальных средах каждый день при перезапуске пула
приложений. Важно масштабировать оборудование таким образом, чтобы оно позволяло справиться с ситуацией, при которой
коэффициент попадания в кэш равен нулю в течение короткого времени между перезапуском пула приложений и последующими
запросами и кэшированием страниц. Нулевой коэффициент попадания в кэш также соответствует среде, в которой кэширование
вывода отключено.
Анонимные пользователи и пользователи, прошедшие проверку
В предыдущем тесте предполагалось, что все запросы к сайту выполнялись анонимными читателями. Однако для реального
сайта некоторые или все пользователи могут проходить проверку подлинности. В качестве примеров, когда требуется проверка
подлинности, можно привести корпоративный сайт публикации в интрасети и контент веб-сайта, доступный только
зарегистрированным участникам.
С помощью профилей кэша вывода можно задать для пользователей, прошедших проверку, поведение кэша вывода,
отличающееся от поведения для анонимных пользователей.
Профили кэша
Профили кэша содержат параметры, применяемые к страницам, элементам страниц, типам контента и уровням
масштабирования развернутого сайта. Профиль кэша определяет указанные ниже типы поведения кэша.
 Срок хранения элементов в кэше.

Политика фильтрации по ролям безопасности.

Срок действия параметров, например продолжительности и изменений.

Варианты кэшированного контента, например на основе разрешений пользователя, прав пользователя и других
настраиваемых переменных.
Любое изменение в профиле кэша немедленно применяется ко всему контенту сайта. Для анонимных пользователей и
пользователей, прошедших проверку, можно задать различные профили кэша.
385
Для анонимных пользователей использовался профиль кэша вывода "Общий доступ через Интернет (анонимный)", а для
пользователей, прошедших проверку, — профиль "Экстрасеть (опубликованный сайт)".
На приведенной ниже диаграмме показано влияние трафика, создаваемого прошедшими проверку пользователями, на загрузку
ЦП сервера базы данных.
В качестве модели проверки подлинности использовалась базовая проверка подлинности Windows. Хотя базовую проверку
подлинности не рекомендуется использовать для сайтов в Интернете, этот метод проверки подлинности был выбран для
демонстрации минимальных накладных расходов, возникающих из-за проверки подлинности. Величина этих накладных расходов
варьируется в зависимости от конкретного механизма проверки подлинности. При тестировании своей среды обязательно
386
учитывайте влияние выбранного механизма проверки подлинности. Дополнительные сведения о механизмах проверки
подлинности, поддерживаемых в SharePoint Server 2010, см. в статье Plan authentication methods (SharePoint Server 2010).
Выводы и рекомендации по работе с анонимными пользователями и пользователями, прошедшими
проверку
Пользователи, прошедшие проверку, создают меньше запросов в секунду и обладают меньшим потенциалом для
масштабирования, поскольку дополнительная работа по проверке учетных данных создает нагрузку на сервер базы данных. Как
следует из результатов тестирования, максимальное количество запросов в секунду, наблюдаемое при прохождении
пользователями проверки подлинности, значительно меньше, чем при анонимном доступе к ферме.
Характеристики масштабирования для операций чтения и записи
Тесты были спроектированы таким образом, чтобы фиксировать количество операций записи в час. В данной статье под
операцией записи подразумевается создание и возврат новой страницы публикации либо изменение и возврат существующей
страницы публикации.
В последующих тестах в систему добавлялись читатели до тех пор, пока загрузка ЦП веб-сервера не достигала 80-90%, после
чего в среде выполнялись операции записи с искусственной задержкой. Общее количество операций записи в час составляло
приблизительно 500. Для всех тестов коэффициент попадания в кэш вывода составлял 90%. Один и тот же тест выполнялся для
топологий фермы 1x1, 2x1 и 4x1; при этом в дополнение к общей пропускной способности при чтении для каждой конфигурации
отслеживалась загрузка ЦП веб-сервера и SQL Server. В качестве базы для сравнения были взяты результаты тестирования
конфигурации с анонимным доступом только на чтение; также была протестирована конфигурация с прошедшими проверку
пользователями (использовалась базовая проверка подлинности Windows).
Хотя при проведении тестов масштабируемости с доступом только на чтение ЦП веб-сервера использовался на 100%, при
проведении тестов масштабируемости с операциями записи загрузка ЦП веб-сервера поддерживалась на уровне 80-90%. Это
было сделано для резервирования части ресурсов ЦП на выполнение операций записи.
На приведенной ниже схеме показано общее количество запросов на чтение в секунду для каждого теста. Количество запросов
на чтение в секунду увеличивается линейно по мере добавления дополнительных веб-серверов, даже при выполнении операций
записи, однако при включении операций записи наблюдается падение частоты запросов в секунду.
387
388
Загрузка ЦП сервера базы данных увеличивается по мере увеличения количества веб-серверов. На приведенной ниже
диаграмме показан график роста загрузки ЦП SQL Server в различных конфигурациях. Как было показано выше в разделе
Анонимные пользователи и пользователи, прошедшие проверку, проверка подлинности влияет на загрузку ЦП сервера базы
данных, и это становится еще более заметно при добавлении операций записи (что также влияет на загрузку ЦП сервера базы
данных).
389
390
Экстраполированный тренд использования SQL Server показывает, что SQL Server станет узким местом при использовании
шести веб-серверов, обрабатывающих запросы на чтение от прошедших проверку пользователей. Однако при анонимном
доступе на чтение возможно масштабирование до большего числа веб-серверов.
Необходимо помнить о том, что в типичной среде на нагрузку на сервер базы данных также влияют дополнительные факторы,
которые следует учитывать при планировании емкости. Дополнительные сведения о том, как определить зеленую зону для
типичной загрузки ЦП сервера базы данных, см. в статье Обзор управления емкостью и изменения размера для SharePoint
Server 2010.
Выводы и рекомендации по характеристикам масштабирования для операций чтения и записи
Данные тестирования показывают, что увеличение количества веб-серверов является эффективной стратегией увеличения
пропускной способности, пока сервер базы данных не становится узким местом. В среднем тесты с использованием анонимных
операций чтения и прошедших проверку операций записи показали увеличение загрузки ЦП веб-сервера на 52% по сравнению с
тестами с использованием анонимных операций чтения и без использования операций записи. Кроме того, операции чтения,
выполняемые прошедшими проверку пользователями, оказывают значительную дополнительную нагрузку на SQL Server,
поскольку при каждом запросе выполняется дополнительная проверка подлинности, требующая обращения к SQL Server.
На приведенной ниже диаграмме показано влияние пропускной способности на загрузку ЦП сервера базы данных.
391
392
Вопросы, связанные с кэшем вывода
Если единственной целью при планировании емкости является максимизация количества запросов в секунду, то оптимальный
коэффициент попадания в кэш вывода, согласно данным тестам, составляет 100%. Однако кэширование вывода для всех
страниц может оказаться неприемлемым из-за требований к актуальности данных или ограничений памяти.
Актуальность данных
Данные, обрабатываемые из кэша вывода, могут не отражать последние обновления, внесенные в исходный контент. В
источнике развертывания контента или в модели присутствия автора (для прошедших проверку авторов) авторы могут не
увидеть последние обновления сразу же после обновления существующего контента.
Для решения этой проблемы необходимо задать в профиле кэша свойство Длительность, в котором указывается срок хранения
страницы в кэше вывода. По истечении срока хранения страница из кэша удаляется, последующий запрос приводит к промаху
кэша, в результате чего контент страницы в кэше обновляется.
Также можно задать свойство профиля кэша Проверять на изменения, чтобы сервер сравнивал время кэширования страницы
со временем последнего изменения контента в семействе сайтов. Запрос страницы, для которой эти отметки времени не
согласуются друг с другом, приводит к очистке кэша для всех страниц семейства сайтов. Поскольку свойство Проверять на
изменения влияет на все страницы в семействе сайтов, его рекомендуется включать только при использовании решения на
основе модели присутствия автора с проверкой подлинности, которое редко обновляется и является по существу статическим.
Совместное использование этого параметра с длительным сроком хранения в кэше позволяет обрабатывать все страницы из
кэша до тех пор, пока сайт не будет обновлен.
По умолчанию свойство Проверять на изменения отключено. Это означает, что в ответ на запросы страниц, срок хранения
которых еще не истек, веб-сервер будет обрабатывать данные из кэша вывода независимо от того, была ли изменена исходная
ASPX-страница.
В данном тесте, проведенном в ферме серверов с топологией 1x1, все переменные имеют те же значения, что и в тестах из
раздела Характеристики масштабирования для операций чтения и записи, за исключением свойства Проверять на изменения.
Если свойство Проверять на изменения включено, кэш очищается чаще, что приводит к снижению коэффициента попадания в
кэш вывода.
На приведенной ниже диаграмме показано влияние свойства Проверять на изменения на пропускную способность.
393
Свойство профиля кэша вывода Проверять на изменения рекомендуется использовать только в особых случаях. Совместное
использование этого параметра с продолжительным сроком хранения данных в кэше эффективно для сайтов с редко
изменяющимся контентом, основанных на модели присутствия автора, но для других типов сайтов может привести к падению
количества запросов в секунду.
394
В конкретных требованиях может быть указано, что критичный к срокам контент должен становиться доступным мгновенно либо
быстрее, чем задано в параметрах по умолчанию. В этом случае необходимо уменьшить срок хранения данных в кэше либо
отключить кэширование вывода.
Выводы и рекомендации по использованию кэша вывода
Кэширование вывода не решает всех проблем, связанных с управлением емкостью. В некоторых ситуациях кэширование вывода
неприемлемо, и это необходимо учитывать при включении кэша вывода и настройке профилей кэша вывода.
Влияние объема считанных данных на загрузку ЦП и время отклика
Этот тест проводился в ферме с топологией 1x1 с анонимным доступом и включенным кэшированием вывода.
На приведенной ниже диаграмме показано влияние объема считанных данных на загрузку ЦП и время отклика.
395
Выводы и рекомендации по влиянию объема считанных данных на загрузку ЦП и время отклика
Как было показано в разделе Узкие места и их устранение, время отклика сервера остается постоянным, пока ресурсов ЦП вебсервера достаточно для обработки поступающих запросов. При полной загрузке ЦП веб-сервера время отклика значительно
увеличивается. При этом ферма серверов по-прежнему способна обрабатывать определенный дополнительный объем запросов.
396
Влияние операций записи на пропускную способность
Отношение количества операций создания к количеству операций изменения одинаково на протяжении тестов. При
тестировании количество операций записи в час было ограничено 500, поскольку создание или изменение более 500 страниц в
час выходит за рамки возможностей, поддерживаемых в большинстве сред SharePoint. Тест не охватывает автоматизированные
процессы, например развертывание контента, рассмотренные в разделе Влияние развертывания контента. Операции создания и
изменения могут привести к выполнению множества операций SQL Server. Следовательно, необходимо учитывать, что операции
записи, количество которых измерено в этих тестах, являются не операциями на уровне SQL Server, а операциями, которые
пользователь рассматривает как операции записи. Все тесты на количество запросов в секунду с учетом количества операций
записи в час проводились в ферме с топологией 1x1.
Сначала в тест добавлялись операции чтения до достижения загрузки ЦП веб-сервера на уровне 60-80%, чтобы оставить буфер
для скачков трафика, после чего такой уровень загрузки ЦП поддерживался на всем протяжении теста. Затем были введены
операции записи с искусственной задержкой для контроля их количества. При выполнении операций записи наблюдались скачки
загрузки ЦП веб-сервера и SQL Server. Некоторые из этих скачков для определенных значений коэффициента попадания в кэш,
как показано на приведенной ниже диаграмме, превышали пороговое значение, характерное для обычной эксплуатации, однако
среднее значение оставалось в пределах нормы.
397
398
Как показано на приведенной выше диаграмме, добавление в среду операций записи привело к незначительному снижению
пропускной способности. На графике видно изменение пропускной способности между ситуацией с доступом только на чтение и
операциями чтения на протяжении примерно 500 операций записи в час. Для каждого значения коэффициента попадания в кэш
вывода были записаны две точки данных. Таким образом, зависимость между точками данных необязательно является
линейной.
Уменьшение пропускной способности в процентах более заметно для малых значений коэффициента попадания в кэш вывода,
как показано на приведенной ниже диаграмме. Общее количество запросов на чтение в секунду в значительной степени зависит
от коэффициента попадания в кэш и не зависит от наличия операций записи.
399
400
На приведенной ниже диаграмме показано, что при добавлении в систему операций записи загрузка ЦП сервера базы данных
существенно не увеличивается. Обратите внимание на границы вертикальной шкалы — от 0 до 10 процентов мощности ЦП.
При выполнении операций записи, как и следовало ожидать, наблюдалась дополнительная нагрузка на SQL Server. Однако
наибольшее увеличение нагрузки составило 2,06%, что крайне незначительно. Средняя загрузка ЦП сервера базы данных
401
оставалась ниже 10% на протяжении всех тестов. Этот тест выполнялся в ферме с топологией 1x1. Загрузка ЦП сервера базы
данных увеличивается с увеличением количества веб-серверов. Эта ситуация подробно рассмотрена в разделе Характеристики
масштабирования для операций чтения и записи.
Во время тестирования также была измерена загрузка ЦП веб-сервера. На приведенной ниже диаграмме показано, что средняя
загрузка ЦП веб-сервера оставалась в пределах 60-80% на всем протяжении тестирования, даже когда количество операций
записи в час достигало 500.
402
403
Однако, как показано на приведенной ниже диаграмме, при выполнении операций записи наблюдались скачки фактической
загрузки ЦП. В общем и целом эти скачки проблемы не представляют. Цель зеленой зоны в том и состоит, чтобы обеспечить
буфер для сглаживания скачков загрузки ЦП. Кроме того, по мере добавления дополнительных веб-серверов скачки загрузки
распределяются между всеми серверами, что уменьшает их влияние на ЦП отдельного сервера. Однако следует иметь в виду,
что подобные скачки будут возникать в реальной среде; операции записи распределены неравномерно и обычно носят
импульсный характер.
404
405
Для типичной среды коэффициент попадания в кэш, равный 90%, крайне мал. Для большинства сред SharePoint Server 2010 с
большим количеством операций чтения этот коэффициент составляет не менее 95%.
Выводы и рекомендации по влиянию операций записи на пропускную способность
Из представленных данных следует, что операции записи не оказывают существенного влияния на общую пропускную
способность системы для читателей. Следует иметь в виду, что операции записи могут приводить к скачкам загрузки ЦП, и
спланировать конфигурацию с учетом возможных скачков. Стратегия сглаживания подобных скачков заключается в
использовании нескольких веб-серверов. Такой подход обладает двумя указанными ниже преимуществами.
 Нагрузка при выполнении операций записи распределяется между всеми веб-серверами, что позволяет сгладить скачки.

Увеличивается количество запросов на чтение в секунду, особенно при высоком коэффициенте попадания в кэш вывода.
Влияние развертывания контента
Альтернативой модели присутствия автора, при которой для изменения и чтения данных используется единая среда, является
разделение одной среды на две независимых — среду разработки и производственную среду и применение механизма
развертывания контента для копирования контента из среды разработки в производственную среду.
В подобной конфигурации в производственной среде практически не выполняются операции записи за исключением случая
импорта контента при его развертывании. В данных тестах количество операций чтения увеличивалось до тех пор, пока загрузка
ЦП веб-сервера не достигала 70-80%. После этого задание развертывания контента экспортировало 10 сайтов по 500 страниц в
каждом из семейства сайтов разработки в виде пакета и импортировало этот пакет в семейство сайтов публикации. Размер
развернутого пакета был больше размера пакетов, обычно используемых в реальных средах, чтобы обеспечить достаточную
продолжительность выполнения задания для получения результатов теста. Дополнительные сведения о характеристиках
развернутого контента см. в разделе Набор данных.
По завершении экспорта контент импортировался в отдельное семейство сайтов; во время импорта измерялась не только
пропускная способность, но и нагрузка на сервер приложений и SQL Server. Тест импорта проводился при различных значениях
коэффициента попадания в кэш вывода.
Ключевое наблюдение: импорт оказывает незначительное влияние на количество запросов на чтение в секунду, как показано на
приведенной ниже диаграмме. Также было определено, что импорт не оказывает существенного влияния на загрузку ЦП вебсервера вне зависимости от коэффициента попадания в кэш, как показано в приведенных ниже таблицах. При этом импорт
оказывает более заметное влияние на загрузку ЦП SQL Server, как показано на приведенной ниже диаграмме. Этого следовало
ожидать, поскольку при импорте контента в базу данных на сервер базы данных ложится дополнительная нагрузка. Тем не
менее, загрузка ЦП SQL Server не превышала 12% при любом значении коэффициента попадания в кэш даже во время импорта.
406
В приведенных ниже таблицах показано влияние импорта контента на загрузку ЦП веб-сервера и сервера базы данных.
407
Влияние импорта контента на загрузку ЦП веб-сервера
Попадание в кэш
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 развертывание контента можно было настроить на создание моментального снимка исходной базы
данных контента перед экспортом из нее контента. Это позволяет эффективно изолировать процесс экспорта от действий по
созданию контента, которые могут выполняться во время экспорта. Тем не менее, моментальные снимки могут повлиять на
производительность операций записи на сервере базы данных, поскольку каждый моментальный снимок увеличивает количество
операций записи. Например, если создано два моментальных снимка исходной базы данных, то при выполнении записи в базу
данных сервер базы данных копирует существующие данные в каждый снимок, после чего записывает новые данные в исходную
базу данных. Это означает, что при каждой операции записи в исходную базу данных фактически выполняются три операции:
одна для исходной базы данных и по одной для каждого моментального снимка.
408
Чтобы оценить влияние моментального снимка на среду разработки, во время экспорта при одновременном выполнении записи
было измерено количество запросов на запись в секунду, время отклика и загрузка ЦП веб-серверов, сервера базы данных и
сервера приложений. Результаты сведены в приведенные ниже таблицы.
Влияние моментальных снимков базы данных во время развертывания контента
Метрика
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%
409
Выводы и рекомендации по влиянию моментальных снимков базы данных во время экспорта
контента
Тестирование не выявило существенного влияния экспорта контента на измеренные точки данных с моментальными снимками
базы данных. Все зафиксированные отклонения находились в пределах допустимой погрешности. Отсюда следует, что
моментальные снимки базы данных можно использовать без особых последствий для производительности.
Характеристики контента
Тесты проводились для единого набора данных, специально созданного для получения ответов на конкретные вопросы. Ваш
набор данных будет отличаться от протестированного и изменится со временем. В данном разделе рассматриваются вопросы
принятия решений по управлению емкостью на основе характеристик контента, например на основе количества страниц в
библиотеке страниц и компонентов страниц.
Число страниц
Во время тестирования было измерено максимальное количество запросов в секунду для различных размеров библиотеки
страниц. Тест проводился для топологии 4x1 с отключенным кэшированием вывода и включенным анонимным доступом. Размер
каждой страницы составлял 42 КБ без сжатия и 12 КБ со сжатием. Результаты теста приведены в таблице ниже.
Влияние числа страниц в библиотеке на количество запросов в секунду
Число страниц
3
1000
20
000
Макс. кол-во запросов/сек
860
801
790
Увеличение числа страниц до 20 000 существенно не повлияло на максимальное количество запросов в секунду.
Многозначные поля подстановки
Многозначное поле подстановки представляет собой столбец в списке, ссылающийся на один или несколько элементов в другом
списке, например столбец, в котором используются корпоративные управляемые метаданные. Такие поля обычно используются
в качестве ключевых слов поиска для страницы и могут не отображаться. В некоторых случаях, например на корпоративных викисайтах, имеет смысл включать значения таких полей в контент страниц. Например, страницы при создании могут быть отнесены
к одной или нескольким категориям (например, "Международные новости", "Общественный интерес" и "Спорт" на сайте
новостей), а на главной странице может располагаться заполнитель, где будет указано, в какие категории попадает страница.
410
Использование многозначных полей подстановки приводит к тому, что при каждом запросе страницы загружается больше
данных, чем при отсутствии таких полей. Следовательно, наличие на странице нескольких многозначных полей подстановки
может повлиять на производительность.
На приведенной ниже диаграмме показано влияние многозначных полей подстановки на пропускную способность.
411
На приведенной ниже диаграмме показано влияние многозначных полей подстановки на использование ресурсов фермы.
412
413
Снижение максимального количества запросов в секунду возникает при увеличении количества многозначных полей подстановки
из-за повышения нагрузки на сеть между веб-сервером и сервером базы данных.
Влияние отчетов об использовании
Отчеты об использовании — это служба, с помощью которой администраторы отслеживают статистику об использовании сайтов.
Дополнительные сведения об этих отчетах см. в статье Configure usage and health data collection (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 в корпорации
Майкрософт.
414
Estimate performance and capacity planning for workflow in
SharePoint Server 2010 (на английском языке)
This performance and capacity planning article provides guidance on the effect that the use of workflow has on topologies that run
Microsoft SharePoint Server 2010.
For general information about capacity planning for SharePoint Server 2010, see Управление производительностью и емкостью
(SharePoint Server 2010).
Contents
 Test farm characteristics

Test results

Recommendations

Troubleshooting
Test farm characteristics
The following sections describe the characteristics of the test farm:
 Dataset

Workload

Hardware, settings, and topology
Dataset
To get benchmarks, most tests ran on a default Team Site on a single site collection in the farm. The manual start tests started workflows
by using a list that has 8,000 items.
Workload
Testing for this scenario helps develop estimates of how different farm configurations respond to changes to the following variables:
415

Effect of the number of front-end servers on throughput for manually starting declarative workflows across multiple computers

Effect of the number of front-end servers on throughput for automatically starting declarative workflows on item creation across
multiple computers
 Effect of the number of front-end servers on throughput for completing tasks across multiple computers
The specific capacity and performance figures presented in this article will differ from the figures in real-world environments. The figures
presented are intended to provide a starting point for the design of an appropriately scaled environment. After you complete the initial
system design, test the configuration to determine whether it will support the factors in your environment.
This section defines the test scenarios and discusses the test process that was used for each scenario. Detailed information such as test
results and specific parameters are given in each test result section later in this article.
Test name
Test description
Throughput for starting workflows manually
1. Associate the included MOSS Approval workflow with a list that
creates one task.
2. Populate the list with list items.
3. Call the StartWorkflow Web service method on Workflow.asmx
against the items in the list for five minutes.
4. Calculate throughput by looking at the number of workflows in
progress.
Throughput for starting workflows automatically when an item is
created
1. Associate the included MOSS Approval workflow with a list that
creates one task, set to automatically start when an item is
created.
2. Create items in the list for five minutes.
3. Calculate throughput by looking at the number of workflows in
progress.
Throughput for completing workflow tasks
1. Associate the included MOSS Approval workflow with a list that
creates one task, set to automatically start when an item is
created.
416
Test name
Test description
2. Create items in the list.
3. Call the AlterToDo Web service method on Workflows.asmx
against the items in the task list that was created by the
workflows that started.
4. Calculate throughput by looking at the number of workflows
completed.
Hardware, settings, and topology
Topologies that were used for these tests use a single computer for the content database and from one to four front-end computers that
have the default installation for SharePoint Server 2010. Although the workflows that were used in these tests are not available in
Microsoft SharePoint Foundation 2010, the results can be used to estimate similar scenarios on those deployments. The dataset that was
used for these tests contains a single site collection with a single site that is based on the Team Site template on a single content
database.
To provide a high level of test-result detail, several farm configurations were used for testing. Farm configurations ranged from one to four
Web servers and a single computer that is running Microsoft SQL Server 2008. Testing was performed with one client computer. The
database server and all Web servers were 64-bit, and the client computer was 32-bit.
The following table lists the specific hardware that was used for testing.
Web server
Database server
Processor
[email protected]
[email protected]
RAM
4 GB
16 GB
Operating system
Windows Server 2008 R2 x64
Windows Server 2008 R2
x64
Storage
680 GB
4.2 terabyte
Number of network adapters
2
2
417
Web server
Database server
Network adapter speed
1 gigabit
1 gigabit
Authentication
NTLM
NTLM
Software version
4747
SQL Server 2008 R1
Number of SQL Server instances
1
1
Load balancer type
No load balancer
No load balancer
ULS logging level
Medium
Medium
Workflow Capacity Planning Topology
418
419
Test results
The following tables show the test results for workflow in SharePoint Server 2010. For each group of tests, only certain specific variables
are changed to show the progressive effect on farm performance.
All the tests reported in this article were conducted without think time, a natural delay between consecutive operations. In a real-world
environment, each operation is followed by a delay as the user performs the next step in the task. By contrast, in the test, each operation
was immediately followed by the next operation, which resulted in a continual load on the farm. This load can cause database contention
and other factors that can adversely affect performance.
Effect of scaling the Web server on throughput
The following throughput tests were run by using the Approval workflow that is included with SharePoint Server 2010. The workflow
association assigns one task, and all instances are run on a single list. Each instance of this workflow creates the following in the content
database:
 An entry in the Workflows table to store workflow status

Five secondary list items (one task and four history items)
 Four event receivers to handle events on the workflow's parent item and task
Workflow Postpone Threshold was set to be very large so that workflow operations would never get queued. Each test was run five times,
and each test ran for five minutes.
Manual start throughput
The test in the following table shows how the addition of front-end servers affects the throughput of starting workflows synchronously
through the Web service. This test was run with a user load of 25 concurrent users continuously calling the StartWorkflow method on
Workflow.asmx and no other load on the farm. The user load was the optimal load before dropped Web requests occurred. The list is
prepopulated with up to 8,000 items.
Topology
Approval workflow maximum RPS
1x1
14.35
2x1
24.08
3x1
29.7
420
Topology
Approval workflow maximum RPS
4x1
30.77
The following graph shows how throughput changes. The addition of front-end servers does not necessarily affect farm throughput in a
linear manner but instead peaks off at around three to four front-end servers. In summary, the maximum throughput for manually starting
workflows is around 30 workflows per second, and adding more than four front-end servers will likely have an insignificant effect.
Manual start throughput
421
Automatically starting workflows when items are created throughput
The test in the following table shows how the addition of front-end servers affects the throughput of starting workflows automatically when
items are created. This test was run with a user load of 150 concurrent users continuously calling the list Web service to create new list
items in a single list and no other operations on the server. The list started as an empty list.
422
Topology
Approval workflow maximum RPS
1x1
13.0
2x1
25.11
3x1
32.11
4x1
32.18
The following graph shows how throughput changes. The throughput is very close to the manual start operations. Similar to the manual
start test, throughput peaks at approximately three or four front-end servers at approximately 32 workflows per second maximum. Adding
more than three or four front-end servers will have an insignificant effect.
Autostart workflow throughput
423
424
Task completion throughput
The test in the following table shows how the addition of front-end servers affects the throughput of completing workflow tasks. The task
list that was used by autostart workflows in the previous test was the list that was used to complete tasks. This test was run with a user
load of 25 concurrent users continuously calling the AlterToDo method on Workflow.asmx and no other operations on the server. The list
started as an empty list.
Topology
Approval workflow maximum RPS
1x1
13.5
2x1
23.86
3x1
27.06
4x1
27.14
The following graph shows how throughput changes. Similar to the manual start test, throughput peaks at approximately three or four
front-end servers at approximately 32 workflows per second maximum. Adding more than three front-end servers will have an insignificant
effect.
Task completion throughput
425
426
Effect of list size and number of workflow instances on throughput
The test in the following table shows how throughput changes as list size and number of workflows increases. Data population was done
by running the autostart workflow test continuously until 1 million items were created in the list, and stopping at different checkpoints
throughout the test to perform throughput measurements as we did with the core throughput tests. Tests were performed on a 4x1
topology.
To maintain reliability during data population, we had to keep workflow queuing turned on to avoid reaching the maximum number of
connections on the database server. If no connections are available and a workflow operation cannot connect to the content database, the
operation will be unable to run. See Recommendations for more information about workflow queuing.
Number of items or workflows
Baseline solution maximum (RPS)
0
32.18
10
32
1,000
28.67
10,000
27.16
100,000
16.98
1,000,000
9.27
Autostart throughput as number of items and workflows increases
427
428
For a single list and single task and history list, throughput decreases steadily between 1,000 and 100,000 items. However, the rate of
degradation reduces after that point. We attribute degradation of throughput to many factors.
One factor is the number of rows added to many tables in the content database per instance. As mentioned earlier, workflows create
several list items in addition to event receivers that each workflow instance registers. As table sizes grow large in different scopes, adding
rows becomes slower, and the aggregate slowdown for these additions becomes a more significant degradation than what is experienced
with only list item creation.
Task list size contributes additional overhead. In comparing throughput for workflows run on new lists versus new task lists, task lists had
a bigger effect on performance. This is because task lists register for more event receivers than the parent list items. The following chart
describes the differences.
Throughput with different list configurations (workflows Million item task list
started per second)
Empty task list
Million item list
9.27
12
Empty item list
9.3
13
If you know that you will have to run lots of workflows against large lists and need more throughput than what your tests show you can get,
consider whether your task lists can be separated between workflow associations.
Recommendations
This section provides general performance and capacity recommendations. Use these recommendations to determine the capacity and
performance characteristics of the starting topology that you created to decide whether you have to scale out or scale up the starting
topology.
For specific information about minimum and recommended system requirements, see Hardware and software requirements (SharePoint
Server 2010).
Scaled-out topologies
You can increase workflow throughput by scaling out to up to four Web servers. Then, additional increase will be insignificant. Workflow
throughput can be restricted by performance-related workflow settings. These settings are described in more detail in Workflow queuing
and performance-related settings.
429
Estimating throughput targets
Many factors can affect throughput. These factors include the number of users, and the type, complexity, and frequency of user
operations. More complex workflows that perform many operations against the content database or register for more events will run slower
and consume more resources than other workflows.
The workflow used in this test creates several entries in the content database that are built in to the task activities. If you expect to have
workflows with small numbers of tasks, you can expect similar throughput characteristics. If most workflows contain very lightweight
operations, throughput may be increased. If your workflows will consist of lots of tasks or intense back-end operations or processing
power, you can expect throughput to decrease.
In addition to understanding what the workflows will do, consider where the workflows will run and whether they will run against large lists,
on which throughput will decrease over time.
SharePoint Server 2010 can be deployed and configured in many ways. As a result, there is no simple way to estimate how many users
can be supported by a given number of servers. Therefore, make sure that you conduct testing in your own environment before you
deploy SharePoint Server 2010 in a production environment.
Workflow queuing and performance-related settings
Workflow uses a queuing system to control workflow-related stress on farm resources and the content database. By using this system,
when the number of workflows executing against a database reaches an administrator-configured threshold, successive workflow
operations are added to the queue to be run by the Workflow Timer service. By default, this service receives a batch of workflow work
items through timer jobs every minute.
Several farm administrator settings directly and indirectly related to the queuing mechanism affect the performance and scaling for
workflow. The following sections describe what these settings do and how to adjust them to meet performance requirements.
Understanding the basic queue settings
Farm administrators can adjust the following settings to configure basic characteristics of the queuing system:
 Workflow Postpone Threshold (Set-SPFarmConfig –WorkflowPostponeThreshold <integer>)
The maximum number of workflows that can execute against a single content database before additional requests and operations are
queued. Queued workflows show a status of Starting. This is a farm-wide setting that has a default value of 15. This represents the
number of workflow operations that are being processed at a time, not the maximum number of workflows that can be in progress. As
workflow operations are completed, successive operations will be able to run.
 Workflow Event Delivery Batch Size (Set-SPWorkflow –BatchSize <integer>)
430

The Workflow Timer service is an exception to the postpone threshold limit and will retrieve batches of items from the queue and
execute them one at a time. These batches can be larger than the postpone threshold. The number of work items that the service
receives per run is set by using the BatchSize property. The BatchSize property can be set one time per service instance. The
default value is 100. When running on application servers that are not configured to be front-end servers, the Workflow Timer service
requires workflow configuration settings in Web.config to be set in the configuration database. This must be done through a script that
calls UpdateWorkflowConfigurationSettings() on the SPWebApplication object, which will copy the Web.config settings from a frontend server.
Workflow Timer Job Frequency (Set-SPTimerJob job-workflow –schedule <string>)
The frequency with which the Workflow Timer service runs can be adjusted through timer job settings. By default, the service is set to
run every five minutes. This means that there can be a five-minute delay before the work items at the top of the queue are processed.
Примечание.
Scheduled work items such as task due date expirations are also picked up by the same timer mechanism. Therefore, they will be delayed
by the same time interval.
The Workflow Timer service can be turned off on each server by using Shared Services Administration in Central Administration. By
default, it will run on every front-end server in the farm. Each job will iterate through all the Web applications and content databases in the
farm.
The combination of the postpone threshold, batch size, and timer frequency can be used to limit workflow operations against the
database. Maximum throughput will be affected by how quickly operations get queued and processed from the queue.
For example, with the default settings, a single timer service, and a single content database, if there are 1,000 items in the queue, it will
take ten timer job runs to execute them all, which will take 50 minutes to execute. However, if you set the batch size to 1,000 and set the
timer job to run every minute, the operations would all begin execution after a minute. If you set the postpone threshold higher, more
operations will run synchronously, reducing the number of requests that get queued and reducing the total time that is required to process
those workflows.
431
Примечание.
We recommend setting the postpone threshold no larger than 200, because concurrent workflow instances run in their own threads and
will each open new SQL Server connections, potentially hitting the maximum connection limits on the database server over time.
If you do not want workflows running on front-end servers and know that operations do not have to occur immediately, you can isolate the
Workflow Timer service to run on select application servers, set the postpone threshold to a very low number to force workflows to usually
run in the timer service, and set the batch size large so that it receives items more quickly and frequently. If you want to make sure
workflows run more synchronously across the system, set the postpone threshold larger so that workflows are not postponed often and
have a more immediate effect.
Modify these settings to optimize for how you want workflows to operate. We recommend experimenting with different settings and testing
them to optimize them for your environments and requirements.
Adjusting settings for queuing
If the farm will sustain heavy workflow load for long periods of time or there will be many delay events queued from workflows in the
system, the number of queued workflow operations will grow. In addition to the basic queue settings, you may have to tune the following
settings to keep the queue in good health:
 Work Item Event Delivery Batchsize
The table that workflow uses for queued events is a general work item table that is shared with other non-workflow features in
SharePoint Server 2010. Thus, there is another timer job that dequeues non-workflow work items. Similar to the workflow event
delivery batch size, the work item event delivery batch size specifies the number of non-workflow work items that are dequeued at a
time.
 Workflow Failover Timer Job Frequency
In rare circumstances, if workflow events cannot be delivered to a workflow instance, the event delivery will be scheduled on the
queue as a failover work item to be retried later (starting with 5 minutes later, and then 10 minutes if it fails again, and then 20
minutes, and so on). A workflow failover timer job dequeues failover work items, and this setting adjusts the frequency at which the
failover timer will run. By default, this runs every 15 minutes.
 Workflow Failover Batchsize
Similar to the workflow and work item batch size settings, this setting controls the number of failover events that each failover timer job
will dequeue.
432
Because there are many timer jobs that operate on the same table, lots of queued items can cause database contention and reduce
throughput and reliability. To reduce contention, we recommend the following:
 Balance Postpone Threshold and Workflow Batchsize so that batch size is small enough or timer job frequency high enough that a
timer job can be completed before the next timer job starts in order to avoid building up too many parallel timer job runs that
cannot finish.

To avoid table locks, do not set either of the two batch size settings larger than 5,000.
Совет.
Offset the frequency of the workflow, work item, and failover timer jobs so that they are not always executing at the same times. To get a
large list that has workflows, four minutes for the workflow timer job and six minutes for the failover worked well in our data population
scripts.
Improving scaling for task and history lists
Workflows generate many tasks and history items per instance. By default, these lists are indexed to help with scaling, but as these lists
grow, performance will always decrease. To reduce the rate of the decrease, keep separate history and task lists for different workflow
associations, and periodically change these lists in the workflow association settings as lists become large.
Workflow also has a daily timer job (job-workflow-autoclean) that will automatically delete workflow instances and tasks for instances that
have been finished for more than 60 days. Leave this timer job on to keep the task lists and events on the task list as clean as possible. If
data must be preserved, write the data to other lists or archive locations. Workflow history items are not deleted by this timer job. If you
have to clean these up, this should be done with a script or manually through the list user interface.
Other considerations
Removing columns on lists causes a database operation proportional to the number of items in the list. Removing workflow associations
will remove the workflow status column from the list. This causes a large operation on large lists. If you know that a list has millions of
items, set the workflow to No New Instance instead of removing workflows.
433
Troubleshooting
Bottleneck
Cause
Resolution
Database contention (locks)
Database locks prevent multiple
users from making conflicting
modifications to a set of data. When
a set of data is locked by a user or
process, no other user or process
can change that same set of data
until the first user or process is
complete, changing the data and
relinquishing the lock.
To help reduce the incidence of database locks, you can do
the following:
 Distribute workflows to more document libraries.

Scale up the database server.
 Tune the database server hard disk for read/write.
Methods exist to circumvent the database locking system in
SQL Server 2005, such as the NOLOCK parameter.
However, we do not recommend or support use of this
method because of the possibility of data corruption.
Database server disk I/O
When the number of I/O requests to Distributing data files across multiple physical drives allows
a hard disk exceeds the disk's I/O
for parallel I/O. The blog SharePoint Disk Allocation and Disk
capacity, the requests will be queued. I/O (http://go.microsoft.com/fwlink/?LinkId=129557) contains
As a result, the time to complete
useful information about resolving disk I/O issues.
each request increases.
Web server CPU utilization
When a Web server is overloaded
with user requests, average CPU
utilization will approach 100 percent.
This prevents the Web server from
responding to requests quickly and
can cause timeouts and error
messages on client computers.
434
This issue can be resolved in one of two ways. You can add
Web servers to the farm to distribute user load, or you can
scale up the Web server or servers by adding faster
processors.
Web servers
The following table shows performance counters and processes to monitor for Web servers in a farm.
Performance counter
Apply to object
Notes
Processor time
Total
Shows the percentage of
elapsed time that this
thread used the processor
to execute instructions.
Memory utilization
Application pool
Shows the average
utilization of system
memory for the application
pool. You must determine
the correct application pool
to monitor.
The basic guideline is to
determine peak memory
utilization for a given Web
application, and assign
that number plus 10 to the
associated application
pool.
Database servers
The following table shows performance counters and processes to monitor for database servers in your farm.
Performance counter
Apply to object
Notes
Average disk queue length
Hard disk that contains SharedServices.mdf
Average values larger than
1.5 per spindle indicate
435
Performance counter
Apply to object
Notes
that the write times for that
hard disk are insufficient.
Processor time
SQL Server process
Average values larger than
80 percent indicate that
processor capacity on the
database server is
insufficient.
Processor time
Total
Shows the percentage of
elapsed time that this
thread used the processor
to execute instructions.
Memory utilization
Total
Shows the average
utilization of system
memory.
См. также
Другие ресурсы
Workflow Scalability and Performance in Windows SharePoint Services 3.0 (http://go.microsoft.com/fwlink/?LinkId=207353)
436
Планирование и настройка рабочих характеристик
хранилища и SQL Server (SharePoint Server 2010)
В этой статье описываются планирование и настройка уровня хранилища и базы данных Microsoft SQL Server в среде Microsoft
SharePoint Server 2010.
В процессе планирования рекомендуется руководствоваться содержащейся в этом документе информацией о планировании
загрузки. В ее основе лежат итоги тестирования, проводившегося специалистами Майкрософт в реальных условиях. Однако
конкретные достигаемые результаты могут варьироваться в зависимости от используемого оборудования и от состава
реализованных функций и возможностей.
Поскольку SharePoint Server часто работает в средах с базами данных, управляемыми отдельными администраторами баз
данных SQL Server, настоящий документ рассчитан на совместное использование специалистами по развертыванию ферм
SharePoint Server и администраторами баз данных SQL Server. Это предполагает наличие глубоких знаний SharePoint Server и
SQL Server.
Перед чтением этой статьи необходимо ознакомиться с общими принципами, изложенными в документе Capacity management
and sizing for SharePoint Server 2010 (на английском языке).
Процесс проектирования и настройки уровня хранилища и базы
данных для продуктов SharePoint 2010
Процесс проектирования и настройки уровня хранилища и базы данных рекомендуется разбить на этапы, как описано ниже. В
каждом разделе приводятся подробные сведения о соответствующем шаге проектирования, включая требования к объему
хранилища и практические рекомендации:
 Определение требований к дисковому пространству и подсистеме ввода-вывода для хранилища и SQL Server

Выбор версии и выпуска SQL Server

Проектирование архитектуры хранилища на основе требований по емкости и вводу-выводу
437

Оценка требований к памяти

Общие сведения о требованиях к топологии сети

Настройка конфигурации SQL Server

Проверка производительности и надежности хранилища
Определение требований к дисковому пространству и подсистеме
ввода-вывода для хранилища и SQL Server
Структура хранилища определяется рядом факторов, связанных с архитектурой SharePoint Server 2010. Наиболее важные
факторы — объем контента, используемые функции и приложения-службы, число ферм и требования доступности.
Прежде чем планировать систему хранения, необходимо понять, какие базы данных могут использоваться в SharePoint Server
2010.
Содержание:
 Базы данных, используемые продуктами SharePoint 2010

Общие сведения о SQL Server и IOPS

Оценка основных требований по объему хранилища и показателям IOPS

Определение требований по объему хранилища и IOPS для приложений-служб

Определение потребностей в доступности
Базы данных, используемые продуктами SharePoint 2010
Состав баз данных, устанавливаемых вместе с SharePoint Server 2010, зависит от того, какие функции используются в текущей
среде. В основе любой среды SharePoint 2010 лежат системные базы данных SQL Server. В этом разделе дается сводка баз
данных, устанавливаемых вместе с SharePoint Server 2010. Более подробную информацию см. в разделе Database types and
descriptions (SharePoint Server 2010) и в статье, посвященной модели базы данных (Возможно, на английском языке)
(http://go.microsoft.com/fwlink/?linkid=187968&clcid=0x419) (Возможно, на английском языке).
Версия и выпуск продукта
Базы данных
SharePoint Foundation 2010
Конфигурация
438
Версия и выпуск продукта
Базы данных
Контент центра администрирования
Контент (одна или несколько)
Служба сбора данных об использовании и исправности
Служба подключения к бизнес-данным
Служба реестра приложений (как обновление каталога бизнесданных Microsoft Office SharePoint Server 2007)
Служба параметров подписки (включенная в Windows PowerShell)
Дополнительные базы данных для выпуска SharePoint Server 2010 Приложение-служба поиска:
Standard
 Администрирование поиска

Обход контента (одна или несколько)
 Свойства (одна или несколько)
Приложение-служба профилей пользователей:

Профиль

Синхронизация
 Теги
Приложение-служба Web Analytics

Поэтапное развертывание
 Отчетность
Безопасное хранилище
Состояние
Управляемые метаданные
Word Automation Services
Дополнительные базы данных для выпуска SharePoint Server 2010 PerformancePoint
Enterprise
439
Версия и выпуск продукта
Базы данных
Дополнительные базы данных для Project Server 2010
Черновики
Опубликованные проекты
Архив
Отчетность
Дополнительная база данных для FAST Search Server
Администрирование поиска
В случае более полной интеграции с SQL Server в среду могут быть также включены дополнительные базы данных, как,
например, в следующих ситуациях.
 Microsoft SQL Server 2008 R2 PowerPivot для Microsoft SharePoint 2010 может использоваться в среде SharePoint Server 2010,
включающей выпуск SQL Server 2008 R2 Enterprise и службы аналитики SQL Server. В этом случае необходимо также
запланировать поддержку базы данных приложения PowerPivot и дополнительную нагрузку на систему. Дополнительную
информацию см. в статье, посвященной планированию развертывания PowerPivot в ферме SharePoint
(http://go.microsoft.com/fwlink/?linkid=186698&clcid=0x419).

В любой среде продуктов SharePoint 2010 можно использовать подключаемый модуль отчетов Microsoft SQL Server 2008
(SSRS). Если он используется, запланируйте поддержку двух баз данных отчетов SQL Server 2008 и дополнительную
нагрузку, связанную с отчетов SQL Server 2008.
Общие сведения о SQL Server и IOPS
На любом сервере, где размещается SQL Server, крайне важно обеспечить максимально быстрый ответ подсистемы вводавывода.
Увеличение числа дисков или массивов и повышение их быстродействия гарантируют достаточное количество операций вводавывода в секунду (IOPS) при низкой задержке в обработке доступа и обслуживании очередей на всех дисках.
Медленная реакция подсистемы ввода-вывода не может компенсироваться наращиванием ресурсов других типов, например ЦП
или памяти; более того, она может неблагоприятно отражаться на работе других компонентов фермы. Необходимо
запланировать обеспечение минимальной задержки перед развертыванием и вести мониторинг существующих систем.
Перед развертыванием новой фермы рекомендуется провести сравнительное тестирование подсистемы ввода-вывода,
используя средство эталонного тестирования дисковой подсистемы SQLIO. Подробнее об этом см. в статье, посвященной
440
средству эталонного тестирования дисковой подсистемы SQLIO (Возможно, на английском языке)
(http://go.microsoft.com/fwlink/?linkid=105586&clcid=0x419) (Возможно, на английском языке).
Более подробную информацию о том, как анализировать требования по IOPS с точки зрения SQL Server, см. в статье,
посвященной анализу характеристик ввода-вывода и определение размеров систем хранения данных для приложений баз
данных SQL Server (Возможно, на английском языке) (http://sqlcat.com/whitepapers/archive/2010/05/10/analyzing-i-o-characteristicsand-sizing-storage-systems-for-sql-server-database-applications.aspx) (Возможно, на английском языке).
Оценка основных требований по объему хранилища и показателям IOPS
Емкость хранилища конфигурации и контента и соответствующие показатели IOPS — это главное, что необходимо планировать
в каждой среде SharePoint Server 2010.
Хранилище конфигурации и IOPS
Требования к емкости хранилища для баз данных конфигурации и контента центра администрирования не слишком высоки.
Рекомендуется выделить 2 ГБ для базы данных конфигурации и 1 ГБ для базы данных контента центра администрирования. Со
временем размер базы данных конфигурации может превысить 1 ГБ, но он растет не очень быстро — примерно на 40 МБ для
каждых 50 тысяч семейств сайтов.
Журналы транзакций базы данных конфигурации могут занимать много места, поэтому рекомендуется заменить полную модель
восстановления базы данных на простую.
Примечание.
Если для повышения доступности базы данных конфигурации требуется использовать зеркальное отображение баз данных SQL Server,
необходимо использовать полную модель восстановления.
Требования по IOPS для баз данных конфигурации и контента центра администрирования минимальны.
Хранилище контента и IOPS
Оценка объема хранилища и уровня IOPS, необходимых для баз данных контента, не предполагает высокой точности. Тестируя
и комментируя приведенные ниже показатели, мы полагаем, что это позволит получить оценки, которые можно будет
использовать при определении начального размера развертываемой среды. Однако после ввода среды в эксплуатацию
рекомендуется пересмотреть требования к емкости исходя из данных, полученных в реально работающей среде.
441
Дополнительные сведения о методологии общего планирования загрузки см. в статье Capacity management and sizing for
SharePoint Server 2010 (на английском языке).
Оценка объема хранилища для базы данных контента
Далее описывается процедура приблизительной оценки размера пространства, необходимого для баз данных контента (без
учета файлов журналов).
1. Подсчитайте предполагаемое количество документов. Оно обозначается в формуле буквой D.
Способ подсчета документов будет определяться используемыми функциями. Например, для личных веб-сайтов и сайтов
совместной работы рекомендуется оценивать ожидаемое число документов в расчете на пользователя и умножать эту
оценку на количество пользователей. Для сайтов управления записями и публикации контента можно подсчитывать число
документов, управляемых и генерируемых процессом.
В случае перехода из существующей системы целесообразно экстраполировать текущие темпы роста и показатели
использования. Если создается новая система, просмотрите имеющиеся общие папки файлов и другие репозитории и
вынесите оценку, опираясь на данные об их использовании.
2. Оцените средний размер документов, которые будут помещаться в хранилище. Он обозначается в формуле буквой S. Имеет
смысл оценивать средние значения для разных типов или групп сайтов. Средние размеры файла для личных сайтов,
мультимедийных репозиториев и ведомственных порталов могут существенно отличаться друг от друга.
3. Оцените число элементов списков в среде. Оно обозначается в формуле буквой L.
Элементы списков труднее оценивать, чем документы. Обычно их число примерно втрое больше числа документов (D), но
оно в значительной степени зависит от того, как предполагается использовать сайты.
4. Определите примерное число версий. Оцените, сколько версий в среднем будет иметь документ библиотеки (обычно это
значение гораздо меньше максимально допустимого числа версий). Оно обозначается в формуле буквой V.
Значение V должно быть больше нуля.
5. Оцените размер баз данных контента по следующей формуле:
Размер базы данных = ((D × V) × S) + (10 КБ × (L + (V × D)))
В этой формуле константа 10 КБ представляет примерную оценку объема метаданных, необходимых для SharePoint Server
2010. Если в системе требуется активно использовать метаданные, эту константу можно увеличить.
Например, если по этой формуле оценить объем пространства, необходимого для файлов данных базы данных контента в среде
совместной работы с приведенными ниже характеристиками, получится около 105 ГБ.
442
Входные данные
Значение
Число документов (D)
200 000
Из расчета 10 000 пользователей с 20 документами каждый
Средний размер документа (S)
250 КБ
Элементы списков (L)
600 000
Число версий, помимо текущей (V)
2
При максимально допустимом числе версий 10
Размер базы данных = (((200000 x 2)) × 250) + ((10 КБ × (600000 + (200000 x 2))) = 110000000 КБ, или 105 ГБ
Функциональные элементы, влияющие на размер баз данных контента
Использование следующих функциональных элементов SharePoint Server 2010 может существенно повлиять на размер баз
данных контента:
 Корзины Пока документ не удален окончательно из корзин первого и второго уровней, он занимает место в базе данных
контента. Подсчитайте, сколько документов удаляется каждый месяц, чтобы определить, как наличие корзин отражается на
размере баз данных контента. Дополнительную информацию см. в статье Configure Recycle Bin settings (SharePoint Server
2010).


Аудит Данные аудита могут быстро разрастаться, занимая немало места в базе данных контента, особенно если включен
аудит представлений. Рекомендуется ограничить рост данных аудита, включив аудит только событий, важных с точки зрения
внутреннего или внешнего нормативного контроля. При оценке места, которое следует зарезервировать для данных аудита,
придерживайтесь следующих указаний.

Оцените число новых записей аудита для сайта и умножьте его на 2 КБ (максимальный размер записи обычно составляет
4 КБ, средний — около 1 КБ).

Исходя из размера выделяемого пространства, определите, сколько дней следует хранить журналы аудита.
Office Web Apps. Если используется Office Web Apps, объем кэша Office Web Apps может существенно повлиять на размер
базы данных контента. По умолчанию объем кэша Office Web Apps устанавливается равным 100 ГБ. Дополнительную
информацию о размере кэша Office Web Apps см. в статье Manage the Office Web Apps cache.
443
Оценка требований по IOPS для базы данных контента
Требования к показателям IOPS для баз данных контента варьируются в зависимости от используемой среды, размера
дискового пространства и числа серверов. В общем случае рекомендуется сравнить прогнозируемую рабочую нагрузку в текущей
среде с одним из протестированных нами решений. Подробнее об этом см. в разделе Результаты тестирования
производительности и емкости и рекомендации (SharePoint Server 2010).
Важно!
Тестирование контента, описываемое в этом разделе, еще не завершено. Регулярно возвращайтесь к нему за дополнительной
информацией.
Оценка требований к объему хранилища и IOPS для приложений-служб
Оценив требования к объему хранилища и IOPS для контента, необходимо определить аналогичные требования в отношении
приложений-служб, используемых в рабочей среде.
Требования к объему хранилища и IOPS для приложений-служб SharePoint Foundation 2010
Для оценки требований к системе хранения для приложений-служб сначала следует ознакомиться с приложениями-службами и
способом их использования. Приложения-службы, доступные в SharePoint Foundation 2010 и использующие базы данных,
указаны в следующей таблице.
База данных приложения-службы
Рекомендации по оценке размера
Служба сбора данных об использовании и исправности
База данных использования может очень быстро расти в размерах и
требовать высокого уровня IOPS.
Например, в среде совместной работы с заранее установленными
параметрами для 1 миллиона HTTP-запросов требуется 2 ГБ.
Оцените требуемое значение IOPS по одной из двух следующих
формул:

444
115 × число обращений к страницам в секунду
База данных приложения-службы
Рекомендации по оценке размера
 5 × число HTTP-запросов
Если необходимо ограничить размер базы данных использования,
рекомендуется начать с того, что записывать в журнал только
запросы страниц. Можно также установить длительность хранения
данных по умолчанию не более двух недель.
Если это возможно, разместите базу данных использования на
отдельном диске.
Служба подключения к бизнес-данным
На размер базы данных служб подключения к бизнес-данным в
первую очередь влияет число типов внешнего контента, которые
планируется поддерживать. Выделите 0,5 МБ для каждого типа
внешнего контента. Если точное число типов внешнего контента,
которые могут потребоваться, неизвестно, рекомендуется выделить
50 МБ. Требования по IOPS минимальны.
Служба реестра приложений
Выделите 1 ГБ, если осуществляется обновление каталога бизнесданных Microsoft Office SharePoint Server 2007. Требования по
IOPS минимальны.
Параметры подписки
Выделите 1 ГБ. Требования по IOPS минимальны.
Требования к объему хранилища и IOPS для приложений-служб SharePoint Server 2010
Для оценки требований к системе хранения для приложений-служб сначала следует ознакомиться с приложениями-службами и
способом их использования. Приложения-службы, доступные в SharePoint Server 2010 и использующие базы данных, указаны в
следующей таблице.
Приложение-служба
Рекомендации по оценке размера
Поиск
Для поиска требуются три базы данных. Рабочая среда может
445
Приложение-служба
Рекомендации по оценке размера
включать несколько баз данных свойств и обхода контента.
База данных администрирования поиска обычно невелика —
достаточно выделить 10 ГБ.
Чтобы оценить требуемое пространство для баз данных свойств и
обхода контента, используйте следующие коэффициенты:

Обход контента: 0,046 × (суммарный размер баз данных
контента)
 Свойства: 0,015 × (суммарный размер баз данных контента)
Требования к IOPS для поиска достаточно высоки.

Для базы данных обхода контента поиск требует от 3500 до
7000 IOPS.
 Для базы данных свойств поиск требует 2000 IOPS.
Подробную информацию об оценке ресурсов, необходимых для
поиска, см. в статье Результаты тестирования производительности и
емкости и рекомендации (SharePoint Server 2010).
Профиль пользователя
Приложение-служба профилей пользователей связано с тремя
базами данных: базой данных профилей, базой данных
синхронизации и базой данных тегов.
Чтобы оценить объем хранилища, необходимого для этих баз
данных, используйте следующую информацию.

Профиль. В среде со стандартными настройками,
использующей Active Directory, для базы данных профилей
требуется примерно 1 МБ на каждый профиль.

Синхронизация. В среде со стандартными настройками при
наличии нескольких групп на одного пользователя для базы
данных синхронизации требуется примерно 630 КБ на
каждый профиль пользователя. 90% этого пространства
446
Приложение-служба
Рекомендации по оценке размера
займет файл данных.

Теги. При стандартных настройках для базы данных тегов
требуется примерно 0,009 МБ на каждый тег, комментарий
или оценку. При расчете количества тегов или заметок, с
которыми будут работать пользователи, используйте
следующую информацию о сайте del.icio.us:

Примерно 10% пользователей считаются активными.

Активные пользователи создают по 4,5 тега и 1,8
комментариев в месяц.
В интерактивной среде совместной работы, где насчитывается 160
тыс. профилей пользователей, 5 групп, 79 тыс. тегов, комментариев
и оценок (2500 комментариев, 76 000 тегов и 800 оценок), при
стандартных настройках базы данных достигают следующих
размеров:
Управляемые метаданные
Имя базы данных
Размер базы данных
Профиль
155 ГБ
Синхронизация
96 ГБ
Теги
0,66 ГБ
Приложение-служба управляемых метаданных использует одну базу
данных. Ее размер определяется числом типов контента и ключевых
слов, используемых в системе. Нередко в одной среде
развертывается несколько экземпляров приложения-службы
управляемых метаданных. Подробную информацию об оценке
447
Приложение-служба
Рекомендации по оценке размера
требований к размеру этой базы данных и уровню IOPS см. в статье
Результаты тестирования производительности и емкости и
рекомендации (SharePoint Server 2010).
Web Analytics
Служба Web Analytics использует две базы данных: базу данных
поэтапного развертывания и базу данных отчетности. На их размер
влияют многие факторы, включая срок хранения данных, объем
ежедневно отслеживаемых данных, число сайтов, семейств сайтов и
дочерних сайтов в анализируемом приложении. Подробную
информацию об оценке требований к размерам и IOPS см. в статье
Результаты тестирования производительности и емкости и
рекомендации (SharePoint Server 2010).
Безопасное хранилище
Размер базы данных приложения-службы Secure Store определяется
числом учетных записей в хранилище и числом строк в таблице
аудита. Рекомендуется выделить пространство из расчета 5 МБ на
каждую тысячу учетных записей. Требования по IOPS минимальны.
Состояние
Приложение-служба состояния использует одну базу данных. Для
нее рекомендуется выделить 1 ГБ. Требования по IOPS
минимальны.
Служба автоматизации Word
Приложение-служба автоматизации Word использует одну базу
данных. Для нее рекомендуется выделить 1 ГБ. Требования по IOPS
минимальны.
PerformancePoint
Приложение-служба PerformancePoint использует одну базу данных.
Для нее рекомендуется выделить 1 ГБ. Требования по IOPS
минимальны.
448
Определение потребностей в доступности
Доступность — это степень, в которой среда SharePoint Server 2010 воспринимается пользователями как доступная. Доступная
система устойчива, то есть влияющие на службу инциденты возникают нечасто, и при их возникновении предпринимаются
своевременные и эффективные меры.
Требования в отношении доступности могут существенно увеличить объем необходимого пространства. Дополнительные
сведения об этом см. в статье Plan for availability (SharePoint Server 2010).
Выбор версии и выпуска SQL Server
Хотя SharePoint 2010 может работать в среде Microsoft SQL Server 2008 R2, SQL Server 2008 или SQL Server 2005, настоятельно
рекомендуется использовать среду SQL Server 2008 или SQL Server 2008 R2 выпуска Enterprise, чтобы получить доступ к
предлагаемым ими возможностям повышения производительности, доступности, безопасности и управляемости.
Дополнительную информацию о преимуществах использования SQL Server 2008 R2 Enterprise Edition см. в статье SQL Server
2008 R2 and SharePoint Products 2010: Better Together (White paper) (SharePoint Server 2010).
В частности, могут оказаться полезными следующие функции:
 Сжатие резервных копий Сжатие резервных копий позволяет ускорить резервное копирование в SharePoint; оно доступно
в выпусках SQL Server 2008 Enterprise и SQL Server 2008 R2 Standard. Установив параметр сжатия в скрипте резервного
копирования или настроив сервер с SQL Server для сжатия по умолчанию, можно значительно сократить размер резервных
копий базы данных и доставляемых журналов. Дополнительную информацию см. в статье, посвященной сжатию резервных
копий (SQL Server) (http://go.microsoft.com/fwlink/?linkid=129381&clcid=0x419).
Примечание.
Сжатие данных SQL Server не поддерживается для SharePoint 2010.

Прозрачное шифрование данных Если требования безопасности включают прозрачное шифрование данных, необходимо
использовать выпуск SQL Server Enterprise.

Приложение-служба Web Analytics Если для проведения анализа планируется привлекать приложение-службу Web
Analytics, целесообразно использовать выпуск SQL Server Enterprise, чтобы в системе можно было использовать разбиение
таблиц на разделы.

Развертывание контента Если планируется использовать средство развертывания контента, рекомендуется выбрать SQL
Server Enterprise, чтобы в системе можно было использовать снимки базы данных SQL Server.
449

Удаленное хранилище больших двоичных объектов Чтобы обеспечить удаленное хранение больших двоичных
объектов в базе данных или каталоге вне набора файлов, связанных с каждой базой данных контента, необходимо
использовать выпуск SQL Server 2008 или SQL Server 2008 R2 Enterprise.

Регулятор ресурсов Регулятор ресурсов — новый компонент, впервые появившийся в SQL Server 2008, который позволяет
управлять рабочей нагрузкой и ресурсами SQL Server, устанавливая предельные уровни потребления ресурсов для
входящих запросов. Регулятор ресурсов дает возможность дифференцировать рабочие нагрузки и выделять ресурсы ЦП и
памяти по запросам исходя из установленных пределов. Он доступен только в SQL Server 2008 и SQL Server 2008 R2
Enterprise. Дополнительную информацию об использовании регулятора ресурсов см. в статье, посвященной управлению
рабочей нагрузкой и ресурсами SQL Server.
Регулятор ресурсов рекомендуется использовать вместе с SharePoint Server 2010, чтобы решать следующие задачи:
 Ограничивать объем ресурсов SQL Server, которые потребляются веб-серверами, охватываемыми компонентом обхода
контента при поиске. Рекомендуется установить для компонента обхода контента ограничение в 10 % от ресурсов ЦП,
доступных в системе, находящейся под нагрузкой.


Отслеживать количество ресурсов, потребляемых в системе каждой базой данных, — например, с помощью регулятора
ресурсов можно определять наилучший порядок размещения баз данных на компьютерах SQL Server.
PowerPivot для SharePoint 2010
Позволяет пользователям совместно работать с создаваемыми ими моделями
данных и анализами в Excel и браузере с автоматическим обновлением результатов анализа. Входит в состав SQL Server
2008 R2 Enterprise Edition Analysis Services.
Проектирование архитектуры хранилища на основе требований по
емкости и вводу-выводу
Производительность системы в немалой степени зависит от архитектуры хранилища и типов дисков, выбранных для рабочей
среды.
Содержание:
 Выбор архитектуры хранилища

Выбор типов дисков

Выбор типов RAID
450
Выбор архитектуры хранилища
В SharePoint Server 2010 поддерживаются архитектуры хранилищ DAS (Direct Attached Storage), SAN (Storage Area Network) и
NAS (Network Attached Storage), причем NAS поддерживается только для баз данных контента, настроенных на использование
удаленного хранилища больших двоичных объектов. Выбор архитектуры зависит от многих факторов, связанных с
используемым бизнес-решением и имеющейся инфраструктурой.
Любая архитектура хранилища должна соответствовать требованиям в отношении доступности, IOPS и задержки. Для гарантии
поддержки необходимо, чтобы система стабильно возвращала первый байт данных в течение 20 миллисекунд (мс).
DAS
DAS — цифровая система хранения, подсоединяемая к серверу или рабочей станции непосредственно, без использования
промежуточной сети хранения. Типы физических дисков DAS включают SAS (Serial Attached SCSI) и SATA (Serial Attached ATA).
В общем случае рекомендуется выбирать архитектуру DAS, если платформа общего хранилища не гарантирует время реакции
20 мс и достаточные значения среднего и пикового показателей IOPS.
SAN
SAN — архитектура для подсоединения запоминающих устройств удаленных компьютеров (дисковых массивов, библиотек лент)
к серверам, при котором эти устройства представлены как локально подключенные к операционной системе (например, блочное
хранилище).
В общем случае SAN рекомендуется выбирать, когда для организации важное значение имеют преимущества общего
хранилища.
Общее хранилище обладает следующими преимуществами:
 Упрощается перераспределение дискового пространства между серверами.

Обслуживается сразу несколько серверов.

Число дисков, к которым может производиться доступ, неограниченно.
NAS
Устройство NAS — это автономный компьютер, подключенный к сети. Его единственное назначение состоит в том, чтобы
предоставлять услуги файлового хранилища данных другим устройствам сети. Операционная система и другие программные
средства устройства NAS обеспечивают функциональные возможности хранилища данных, файловых систем и файлового
доступа, а также управление этими функциями (например, файловое хранилище).
451
Примечание.
NAS поддерживается только для баз данных контента, настроенных на использование удаленного хранилища больших двоичных
объектов. Любое устройство NAS должно отвечать на команду ping в течение 1 мс и возвращать первый байт данных в течение 20 мс. Это
ограничение не распространяется на локальный провайдер SQL Server FILESTREAM, поскольку он сохраняет данные только локально,
на том же сервере.
Выбор типов дисков
От типов дисков, используемых в системе, может зависеть ее надежность и производительность. При прочих равных условиях,
чем больше диск, тем больше среднее время поиска дорожки. SharePoint Server 2010 поддерживает следующие типы дисков:
 SCSI (Small Computer System Interface)

SATA (Serial Advanced Technology Attachment)

SAS (Serial-attached SCSI)

FC (Fibre Channel)

IDE (Integrated Device Electronics)

SSD (Solid State Drive) или флэш-диск
Выбор типов RAID
Технология RAID (избыточный массив независимых дисков) часто используется для повышения производительности отдельных
дисков (путем расслоения данных по нескольким дискам) и усиления защиты от сбоев отдельных дисков.
В SharePoint Server 2010 поддерживаются все типы RAID, однако использовать рекомендуется RAID 10 или специализированное
решение RAID с эквивалентными характеристиками.
При настройке массива RAID убедитесь, что файловая система выровнена по смещению, установленному производителем
дисков. В отсутствие указаний производителя см. статью, содержащую практические советы по настройке ввода-вывода перед
развертыванием SQL Server (Возможно, на английском языке) (http://go.microsoft.com/fwlink/?linkid=105583&clcid=0x419)
(Возможно, на английском языке).
Дополнительные сведения об инициализации RAID и подсистемы ввода-вывода SQL Server см. в статье, содержащей
практические советы по SQL Server (Возможно, на английском языке) (http://go.microsoft.com/fwlink/?linkid=168612&clcid=0x419)
(Возможно, на английском языке).
452
Оценка требований к памяти
Объем памяти, необходимой для SharePoint Server 2010, непосредственно связан с размерами баз данных контента,
размещенных на сервере SQL Server.
По мере добавления приложений-служб и функциональных компонентов требования, вероятно, будут расти. В следующей
таблице приводятся рекомендации по объему памяти.
Примечание.
Здесь используются определения небольшой и средней среды развертывания из раздела «Базовые архитектуры» статьи Capacity
management and sizing for SharePoint Server 2010 (на английском языке).
Общий размер баз данных контента
Рекомендуемый объем ОЗУ для компьютера SQL Server
Минимум для небольшой рабочей среды развертывания
8 ГБ
Минимум для средней рабочей среды развертывания
16 ГБ
Рекомендуемый размер до 2 терабайт
32 ГБ
Рекомендуемый размер в диапазоне от 2 до 5 терабайт
64 ГБ
453
Примечание.
Эти значения выше тех, что рекомендуются в качестве минимальных для SQL Server, поскольку учитывают данные, необходимые для
среды SharePoint Server 2010. Дополнительную информацию о системных требованиях SQL Server см. в статье, посвященной
требованиям к оборудованию и программному обеспечению для установки SQL Server 2008
(http://go.microsoft.com/fwlink/?linkid=129377&clcid=0x419).
На объем памяти могут влиять и другие факторы:
 Использование зеркального отображения SQL Server.

Частое использование файлов размером более 15 МБ.
Общие сведения о требованиях к топологии сети
Необходимо планировать систему сетевых подключений внутри ферм и между фермами. Рекомендуется использовать сеть с
низкой задержкой.
Далее приводятся некоторые практические советы и рекомендации:
 Соединение между любым сервером фермы и сервером SQL Server должно иметь пропускную способность и задержку
уровня локальной сети. Задержка не должна превышать 1 мс.

Не рекомендуется использовать топологию территориально-распределенной сети, в которой сервер SQL Server
развертывается из других компонентов фермы в удаленном режиме по сети с задержкой более 1 мс. Такая топология не
тестировалась.

Разворачивайте соответствующую территориально-распределенную сеть, если планируется использовать зеркальное
отображение или доставку журналов SQL Server для поддержания актуального состояния удаленных сайтов.

Рекомендуется оборудовать веб-серверы и серверы приложений двумя сетевыми адаптерами: один адаптер будет
обрабатывать трафик конечных пользователей, а другой обеспечивать связь с серверами SQL Server.
454
Настройка конфигурации SQL Server
В следующих разделах описывается планирование настройки конфигурации SQL Server для SharePoint Server 2010.
Содержание:
 Определение требуемого количества экземпляров серверов

Конфигурация дискового пространства и памяти

Задание параметров SQL Server

Конфигурация баз данных
Оценка требуемого числа серверов
В целом сервер SharePoint Server 2010 разрабатывался в расчете на использование горизонтального масштабирования SQL
Server — т. е. SharePoint Server 2010 может работать лучше с большим числом серверов среднего размера, на которых запущен
SQL Server, чем с небольшим числом крупных серверов.
Всегда размещайте SQL Server на выделенном сервере, которому не назначены никакие другие роли в ферме и где не
размещаются базы данных каких-либо других приложений (если только система не развертывается на автономном сервере).
Необходимость в развертывании дополнительного сервера базы данных SQL Server может возникать в следующих случаях:
 если используется более четырех веб-серверов, использующих полную емкость;

если общий размер баз данных контента превышает 5 терабайт.
Примечание.
Майкрософт поддерживает серверные конфигурации, не соответствующие этим условиям.
Чтобы организовать надежное хранение учетных данных при использовании приложения-службы Secure Store, рекомендуется
разместить базу данных безопасного хранения на отдельном экземпляре сервера базы данных, доступ к которому имеет только
один администратор.
Конфигурация дискового пространства и памяти
На сервере, на котором запущен SQL Server 2008, рекомендуется отвести для кэша второго уровня на каждом ЦП не менее 2 МБ
для оптимизации работы памяти.
455
Следуйте рекомендациям производителя по настройке конфигурации хранилища
Чтобы добиться оптимальной производительности при настройке физического хранилища, придерживайтесь рекомендаций по
конфигурации оборудования от производителя устройств хранения, а не полагайтесь на значения, устанавливаемые в
операционной системе по умолчанию.
В отсутствие указаний от производителя рекомендуется настраивать хранилище для SQL Server 2008 с помощью использовать
служебной программы конфигурирования дисков DiskPart.exe. Дополнительную информацию см. в статье, содержащей
практические советы по настройке ввода-вывода перед развертыванием (Возможно, на английском языке)
(http://go.microsoft.com/fwlink/?linkid=105583&clcid=0x419) (Возможно, на английском языке).
Подготовьте как можно больше ресурсов
Убедитесь, что каналы ввода-вывода SQL Server, предназначенные для обмена данными с дисками, не используются другими
приложениями, например файлом подкачки страниц или журналами IIS.
Обеспечьте максимальную пропускную способность шины. Чем она больше, тем выше надежность и производительность.
Имейте в виду, что диск — не единственный потребитель полосы пропускания шины; например, следует всегда учитывать
сетевой доступ.
Задание параметров SQL Server
Перед развертыванием SharePoint Server необходимо настроить следующие параметры SQL Server.
 Не включайте автоматическое создание статистики на сервере SQL Server, поддерживающем SharePoint Server. В SharePoint
Server реализованы определенные виды статистики и никакой дополнительной статистики не требуется. Автосоздание
статистики может существенно изменить план выполнения запроса, передав его из одного экземпляра SQL Server в другой
экземпляр SQL Server. Поэтому для согласованной поддержки всех клиентов SharePoint Server по мере необходимости
предлагает кодированные указания к запросам, чтобы добиться наилучшей производительности независимо от сценария
работы.

Для обеспечения оптимальной производительности настоятельно рекомендуется присвоить параметру max degree of
parallelism (максимальная степень параллелизма) значение 1 для серверов баз данных SharePoint Server 2010.
Дополнительную информацию об этой настройке см. в статье, посвященной параметру max degree of parallelism
(http://go.microsoft.com/fwlink/?linkid=189030&clcid=0x419).

Для удобства сопровождения определите псевдонимы подключений к SQL Server для каждого сервера базы данных,
входящего в ферму. Псевдоним подключения — это альтернативное имя, которое может быть использовано для
подключения к экземпляру SQL Server. Дополнительную информацию см. в статье, посвященной установки псевдонима SQL
Server (среда SQL Server Management Studio) (http://go.microsoft.com/fwlink/?linkid=132064&clcid=0x419).
456
Конфигурация баз данных
Ниже приводятся практические рекомендации по настройке конфигурации баз данных, включенных в рабочую среду.
Приоритеты данных и их распределение по дискам
В идеальном варианте базу данных tempdb, базы данных контента, базу данных использования, базы данных поиска и журналы
транзакций SQL Server 2008 следовало бы размещать на разных жестких дисках.
Далее приводятся некоторые практические советы и рекомендации по назначению приоритетов данным.
 При выборе данных для более быстродействующих дисков соблюдайте следующую очередность:
1. Файлы данных tempdb и журналы транзакций
2. Файлы журналов транзакций баз данных
3. Базы данных поиска, исключая базу данных администрирования поиска

4. Файлы данных баз данных
На сайте портала, используемом преимущественно в режиме чтения, файлы данных имеют более высокий приоритет,
чем журналы.
Результаты тестирования и отзывы клиентов свидетельствуют о том, что производительность фермы SharePoint Server 2010
может значительно упасть из-за недостаточно быстрого выполнения дисковых операций ввода-вывода для tempdb. Чтобы
избежать этого, размещайте tempdb на выделенных дисках. Если наблюдается или ожидается высокая нагрузка (т. е.
среднее время операции чтения или записи превышает 20 мс), разместите файлы на разных дисках или замените диски
более быстродействующими.

Для достижения наилучшей производительности разместите tempdb в массиве RAID 10. Число файлов данных tempdb
должно равняться числу ЦП, и эти файлы должны быть одинакового размера. При этом подсчете принимайте двухъядерный
процессор за два ЦП, а каждый процессор, поддерживающий Hyper-Threading, — за один ЦП. Дополнительную информацию
см. в статье, посвященной оптимизации производительности базы данных tempdb
(http://go.microsoft.com/fwlink/?linkid=148537&clcid=0x419).

Размещайте файлы данных и файлы журналов транзакций базы данных на разных дисках. Если их приходится размещать на
одних и тех же дисках из-за слишком маленького размера файлов, делающего нецелесообразным выделение целого диска
или чередование томов, или из-за дефицита дискового пространства, помещайте на один диск файлы с разными схемами
использования, чтобы свести к минимуму вероятность одновременных запросов доступа.
457

Выясните у производителя используемых устройств хранения данных, как настроить журналы и базы данных поиска для
оптимизации записи в данном решении хранилища.
Использование нескольких файлов данных для баз данных контента
Для достижения наилучшей производительности придерживайтесь следующих рекомендаций.
 Создавайте файлы только в первичной файловой группе базы данных.

Размещайте файлы на нескольких дисках.

Число файлов данных не должно превышать количества ЦП. При этом подсчете принимайте двухъядерный процессор за два
ЦП, а каждый процессор, поддерживающий Hyper-Threading, — за один ЦП.

Создавайте файлы данных одинакового размера.
Важно!
Для резервного копирования и восстановления нескольких файлов данных можно использовать средства резервного копирования и
восстановления, встроенные в SharePoint Server 2010, однако если выполнить запись поверх данных в том же месте, эти средства не
позволят восстановить группу файлов данных в другом месте. Поэтому при использовании нескольких файлов данных для базы данных
контента настоятельно рекомендуется использовать средства резервного копирования и восстановления SQL Server. Дополнительные
сведения о резервном копировании и восстановлении SharePoint Server 2010 см. в статье Plan for backup and recovery (SharePoint
Server 2010).
Дополнительную информацию о создании файловых групп и управлении ими см. в статье, посвященной архитектуре файлов и
файловых групп (http://go.microsoft.com/fwlink/?linkid=117909&clcid=0x419).
Ограничение баз данных контента в размерах для лучшей управляемости
Размеры баз данных следует планировать таким образом, чтобы это способствовало улучшению управляемости, повышению
производительности и упрощению обновления рабочей среды.
Чтобы обеспечить надлежащую системную производительность, настоятельно рекомендуется установить для размера баз
данных контента ограничение в 200 ГБ.
Размер семейства сайтов (если оно не единственное в базе данных) не должен превышать 100 ГБ. Это ограничение позволит
использовать средства фрагментарного резервного копирования SharePoint Server 2010 для перемещения семейства сайтов в
случае необходимости в другую базу данных.
458
Важно!
Базы данных контента размером до 1 ТБ поддерживаются только для крупных репозиториев и архивов с одним сайтом, в которых данные
остаются достаточно статическими, например для систем управления справочными документами и сайтов центров записей. Большие базы
данных поддерживаются в таких сценариях потому, что их модели ввода-вывода и типичные форматы структур данных специально
рассчитаны на крупномасштабную среду и соответственно протестированы.
Если архитектура системы требует базы данных большего размера, чем предусмотрено рекомендуемым стандартом,
придерживайтесь следующих правил.
 Для баз данных, содержащих множество больших файлов, которые хранятся в виде больших двоичных объектов,
целесообразно использовать удаленное хранилище больших двоичных объектов (RBS). Такой выбор оптимален в
следующих ситуациях:
1. При использовании сайтов, содержащих большие файлы, к которым редко производится доступ, например в
репозиториях знаний.
2. При наличии терабайтов данных.
3. Для хранения файлов видео и мультимедиа.
Дополнительные сведения см. в статье Plan for remote BLOB storage (RBS) (SharePoint Server 2010).
 Следуйте практическим рекомендациям по просмотру данных в больших базах данных. Дополнительную информацию см. в
статье Управление мощностью SharePoint Server 2010: ограничения, связанные с программным обеспечением.
Дополнительные сведения о крупномасштабных репозиториях документов см. в документе «Оценка требований
производительности и емкости для крупномасштабных репозиториев документов», открываемом из статьи Результаты
тестирования производительности и емкости и рекомендации (SharePoint Server 2010).
Упреждающий контроль роста размеров файлов данных и журналов
Ростом размеров файлов данных и журналов рекомендуется управлять в упреждающем режиме с учетом следующих
рекомендаций:
 По мере возможности заранее увеличьте размеры всех файлов данных и журналов до предполагаемых окончательных
величин.
459


По соображениям безопасности рекомендуется включить автоматическое увеличение размеров файлов (авторасширение).
Не следует полагаться на параметры авторасширения, принимаемые по умолчанию. При настройке авторасширения
придерживайтесь следующих правил:

Если планируются базы данных контента с превышением рекомендуемого размера (200 ГБ), установите значение
авторасширения базы данных не в процентах, а в виде фиксированного числа мегабайтов. Это позволит сократить
частоту увеличения размера файла в SQL Server. Увеличение размера файла — блокирующая операция, в ходе которой
происходит заполнение нового пространства пустыми страницами.

Для базы данных хранилища свойств приложения-службы поиска установите значение параметра авторасширения
равным 10%.

Если расчетный размер базы данных контента в течение ближайшего года не должен превысить рекомендуемого
максимума в 200 ГБ, установите для базы данных максимальный размер, прогнозируемый на этот год (с 20-процентным
допуском), используя свойство ALTER DATABASE MAXSIZE. Регулярно пересматривайте это значение, следя за тем,
чтобы оно соответствовало прежним темпам роста.
Поддерживайте процент доступного пространства по всем дискам на уровне не ниже 25%, чтобы обеспечить возможность
роста размеров и работу в условиях пиковых нагрузок. Если возможность роста обеспечивается путем добавления дисков в
массив RAID или выделения дополнительного места в хранилище, внимательно следите за размерами дискового
пространства, чтобы не допустить нехватки места.
Проверка и мониторинг хранилища и производительности SQL
Server
Регулярное тестирование производительности системы и проверка решения резервного копирования имеют важное значение
для соблюдения соглашений об уровне обслуживания (SLA). В частности, тестирование подсистемы ввода-вывода компьютера,
на котором запущен SQL Server, поможет добиться удовлетворительной производительности всей системы.
Тестирование используемого решения резервного копирования даст гарантии того, что резервное копирование системы будет
выполнено за отведенное на техническое обслуживание время. Если при данном решении резервного копирования не удается
соблюдать требуемые SLA, рассмотрите возможность перехода на решение добавочного резервного копирования, такого как
System Center Data Protection Manager (DPM) 2010.
Крайне важно постоянно контролировать следующие ресурсы сервера SQL Server: ЦП, память, кэш и подсистему ввода-вывода.
Если какой-либо из этих компонентов демонстрирует признаки замедления или перегрузки, проанализируйте соответствующую
460
стратегию, опираясь на данные о текущей и прогнозируемой рабочей нагрузке. Дополнительную информацию см. в статье,
посвященной устранению проблем с производительностью SQL Server 2008 (Возможно, на английском языке)
(http://go.microsoft.com/fwlink/?linkid=168448&clcid=0x419) (Возможно, на английском языке).
В следующем разделе приводится перечень счетчиков производительности, которые рекомендуется использовать для
мониторинга производительности баз данных SQL Server, работающих в среде SharePoint Server 2010. Для каждого счетчика
указываются примерные значения, свидетельствующие об исправности.
Подробнее о мониторинге производительности и использовании счетчиков производительности см. в руководстве по
отслеживанию производительности (http://go.microsoft.com/fwlink/?linkid=189032&clcid=0x419).
Мониторинг счетчиков SQL Server
Для обеспечения исправности серверов необходимо следить за следующими счетчиками SQL Server.
 Общая статистика Этот объект содержит счетчики для мониторинга работы сервера в целом, например число текущих
подключений или число пользователей, в течение секунды подключающихся к компьютерам с запущенными экземплярами
SQL Server и отключающихся от них. Рекомендуется наблюдать за следующим счетчиком:


Базы данных Этот объект содержит счетчики для мониторинга операций массового копирования, пропускной способности
средства резервного копирования и восстановления, операций с журналами транзакций. Мониторинг транзакций и журналов
транзакций позволит определить, сколько пользовательских операций выполняется в базе данных и насколько заполнен
журнал транзакций. Объем пользовательских операций может влиять на производительность базы данных, размер журнала,
выполнение блокировки и репликации. Мониторинг операций с журналом на нижнем уровне, дающий оценки активности
пользователей и загруженности ресурсов, помогает выявлять узкие места в системе. Рекомендуется наблюдать за
следующим счетчиком:


Соединений пользователей Этот счетчик показывает число подключений пользователей на компьютере, на котором
запущен SQL Server. Если его значение окажется на 500% выше базового, это может привести к снижению
производительности.
Транзакций/с Этот счетчик показывает количество транзакций для данной базы данных или всего сервера,
выполняемых в секунду. Это значение сопоставляется с базовым, что позволяет устранять возникающие неполадки.
Блокировки Этот объект содержит информацию о блокировках SQL Server по отдельным типам ресурсов. Рекомендуется
наблюдать за следующими счетчиками:

Среднее время ожидания (мс) Этот счетчик показывает среднее время ожидания по всем запросам блокировки,
вызвавшим переход в состояние ожидания.
461




Время ожидания блокировки (мс) Этот счетчик показывает время ожидания для блокировок, установленных за
последнюю секунду.

Ожиданий блокировок/с Этот счетчик показывает число запросов блокировки в секунду, которые не были
удовлетворены немедленно и были вынуждены ждать освобождения ресурсов.

Количество взаимоблокировок/с Этот счетчик показывает число взаимоблокировок, происходящих в секунду на
компьютере, на котором запущен SQL Server. Его значение не должно превышать 0.
Кратковременные блокировки Этот объект содержит счетчики для мониторинга внутренних блокировок ресурсов SQL
Server, называемых кратковременными блокировками. Мониторинг таких блокировок, дающий оценки активности
пользователей и загруженности ресурсов, помогает выявлять узкие места в системе. Рекомендуется наблюдать за
следующими счетчиками:

Среднее время ожидания кратковременной блокировки (мс) Этот счетчик показывает среднее время ожидания
блокировки для запросов кратковременных блокировок, которым пришлось ожидать обработки.

Ожиданий кратковременных блокировок/с Этот счетчик показывает число запросов кратковременных блокировок,
которые не удалось удовлетворить немедленно.
Статистика SQL Этот объект содержит счетчики для слежения за компиляцией и типом запросов, направляемых в
экземпляр SQL Server. Мониторинг числа компиляций и повторных компиляций, а также число пакетов, полученных
экземпляром SQL Server, позволяет судить о том, как быстро в SQL Server обрабатываются запросы пользователей и
насколько эффективно работает оптимизатор запросов. Рекомендуется наблюдать за следующими счетчиками:

Компиляций SQL/с Этот счетчик показывает, сколько раз в секунду вводится путь к компилируемому коду.

Повторных компиляций SQL/сек Этот счетчик показывает число повторных компиляций инструкции в секунду.
Диспетчер буферов Этот объект содержит счетчики, позволяющие контролировать, как в SQL Server используется память
для хранения страниц данных, внутренних структур данных и кэша процедур, и как работает физическая подсистема вводавывода при чтении и записи страниц базы данных SQL Server. Рекомендуется наблюдать за следующим счетчиком:

Коэффициент попадания в буферный кэш

Этот счетчик показывает, сколько страниц (в процентах от общего числа) было найдено в буферном кэше, что позволило
не считывать их с диска. Его значение равняется отношению общего числа успешных обращений в кэш к общему числу
операций поиска в кэше для последних нескольких тысяч попыток доступа к страницам. Поскольку чтение из кэша
гораздо выгоднее чтения с диска в терминах потребляемых ресурсов, следует стремиться, чтобы это отношение было
462
максимально высоким. В общем случае коэффициент успешных обращений в буферный кэш можно повысить путем
увеличения объема памяти, доступной для SQL Server.

Кэш планов Этот объект содержит счетчики, позволяющие следить за тем, как в SQL Server используется память для
хранения таких объектов, как хранимые процедуры, специальные и подготовленные инструкции Transact-SQL и триггеры.
Рекомендуется наблюдать за следующим счетчиком:

Коэффициент попадания в кэш

Этот счетчик показывает отношение числа успешных обращений в кэш к числу операций поиска для планов.
Мониторинг счетчиков физических серверов
Для обеспечения исправности компьютеров, на которых запущен SQL Server, необходимо следить за следующими счетчиками.
 Процессор: % загруженности процессора: _Total Этот счетчик показывает, какой процент времени процессор выполняет
процессы приложений или операционной системы, отличные от Idle. На компьютере, на котором запущен SQL Server, это
значение должно оставаться в диапазоне от 50% до 75%. В случае постоянной перегрузки необходимо выяснить, вызвано ли
это каким-либо аномальным процессом, или же серверу требуются дополнительные ЦП.

Система: длина очереди процессора Этот счетчик показывает число потоков в очереди процессора. Необходимо следить
за тем, чтобы оно не более чем вдвое превышало число ЦП.

Память: доступно МБ Этот счетчик показывает размер физической памяти в мегабайтах, доступной для процессов,
выполняемых на компьютере. Необходимо следить за тем, чтобы он составлял не менее 20% от общего объема доступной
физической оперативной памяти.

Память: обмен страниц/сек Этот счетчик показывает скорость считывания страниц с диска или записи на диск в случае
страничных прерываний. Необходимо следить, чтобы значение счетчика не превышало 100.
Дополнительную информацию и описание методов устранения неполадок памяти см. в статье, посвященной мониторингу
использования памяти в SQL Server 2005 (http://go.microsoft.com/fwlink/?linkid=105585&clcid=0x419).
Мониторинг счетчиков дисков
Для обеспечения исправности дисков следите за нижеперечисленными счетчиками. Следует иметь в виду, что здесь указаны
значения, представляющие результаты измерений за некоторый период времени, а не результаты единичных измерений и не
пиковые показатели.
 Физический диск: % активности диска: диск данных Этот счетчик показывает, какую часть истекшего времени
выбранный диск обслуживал запросы на чтение и запись; это основной индикатор занятости диска. Если значение счетчика
Физический диск: % активности диска слишком высоко (более 90%), проверьте счетчик Физический диск: текущая длина
463
очереди диска, чтобы узнать, сколько системных запросов ожидает доступа к диску. Число ожидающих запросов вводавывода должно не более чем в 1,5–2 раза превышать число шпинделей физического диска.

Логический диск: обращений к диску/сек Этот счетчик показывает скорость выполнения операций чтения и записи на
диске. Используйте его для мониторинга тенденций роста размеров данных и составления соответствующих прогнозов.

Логический диск: скорость чтения с диска (байт/сек) и Логический диск: скорость записи на диск (байт/сек) Эти
счетчики показывают скорость передачи данных с диска или на диск в ходе операций чтения или записи.

Логический диск: средний размер одного чтения с диска (байт) Этот счетчик показывает среднее число байтов,
передаваемых с диска в ходе операций чтения. Это значение может характеризовать задержку доступа к диску: большие
объемы считывания могут слегка увеличивать задержку.

Логический диск: средний размер одной записи на диск (байт) Этот счетчик показывает среднее число байтов,
передаваемых на диск в ходе операций записи. Это значение может характеризовать задержку доступа к диску: большие
объемы записи могут слегка увеличивать задержку.

Логический диск: текущая длина очереди диска Этот счетчик показывает число невыполненных запросов доступа к диску
на момент сбора данных о производительности. Чем меньше значение этого счетчика, тем лучше. Значение, большее 2 для
одного диска, может указывать на узкое место в системе и требует тщательного исследования. Таким образом, значение, не
превышающее 8, считается приемлемым для логического устройства (LUN), состоящего из 4 дисков. Узкие места могут
приводить к скоплению невыполненных запросов, затрагивая не только текущий сервер, с которого производятся обращения
к диску, но и увеличивая время ожидания для пользователей. Возможными путями решения этой проблемы являются
добавление дисков в массив RAID, замена имеющихся дисков более быстродействующими или перемещение части данных
на другие диски.

Логический диск: средняя длина очереди диска Этот счетчик показывает среднее число запросов на чтение и запись,
помещенных в очередь к выбранному диску за определенный интервал времени. Число ожидающих запросов чтения и
записи не должно превышать 2 на один шпиндель, но измерение этого показателя затрудняют виртуализация дискового
пространства и различия в уровнях RAID между конфигурациями. Внимания заслуживает превышение средней длины
очереди диска в сочетании с превышением средней задержки доступа к диску. Такая комбинация может указывать на
перегрузку кэша массива хранилищ или на снижение производительности вследствие совместного использования диска
несколькими приложениями.

Логический диск: среднее время чтения с диска (сек.) и Логический диск: среднее время записи на диск (сек.) Эти
счетчики показывают среднее время выполнения операции чтения с диска или записи на диск (в секундах). Необходимо
следить, чтобы эти значения не превышали 85% от уровня пропускной способности диска, иначе время доступа к диску
464
станет расти экспоненциально. Пропускную способность используемого оборудования можно узнать из документации
производителя или определить с помощью программы эталонного тестирования дисковой подсистемы SQLIO.
Дополнительную информацию см. в статье, посвященной средству эталонного тестирования дисковой подсистемы SQLIO
(Возможно, на английском языке) (http://go.microsoft.com/fwlink/?linkid=105586&clcid=0x419) (Возможно, на английском языке).

Логический диск: среднее время чтения с диска (сек.) Этот счетчик показывает среднее время выполнения операции
чтения с диска (в секундах). В правильно настроенных системах оптимальными являются значения от 1 до 5 мс для
журналов (идеальный вариант — 1 мс для массива с кэшем) и от 4 до 20 мс для данных (желательно менее 10 мс). В
периоды пиковой нагрузки возможны более высокие задержки, но если они случаются регулярно, необходимо выяснить
причины проблемы.

Логический диск: среднее время записи на диск (сек.) Этот счетчик показывает среднее время выполнения операции
записи на диск (в секундах). В правильно настроенных системах оптимальными являются значения от 1 до 5 мс для
журналов (идеальный вариант — 1 мс для массива с кэшем) и от 4 до 20 мс для данных (желательно менее 10 мс). В
периоды пиковой нагрузки возможны более высокие задержки, но если они случаются регулярно, необходимо выяснить
причины проблемы.
При использовании конфигураций RAID со счетчиками Среднее время чтения с диска (сек) и Среднее время записи
на диск (сек.) скорость ввода-вывода для диска рассчитывается по следующим формулам.
Уровень RAID
Формула
RAID 0
Число операций ввода-вывода на диске = (число операций чтения +
число операций записи) / число дисков
RAID 1
Число операций ввода-вывода на диске = [число операций чтения +
(2 × число операций записи)] / 2
RAID 5
Число операций ввода-вывода на диске = [число операций чтения +
(4 * число операций записи)] / число дисков
RAID 10
Число операций ввода-вывода на диске = [число операций чтения +
(2 * число операций записи)] / число дисков
465
Например, предположим, что в системе RAID 1 с двумя физическими дисками счетчики имеют следующие значения:
Счетчик
Значение
Среднее время чтения с диска (сек)
80
Логический диск: среднее время записи на диск (сек)
70
Средняя длина очереди диска
5
Число операций ввода-вывода для диска вычисляется следующим образом: (80 + (2 × 70))/2 = 110
Длина очереди диска равняется: 5/2 = 2,5
Эти цифры указывают на потенциально узкое место в подсистеме ввода-вывода.
Другие средства мониторинга
Отслеживать задержки доступа к дискам и анализировать тенденции в изменении характеристик можно также в динамическом
административном представлении sys.dm_io_virtual_file_stats в SQL Server 2008. Дополнительную информацию см. в статье,
посвященной sys.dm_io_virtual_file_stats (Transact-SQL) (http://go.microsoft.com/fwlink/?linkid=105587&clcid=0x419).
466