Оценка мощности и производительности управления веб-контентом (SharePoint Server 2013)
ОБЛАСТЬ ПРИМЕНЕНИЯ:
2013 
2016 2019 Subscription Edition SharePoint в Microsoft 365
Предприятия часто используют SharePoint Server 2013 для публикации контента, к которому обращаются пользователи на сайте в Интернете или авторизованные пользователи на сайте интрасети. Эта статья содержит данные о производительности и емкости, которые могут помочь вам в планировании числа и типа компьютеров, необходимых для публикации контента и управления веб-контентом в SharePoint Server 2013.
Публикация SharePoint включает различные типы сайтов публикации и связанные с ними методы, доступные для каждого сайта. Функции публикации SharePoint Server 2013 предназначены для создания фирменных сайтов Интернета, интрасети и экстрасети. Дополнительные сведения о публикации SharePoint Server 2013 см. в статье Обзор публикации в Интернете, интрасети и на сайтах экстрасети в SharePoint Server.
Введение
В этой статье рассматриваются следующие сценарии.
Сайт присутствия в Интернете
Содержит сведения для клиентов, партнеров, инвесторов и потенциальных сотрудников. Сайты этого типа позволяют анонимным пользователям в Интернете находить сведения о корпорации. Как правило, такие сайты содержат фирменную символику, а компания управляет контентом.
Деловой сайт в Интернете
Используется для рекламирования продуктов и услуг, предлагаемых компанией. Кроме того, такие сайты могут содержать каталог продуктов, предлагаемых компанией.
Сайт интрасети
Компания публикует этот сайт внутри организации. Эти сайты обмениваются информацией для пользователей, прошедших проверку подлинности, и компаний либо жестко управляют сайтом, чтобы ограничить доступ, либо открыты для всех пользователей jnternal.
Сайт экстрасети
Предоставление доступа к специальному контенту удаленным сотрудникам, партнерам и клиентам. Такие сайты могут предоставлять доступ к базам знаний, использующим контент, помеченный метаданными для разделения статей по категориям. Пользователи могут искать и просматривать определенные сведения, например статьи об устранении неполадок и поддержке.
Публикация в нескольких семействах веб-сайтов и веб-часть поиска контента позволяют повторно использовать содержимое в разных семействах веб-сайтов в этих сценариях. Эти функции и функции влияют на планирование емкости. Дополнительные сведения см. в статье Общие сведения о публикации между сайтами в SharePoint Server.
Примечание.
В этой статье публикацию на нескольких сайтах в семействах веб-сайтов мы будем называть публикацией на нескольких сайтах.
Управляемая навигация в SharePoint Server 2013 обеспечивает навигацию на основе таксономии для сайта публикации. Подробнее см. в статье Overview of managed navigation in SharePoint Server.
Данные о емкости и производительности, представленные в этой статье, разделены на две части. Первая из них относится к новому способу публикации на нескольких сайтах и управляемой навигации. Во второй части используется модель с присутствием автора.
Примечание.
Сценарии, описанные в этой статье, можно реализовать как с помощью публикации на нескольких сайтах, так и с помощью сайтов с присутствием автора. Функции публикации на нескольких сайтах и управляемой навигации не зависят друг от друга, и их можно использовать по отдельности.
В моделях, описанных в этой статье, используются два ключевых показателя.
Пропускная способность
Количество просмотров страниц в секунду, которые способен обрабатывать сайт.
Время отклика сервера
Время, необходимое серверу для обработки запроса и влияющее на скорость открытия страницы. Значения времени отклика сервера представлены в этом документе в 95-х и 50-х процентилях. Это значит, что 95 и 50 процентов запросов, соответственно, обрабатываются быстрее, чем указанное значение. Эти значения вычисляются с помощью параметра "Продолжительность", записанного в базе данных использования SharePoint для данного запроса.
Актуальность контента
Время, необходимое для того, чтобы обновленный элемент появился в результатах поиска, полезно учитывать при работе с публикацией на нескольких сайтах.
В приведенных в этой статье сценариях используются следующие два состояния.
Зеленая зона
Сервер используется менее, чем на 60 процентов. К такому состоянию следует стремиться в течение большей части работы сервера.
Красная зона
Ресурсы серверов используются практически полностью. Это состояние указывает на повышенную загрузку сайта SharePoint. В красной зоне время отклика сервера начинает повышаться по мере того, как сервер пытается обрабатывать входящие запросы.
Необходимая информация
Перед прочтением этой статьи убедитесь, что вы знакомы с ключевыми понятиями об управлении емкостью в SharePoint Server 2013. Перечисленные ниже статьи помогут вам изучить рекомендуемый подход к управлению емкостью и предоставят контекст для эффективного использования сведений из этой статьи.
Обратите внимание, что в данной статье не используются некоторые новые функции, связанные со сценариями публикации, в том числе каналы устройств, оптимизация SEO, шаблоны отображения и правила запросов. Кроме того, в этой статье отсутствует подробное описание функций и настройки сайта публикации на нескольких сайтах. Дополнительные сведения см. Дополнительные сведения см . в разделах Планирование публикации на нескольких сайтах в SharePoint Server и Настройка решений для управления веб-содержимым в SharePoint Server.
Дополнительные сведения о емкости и производительности, которые помогут понять данные в этой статье, см. в статье Планирование производительности в SharePoint Server 2013.
Публикация на нескольких сайтах с помощью управляемой навигации
В этом разделе представлены тестовые данные для двух сценариев: публикации на нескольких сайтах с анонимными пользователями и публикации с присутствием автора.
Публикация на нескольких сайтах с анонимными пользователями
Результаты тестов в этом разделе основаны на обычной модели публикации на нескольких сайтах для обучения планированию емкости. Используйте это руководство при планировании развертывания SharePoint для доступа анонимных пользователей к веб-сайту, изменяя характеристики развертывания соответствующим образом.
Тестовый случай в наших тестах использует функцию публикации между сайтами. Этот сценарий предоставляет содержимое в нескольких семействах веб-сайтов, которые помечаются как каталоги, а затем обходятся приложением службы поиска SharePoint. Веб-части, использующие технологию поиска, например веб-часть поиска контента и веб-часть Catalog-Item повторного использования, отображают содержимое на страницах другого сайта. Дополнительные сведения см. в статье Общие сведения о публикации между сайтами в SharePoint Server.
Модель сайта, созданная для испытания публикации на нескольких сайтах, имеет следующие характеристики.
Веб-сайт публикации, содержащий около 5 миллионов страниц с элементами.
Эти элементы связаны примерно с 1000 категорий.
Контент расположен в одном или нескольких каталогах в других семействах веб-сайтов.
На веб-сайте используется управляемая навигация по категориям, с которыми связаны элементы.
В базовой топологии развертывания, описанной далее в этом списке, веб-сайт в среднем обрабатывает до 80 просмотров страниц в секунду. В пиковые периоды выполняется до 100 просмотров страниц в секунду. Чтобы увеличить пропускную способность, добавьте в топологию компьютеры. Чтобы снизить пропускную способность, удалите компьютеры из топологии.
Программа-обходчик службы поиска выполняет обход с минутным интервалом, обновляя каталог пять раз в секунду.
Веб-сайт содержит следующие структуры страниц и трафика.
Главная страница, которая содержит три веб-части поиска контента и веб-часть панели уточнения результатов поиска (она получает 15 процентов трафика).
Страницы категорий, содержащие три веб-части поиска контента, одну веб-часть панели уточнения таксономии и одну веб-часть панели уточнения, которые получают 45 процентов трафика.
Страницы элементов каталога, содержащие веб-часть повторного использования элементов каталога и две веб-части поиска контента, которые получают 40 процентов трафика.
Все веб-части поиска контента и повторного использования элементов каталога выполняют синхронные запросы.
Страницы элементов каталога не используют кэш результатов анонимного поиска, поскольку они получают небольшое количество трафика.
В ферме включен кэш больших двоичных объектов (BLOB) для компьютеров, выполняющих роль интерфейсных веб-серверов.
На следующем рисунке показана топология серверов для проверки этого сценария.
Рисунок 1. Топология серверов тестовой лаборатории
один компьютер, на котором размещается SQL Server со всеми базами данных, которые использует SharePoint;
один компьютер, на котором размещаются приложения службы SharePoint, служба распределенного кэша, служба обработки аналитики поиска и роли администрирования поиска;
один компьютер, на котором размещается программа-обходчик службы поиска и роли обработки контента;
три компьютера, на которых размещаются узлы поискового индекса с обработкой запросов и которые выступают в роли интерфейсных веб-серверов.
Примечание.
Компьютеры в этом тесте являются физическими компьютерами под управлением Windows Server 2008 R2. Рекомендации по использованию виртуальных машин и Windows Server 2012 см. в статье Планирование емкости поиска и планирование емкости для SharePoint Server 2013.
Важно!
Конфигурация топологии нашей тестовой лаборатории оптимизирована для сценариев публикации, основанных на поиске. Эта конфигурация отличается от типов развертываний SharePoint, предназначенных для совместной работы. Например, в нашей конфигурации интерфейсные веб-серверы используются в качестве серверов поискового индекса для достижения максимальной производительности. > В нашей топологии лаборатории тестирования мы узнали, что компьютер, на котором размещен сервер приложений, был недостаточно загружен. Поэтому мы поместили службу распределенного кэша на этот сервер приложений, а не на отдельный сервер. В своей среде вы можете разместить службу распределенного кэша на отдельном сервере. Для достижения максимальной производительности не рекомендуется размещать службу распределенного кэша на интерфейсном веб-сервере, выполняющем роль сервера поискового индекса.
Отчеты тестовой лаборатории
Мы использовали топологию на рис. 1 для лаборатории тестирования с физическими компьютерами и нагрузочного теста Visual Studio Team System (VSTS). Дополнительные сведения см. в разделе Visual Studio Team System. Технические спецификации тестовых компьютеров приведены в следующих таблицах.
Примечание.
Мы не использовали кэширование браузера и зависимые запросы, например изображения и файлы JavaScript, в тестах службы VSTS. Количество зависимых запросов во многом зависит от настроек сайта публикации. > На страницах, которые мы использовали в тестах, было выполнено почти 50 страниц времени загрузки 1 (PLT1) запросов (пустой кэш браузера) и около 3 запросов для типов запросов PLT2 (последующие запросы с результатами из кэша браузера). Как правило, кэш BLOB-объектов SharePoint обслуживает запросы для этих элементов и практически не влияет на показатели производительности.
| Серверные компоненты | Серверы SharePoint Server |
|---|---|
| Процессоры | Процессоры Intel Xeon с частотой 2,27 ГГц (2 процессора, 8 ядер всего, всего 16 потоков) |
| ОЗУ | 24 ГБ |
| Операционная система | Windows Server 2008 R2 Enterprise с пакетом обновления 1 (64-разрядная версия) |
| Размер диска для SharePoint | 200 ГБ на внутреннем диске |
| Объем индекса поиска | 78 ГБ на внешнем дисковом массиве (2 диска Dell PERC H700 SCSI) |
| Количество сетевых адаптеров | 2 |
| Скорость сетевого адаптера | 1 гигабит |
| Проверка подлинности | Нет — анонимный |
| Версия программного обеспечения | SharePoint Server 2013 |
| Серверные компоненты | Серверы баз данных |
|---|---|
| Процессоры | Процессоры Intel Xeon L5520 с частотой 2,27 ГГц (2 процессора, 8 ядер всего, всего 16 потоков) |
| ОЗУ | 24 ГБ |
| Операционная система | Windows Server 2008 R2 Enterprise с пакетом обновления 1 (64-разрядная версия) |
| Дисковый массив | 2 диска Dell H700 SCSI |
| Количество сетевых адаптеров | 2 |
| Скорость сетевого адаптера | 1 гигабит |
| Проверка подлинности | NTLM |
| Версия программного обеспечения | Microsoft SQL Server 2008 R2 с пакетом обновления 1 (SP1) |
После 10 минут работы были получены следующие результаты.
| Тестовые функции | Зеленая зона | Красная зона |
|---|---|---|
| Количество пользователей системы VSTS (симуляция одновременного использования): | 60 | 100 |
| Время отклика сервера 50-й процентиль*: | 219 мс | 302 мс |
| Время отклика сервера 95-й процентиль*: | 412 мс | 635 мс |
| Количество просмотров страниц в секунду | 78 | 98 |
В этом сценарии публикации на нескольких сайтах отображается контент поискового индекса. Может быть интересно изучить количество запросов, обслуживаемых серверами поиска, и количество запросов, обслуживаемых кэшем результатов анонимного поиска. В этой модели кэш результатов анонимного поиска обслуживает около 60 процентов запросов. Кэш результатов анонимного поиска рассматривается далее в этой статье.
| Тестовые функции | Зеленая зона | Красная зона |
|---|---|---|
| Всего запросов в секунду | 235 | 294 |
| Запросы, обслуживаемые кэшем результатов анонимного поиска | 145 | 182 |
| Запросы обслуживаемые службой поиска | 90 | 112 |
Ниже представлены средние показатели загрузки ЦП и максимального использования памяти для этих компьютеров в ходе тестов.
| Тестовые функции | Зеленая зона | Красная зона |
|---|---|---|
| Средняя загрузка ЦП (узлы поискового индекса на интерфейсный веб-сервер) | 59 % | 80 % |
| Средняя загрузка ЦП (сервер приложений с распределенным кэшем) | 8 % | 9 % |
| Средняя загрузка ЦП (узлы CPC службы поиска) | 5 % | 5 % |
| Средняя загрузка ЦП (SQL Server) | Не измерялась | Не измерялась |
| Максимальное использование памяти (узлы поискового индекса на интерфейсный веб-сервер) | 7,5 ГБ | 7,5 ГБ |
| Максимальное использование памяти (сервер приложений с распределенным кэшем) | 10,1 ГБ | 10 ГБ |
| Максимальное использование памяти (узлы CPC службы поиска) | 6,5 ГБ | 6,5 ГБ |
Обратите внимание, что объем используемой памяти может несколько отличаться, поскольку в ходе обычной работы выполняются различные задания таймера. Мы обнаружили, что узлы сервера индекса и интерфейсного веб-сервера использовали до 12 ГБ памяти после двухнедельного тестового запуска с постоянной нагрузкой.
Как веб-части поиска отображают контент на сайтах публикации на нескольких сайтах
Если страница публикации содержит веб-часть поиска, например веб-часть поиска контента, браузер начинает обрабатывать страницу до того, как будет завершен поисковый запрос. Это снижает распознаваемое время ожидания страницы. По завершении поискового запроса все его результаты отправляются в браузер, и подключение к браузеру закрывается. Пользователям может показаться, что результаты поиска загружаются асинхронно. Тем не менее, запросы с сервера отправляются, пока запрашивается страница.
Обратите внимание, что веб-часть поиска контента может работать в отдельном асинхронном режиме, в котором запросы отправляются из браузера после загрузки страницы.
Влияние изменений нагрузки на сайт публикации на нескольких сайтах
Мы изменяли количество пользователей VSTS (аналогично количеству одновременных пользователей, обращающихся к сайту), которые использовались в нагрузочном тесте. На следующей диаграмме показано, что время отклика сервера увеличивается по мере увеличения нагрузки, а количество обслуживаемых страниц в секунду увеличивается. Мы рекомендуем, чтобы время отклика сервера было не более 750 мс, чтобы пользователи смогли быстро реагировать на развертывание SharePoint.
Рисунок 2. Диаграмма пропускной способности и времени отклика сервера при разных нагрузках
Масштабирование сайта публикации на нескольких сайтах
Если ожидается, что развертывание SharePoint будет получать больше или меньше трафика, чем в базовом случае, описанном ранее, вы можете изменить количество компьютеров фермы, выполняющих роли серверов индекса и интерфейсных веб-серверов, в соответствии с количеством трафика. На следующем рисунке показаны результаты масштабирования сайта публикации на нескольких сайтах с различными уровнями нагрузки и количеством компьютеров, используемых в качестве интерфейсных веб-серверов с узлами индекса, начиная с одного компьютера в роли интерфейсного веб-сервера с узлами индекса и заканчивая шестью компьютерами.
Рисунок 3. Масштабирование развертывания
В каждой из этих конфигураций мы изменяли нагрузку так, чтобы время отклика сервера практически не отличалось от базового случая из предыдущего раздела.
Обратите внимание, что по мере увеличения числа компьютеров сложность топологии начинает обгонять преимущества. Каждый дополнительный компьютер имеет меньшую пропускную способность по сравнению с компьютерами, которые уже находятся в среде. Эти числа предоставляются для отображения шаблона горизонтального масштабирования. Фактическая производительность будет меняться в зависимости от того, как создается развертывание SharePoint.
Руководство по планированию сайта
В большинстве тестов производительности мы использовали развертывание, описанное в предыдущих разделах. Рекомендации из следующего списка помогут вам принять правильные решения по планированию емкости, если ваши развертывания отличаются от используемых в тестовой лаборатории.
Как правило, чем больше элементов в поисковом индексе, тем выше задержка. Каждый раздел индекса может содержать до 10 миллионов отображаемых элементов. Обычные веб-сайты редко содержат более 10 миллионов элементов, поэтому им необходим только один раздел, как в описанной ранее топологии. Вы можете использовать несколько разделов индекса, чтобы хранить более 10 миллионов элементов или уменьшить размеры разделов, повысив скорость их работы. Если вы планируете использовать несколько разделов индекса, см. Если вы планируете использовать несколько секций индекса, см. раздел Масштабирование поиска интернет-сайтов в SharePoint Server , чтобы правильно определить топологию поиска.
Каждый элемент управления или веб-часть, добавленные на страницу (или макет страницы), увеличивают время отклика страницы.
Не используйте на одной странице более пяти синхронных веб-частей поиска контента или повторного использования элементов каталога. Обрабатывая запрос страницы, SharePoint Server 2013 выполняет до пяти параллельных запросов и возвращает результаты. Если страница получает более пяти запросов, SharePoint Server 2013 сначала выполняет первые пять из них, а затем следующий набор из пяти запросов. Если на странице необходимо использовать более пяти веб-частей поиска контента или повторного использования элементов каталога, вы можете запустить дополнительные веб-части поиска контента в асинхронном режиме или использовать правила запросов и блоки результатов.
Веб-части поиска контента и повторного использования элементов каталога могут работать в асинхронном режиме. Запрос, связанный с веб-частью, выполняется после того как браузер загрузит страницу. С помощью этого режима можно замедлять запросы так, чтобы остальное содержимое страницы отображалось быстрее. В других случаях рекомендуется использовать синхронные запросы для максимального снижения времени загрузки страницы.
Веб-часть панели уточнения, которая содержит много уточнений, увеличивает время обработки запроса. Вы можете изменить количество уточнений для управляемого свойства. Дополнительные сведения см. в статье Настройка уточнений и фасетной навигации в SharePoint Server.
Если вы используете веб-часть области уточнения таксономии и сложную иерархию узлов навигации, время обработки запросов увеличится. Не рекомендуется использовать веб-часть области уточнения таксономии на страницах, содержащих более 200 узлов навигации. Это может замедлить отклик сервера и снизить пропускную способность.
Чтобы создать развертывание SharePoint с высокой доступностью, необходимо добавить следующие компоненты.
Дополнительный компьютер, на котором выполняются приложения-службы с ролями распределенного кэша на случай, если имеющийся компьютер недоступен.
Дополнительные компьютеры, поддерживающие нагрузку, если один или несколько компьютеров с интерфейсными веб-серверами и узлами индекса недоступны.
Дополнительный компьютер с ролями CPC, обеспечивающий обновление сайта, если компьютер с ролью CPC недоступен.
Топология SQL Server, которая продолжает обслуживать запросы баз данных, если серверы баз данных недоступны.
Скорость обхода службы поиска и актуальность контента
В ходе испытаний мы также провели тесты обновления публикуемого контента каталога. Затем мы рассмотрели время, необходимое для того, чтобы обновленный элемент появился на сайте публикации. В своих экспериментах мы выполняли пять обновлений каталога в секунду и установили интервал в одну минуту для непрерывного обхода контента. Мы заметили, что в среднем для появления изменений на сайте публикации требовалось около двух минут. Минимальное время составляло чуть менее минуты, а максимальное три минуты. Мы не заметили значительного изменения этих показателей при увеличении количества компьютеров с ролью CPC.
Тем не менее, в случае полного обхода каталога при повышении числа компьютеров с ролью CPC увеличилось количество элементов, обрабатываемых за секунду. На приведенном ниже графике показано отношение количества элементов, обрабатываемых за секунду, и числа компьютеров с ролью CPC в ферме. Обратите внимание, что эти тестовые данные были получены из развертывания SharePoint, которое отличается от используемого в базовом испытании. Полученные результаты применимы к развертываниям SharePoint, поскольку при добавлении узлов CPC повышается время полного обхода контента.
Рисунок 4. Влияние компьютеров для обработки контента (CPC) на полный обход контента
Таким образом, если вам нужно ускорить полный обход своих каталогов, вы можете повысить число компьютеров, использующих роль CPC, в своем развертывании.
Нагрузка на приложение-службу управляемых метаданных
Наше испытание показало, что сценарии публикации, в которых используется управляемая навигация, не требует значительного количества памяти и мощности процессора для приложения-службы управляемых метаданных. В развертывании, подобном описанному выше, приложение-службы управляемых метаданных можно запускать на компьютере, выполняющем другие приложения-службы SharePoint. Компонент управляемых метаданных устанавливает одно подключение к приложению-службе после первого запроса к сайту. Последующие запросы используют значения из кэша интерфейсных веб-серверов. Таким образом, нагрузка на приложение-службу управляемых метаданных отсутствует, пока интерфейсные веб-серверы обрабатывают запросы.
Кэш результатов анонимного поиска
Кэш результатов анонимного поиска хранит результаты запроса, уточняющие данные для запроса и дополнительные таблицы результатов, возвращаемые службой распределенного кэша SharePoint. Каждая запись кэша зависит от параметров запроса, таких как порядок сортировки результатов, запрошенные уточнения и правила динамического изменения порядка. Кэш влияет на все запросы, обрабатываемые веб-приложением, включая запросы из веб-частей поиска и запросы клиентов CSOM. Дополнительные сведения см. в разделах Обзор архитектуры поиска в SharePoint Server и Масштабирование поиска интернет-сайтов в SharePoint Server.
Из соображений безопасности этот кэш не используется для запросов, проходящих проверку подлинности.
Для достижения наилучших результатов рекомендуется, чтобы служба распределенного кэша выполнялась только на компьютере, на котором работают приложения-службы SharePoint. Службу распределенного кэша не следует запускать на компьютерах с ролями интерфейсных веб-серверов.
По умолчанию кэш результатов анонимного поиска обновляется каждые 15 минут. Вы можете использовать Microsoft PowerShell для настройки длительности кэша в веб-приложении, в котором настроен кэш:
$webapp.Properties["SearchResultsCacheTTL"] = <number of seconds to keep in cache>
$webapp.Update()
Чтобы повысить актуальность результатов поиска, нужно уменьшить это значение. Обратите внимание, что при этом будет увеличено число запросов, которые потребуется обрабатывать службе поиска.
Рекомендуется всегда использовать кэш на страницах публикации, которые получают интенсивный трафик. Примерами таких типов страниц являются домашняя страница сайта и страницы категорий, использующие веб-части поиска. Не рекомендуется кэширование страниц элементов каталога. Поскольку доступ к отдельной странице элемента каталога будет осуществляться гораздо реже, чем к домашней странице, и хранить элемент в кэше может быть не стоит.
Когда мы отключили кэш результатов анонимного поиска в тестовой среде с таким же шаблоном нагрузки, время отклика сервера значительно повысилось, а пропускная способность в просмотрах страниц за секунду снизилась. На следующем графике показано это отношение.
Рисунок 5. Влияние кэша результатов анонимного поиска
По умолчанию веб-части поиска контента используют кэш результатов анонимного поиска. Веб-части повторного использования элементов каталога, применяемые на страницах элементов каталога, не используют его в связи с разреженными шаблонами доступа к таким страницам.
Чтобы настроить поведение кэширования для отдельной веб-части для использования (или не использования) кэша результатов анонимного поиска, задайте значение вложенного свойства TryCache в DataProviderJSON свойстве веб-части. Если задано значение "true", запрос будет использовать кэш. Если же задано значение "false", запрос не будет использовать кэш для анонимного поиска.
Влияние кэша вывода
Кэширование выходных данных — эффективный способ снижения нагрузки на SharePoint Server 2013 в сценариях публикации. Дополнительные сведения о работе кэша вывода в этой статье см. в разделе Кэширование выходных данных и профили кэша.
Кэширование вывода в развертывании SharePoint может снизить нагрузку на базы данных контента SharePoint и приложение службы поиска. Далее представлено несколько примеров.
Определенные страницы получают большое количество трафика.
Базы данных контента SharePoint получают большое количество трафика.
Компьютеры, которые обслуживают запросы поиска, работают с высокой загрузкой процессора.
Мы рекомендуем использовать кэширование вывода для самых популярных страниц вашего сайта, например главной страницы или страниц категорий высокого уровня, а также некоторых страниц элементов с большим количеством входящего трафика.
Важно!
В SharePoint Server 2013 существует известная проблема: страницы со включенным кэшированием выводимых данных содержат веб-часть "Поиск контента". Чтобы избежать этой проблемы в своем развертывании, установите обновление для SharePoint Server 2013 за 12 марта 2013 г.
На приведенном ниже графике показаны некоторые результаты из нашей тестовой среды, где кэширование вывода используется на главной странице и страницах категорий, которые получают 60 процентов трафика сайта.
Рисунок 6. Влияние кэширования вывода на главную страницу и страницы категорий
Примечание.
Веб-части поиска контента могут работать в асинхронном режиме. Кэширование вывода не распространяется на нагрузку из асинхронных веб-частей поиска контента.
Обработка аналитики использования
Чтобы иметь готовые сведения об аналитике использования, SharePoint Server 2013 обрабатывает сведения, которые содержатся в базе данных об использовании. В нашей топологии обработка аналитики выполняется на узле, содержащем узел Администратор поиска, службу распределенного кэша и другие приложения-службы. Дополнительные сведения см. в статье Обзор обработки аналитики в SharePoint Server.
Мы измерили время обработки аналитики с помощью сайта публикации на нескольких сайтах, использованного в предыдущих испытаниях. Мы измерили время, необходимое SharePoint Server 2013 для обработки большого количества событий щелчков на страницах сайта. Хотя эти результаты были получены на сайте публикации на нескольких сайтах, они также применимы к сайтам, использующим метод публикации с присутствием автора.
Для испытаний обработки аналитики использования мы вызывали следующие события каждый день недели.
27,5 миллиона событий щелчков между 3 миллионами элементов списков и 400 000 пользователей.
Использовалось распределение Ципфа, чтобы некоторые элементы и пользователи могли вызывать больше событий, чем другие.
Всего вызывалось по 7,5 миллионов событий в день, симулирующих различные шаблоны трафика от различных пользователей сайта.
Мы провели анализ семь раз, чтобы симулировать трафик за одну неделю. Задание аналитики использования запускалось каждый день для данных, собранных за шесть дней. Затем мы измерили время, потраченное на данные седьмого дня. Данные за седьмой день обрабатываются дольше всего, так как выполняется обработка элементов за всю неделю и обновление графика отношения. Время работы и использование диска за 8-й день будут подобны аналогичным показателям за 1-й день.
Обработка аналитики практически не влияла на производительность компьютера, на котором она выполнялась, и сайт, основанный на поиске, продолжал успешно обрабатывать запросы и обновлять контент.
В приведенной ниже таблице представлена сводка результатов.
| Расписание тестов | График отношения обновлений | Время работы, ч | Общее максимальное использование диска | Максимальное использование диска заданием аналитики использования |
|---|---|---|---|---|
| День 1 | Нет | 02:35 | 2,65 ГБ | |
| День 2 | Нет | 02:43 | ||
| День 3 | Нет | 03:23 | ||
| День 4 | Нет | 04:39 | ||
| День 5 | Нет | 06:08 | ||
| День 6 | Нет | 07:35 | ||
| День 7 | Да | 08:29 | 82,4 ГБ | 4 ГБ |
На приведенном ниже графике показано время работы за разные дни.
Рисунок 7. Часы работы по дням
Публикация на нескольких сайтах с проверкой подлинности пользователей
Публикация в SharePoint часто используется на сайтах интрасети. С помощью SharePoint Server 2013 на эти сайты можно также добавить публикацию на нескольких сайтах. В следующих разделах описаны важные отличия, которые следует учитывать при планировании сайта публикации на нескольких сайтах с проверкой подлинности пользователей. Правила для сайтов с анонимным доступом, кроме исключений, описанных в следующих разделах, применимы и к сайтам с проверкой подлинности.
Отсутствие кэша результатов анонимного поиска
Как описано в разделе Кэш результатов анонимного поиска выше, этот кэш влияет только на анонимных пользователей сайта SharePoint. Пропускная способность сайтов с проверкой подлинности пользователей значительно ниже, чем на сайтах с анонимным доступом, использующих кэш результатов анонимного доступа. Как правило, сайты интрасети редко находятся под такой высокой нагрузкой, как сайты, описанные в предыдущем разделе (до 100 просмотров страниц в секунду). Тем не менее, важно учитывать это отличие.
Кэш вывода может помочь компенсировать нехватку кэша результатов анонимного поиска в таких сценариях. На сайтах публикации на нескольких сайтах, где ожидается большое количество просмотров страниц в секунду, рекомендуется включить кэш вывода.
Важно!
Веб-части поиска контента имеют параметр, позволяющий им работать в асинхронном режиме. Кэш вывода не применяется к асинхронным веб-частям поиска контента.
Увеличенный индекс поиска
В зависимости от размера предприятия, которое развертывает SharePoint Server 2013, развертывания интрасети для SharePoint Server 2013 обычно индексируют большее количество документов. Это означает, что необходимая топология поиска для индексирования этих документов будет отличаться от топологии, описанной в предыдущем разделе. См. раздел Планирование поиска в SharePoint Server , чтобы соответствующим образом определить размер развертывания SharePoint.
Публикация с присутствием автора
В этом разделе содержатся рекомендации и результаты использования SharePoint Server 2013, но в нем не содержатся подробные сведения о различных функциях, влияющих на планирование емкости. Дополнительные сведения в этой области см. в разделе Управление веб-содержимым в SharePoint Server.
Публикация с присутствием автора и анонимными пользователями
Для своих испытаний мы использовали веб-сайт со следующими характеристиками.
Веб-сайт, содержащий до 20 000 страниц статей, разделенных на 20 папок по 1000 страниц на 50 сайтах в одном семействе.
На сайте используется структурированная навигация.
В среднем сайт получает 50-100 просмотров страниц в секунду.
Шаблоны трафика включают следующие страницы:
20 страниц, содержащих одну веб-часть "Запрос содержимого" (20 процентов трафика);
30 страниц, содержащих несколько веб-частей "Запрос содержимого", выполняющих запросы различных масштабов к базе данных контента (30 процентов трафика);
1600 статей, содержащих по 40 КБ текста и по два изображения (50 трафика).
На следующей схеме представлена рекомендуемая топология серверов.
Рисунок 8. Тестовая топология публикации с присутствием автора
1 компьютер с сервером SQL Server
1 компьютер с приложениями служб SharePoint, выполняющий роль интерфейсного веб-сервера
Результаты тестовой лаборатории
Мы использовали топологию, показанную на предыдущей схеме, в нашей тестовой лаборатории с помощью физических компьютеров и теста нагрузки системы Visual Studio Team System.
В следующей таблице показаны технические характеристики наших тестовых компьютеров.
| Серверные компоненты | Серверы SharePoint |
|---|---|
| Процессоры | Процессоры Intel Xeon с частотой 2,33 ГГц (2 процессора, 8 ядер всего, всего 8 потоков) |
| ОЗУ | 24 ГБ |
| Операционная система | Windows Server 2008 R2 Enterprise (64-разрядная версия) |
| Количество сетевых адаптеров | 2 |
| Скорость сетевого адаптера | 1 Гбит/с |
| Проверка подлинности | Нет — анонимный |
| Тип подсистемы балансировки нагрузки | Программная подсистема балансировки нагрузки Windows |
| Версия программного обеспечения | SharePoint Server 2013 |
| Серверные компоненты | Сервер базы данных |
|---|---|
| Процессоры | Процессоры Intel Xeon MP7130M с частотой 2,79 ГГц (2 процессора, 8 ядер всего, всего 16 потоков) |
| ОЗУ | 16 ГБ |
| Операционная система | Windows Server 2008 R2 Enterprise (64-разрядная версия) |
| Дисковый массив | 2 диска Dell PERC 5/E |
| Количество сетевых адаптеров | 1 |
| Скорость сетевого адаптера | 1 Гбит/с |
| Проверка подлинности | NTLM |
| Версия программного обеспечения | Microsoft SQL Server 2008 R2 с пакетом обновления 1 (SP1) |
В следующей таблице показаны результаты 10-минутного запуска.
| Тестовые функции | Зеленая зона | Красная зона |
|---|---|---|
| Количество пользователей системы VSTS | 5 | 15 |
| Время отклика сервера (50-й процентиль) | 69 мс | 112 мс |
| Время отклика сервера (95-й процентиль) | 92 мс | 221 мс |
| Количество просмотров страниц в секунду | 57 | 93 |
| Средняя загрузка ЦП (сервер приложений и интерфейсный веб-сервер) | 55 | 97 |
| Средняя загрузка ЦП (сервер SQL Server) | 7 | 9 |
| Максимальное использование памяти (сервер приложений и интерфейсный веб-сервер) | 8,9 ГБ | 8,9 ГБ |
Влияние кэша вывода
Кэширование выходных данных — эффективный способ снижения нагрузки на SharePoint Server 2013 в сценариях публикации. Дополнительные сведения см. в статье Планирование кэширования и производительности в SharePoint Server.
В следующей таблице представлены результаты 10-минутного запуска с включенным кэшем вывода и 90-процентным коэффициентом попадания.
| Тестовые функции | Зеленая зона | Красная зона |
|---|---|---|
| Количество пользователей системы VSTS | 5 | 15 |
| Время отклика сервера (50-й процентиль) | 2 мс | 2 мс |
| Время отклика сервера (95-й процентиль) | 74 мс | 88 мс |
| Количество просмотров страниц в секунду | 190 | 418 |
| Средняя загрузка ЦП (сервер приложений и интерфейсный веб-сервер) | 58 | 85 |
| Средняя загрузка ЦП (SQL Server) | 5 | 7 |
| Максимальное использование памяти (сервер приложений и интерфейсный веб-сервер) | 9,2 ГБ | 9,4 ГБ |
Результаты испытаний показывают, что кэширование вывода может значительно повысить пропускную способность сайта публикации SharePoint и сократить время отклика сервера. Для запросов, обслуживаемых из кэша вывода, достигается практически мгновенный отклик.
На следующем графике представлена сводка результатов наших тестов.
Рисунок 9. Влияние кэширования вывода с коэффициентом попадания 90 %
Влияние управляемой навигации
В SharePoint Server 2013 сайты публикации также могут использовать управляемую навигацию. Дополнительные сведения о настройке см. в статье Обзор управляемой навигации в SharePoint Server.
Мы провели для нашего тестового сайта с использованием управляемой навигации такой же набор испытаний, что и для структурированной навигации. Наши испытания показывают, что производительность сайтов с управляемой навигацией практически не отличается от производительности сайтов со структурированной навигацией.
| Тестовые функции | Зеленая зона | Красная зона |
|---|---|---|
| Количество пользователей системы VSTS | 5 | 15 |
| Время отклика сервера (50-й процентиль) | 70 мс | 111 мс |
| Время отклика сервера (95-й процентиль) | 95 мс | 215 мс |
| Количество просмотров страниц в секунду | 56 | 94 |
| Средняя загрузка ЦП (сервер приложений и интерфейсный веб-сервер) | 54 | 97 |
| Средняя загрузка ЦП (сервер SQL Server) | 7 | 9 |
| Максимальное использование памяти (сервер приложений и интерфейсный веб-сервер) | 8 ГБ | 8 ГБ |
На следующем графике показаны различные типы навигации на одном и том же сайте.
Рисунок 10. Сравнение управляемой и структурированной навигации
Влияние добавления компьютеров (масштабирования)
Если для развертывания SharePoint требуется больше пропускной способности, можно рассмотреть возможность горизонтального масштабирования (увеличение числа компьютеров, на которых размещается SharePoint Server 2013). На следующем графике показано, как растет пропускная способность по мере добавления компьютеров в ферму.
Рисунок 11. Влияние добавления интерфейсных веб-серверов на пропускную способность
В наших тестах мы увеличили нагрузку на сервер под управлением SharePoint Server 2013 для каждого добавленного компьютера, чтобы время отклика сервера было примерно одинаковым (около 11 миллисекунда для зеленой зоны, около 250 миллисекунда для красной зоны).
Сайты публикации с присутствием автора и проверкой подлинности пользователей
Функцию публикации SharePoint часто используют в интрасети, где пользователи сайта проходят проверку подлинности. В этом разделе описаны наши тесты с использованием проверки подлинности пользователей и представлены их результаты.
В следующей таблице представлены результаты испытания сайтов публикации с присутствием автора, пользователи которых проходят проверку подлинности на основе утверждений в NTLM. Обратите внимание, что в этих испытаниях использовалось такое же оборудование, как и в тестах из предыдущего раздела.
| Тестовые функции | Зеленая зона | Красная зона |
|---|---|---|
| Количество пользователей системы VSTS | 5 | 15 |
| Время отклика сервера (50-й процентиль) | 76 мс | 107 мс |
| Время отклика сервера (95-й процентиль) | 103 мс | 194 мс |
| Количество просмотров страниц в секунду | 54 | 100 |
| Средняя загрузка ЦП (сервер приложений и интерфейсный веб-сервер) | 50 | 97 |
| Средняя загрузка ЦП (SQL Server) | 6 | 9 |
| Максимальное использование памяти (сервер приложений и интерфейсный веб-сервер) | 9,5 ГБ | 9,5 ГБ |
Результаты показывают, что время отклика сервера и пропускная способность для анонимных и проверенных запросов практически не отличаются.
На следующем графике показаны запросы разных типов на одном и том же сайте.
Рисунок 12. Сравнение анонимных и проверенных запросов
Влияние кэша вывода на сценарии с проверкой подлинности
Проверенные запросы на сервер требуют циклического прохождения к базе данных контента, чтобы убедиться, что соответствующая учетная запись имеет разрешения на просмотр контента. Это значит, что скорость кэширования вывода на сайтах с проверкой подлинности отличается от аналогичного показателя на анонимных сайтах.
В следующей таблице представлены результаты 10-минутного запуска с включенным кэшем вывода и 90-процентным коэффициентом попадания.
| Тестовые функции | Зеленая зона | Красная зона |
|---|---|---|
| Количество пользователей системы VSTS | 6 | 18 |
| Время отклика сервера (50-й процентиль) | 17 мс | 29 мс |
| Время отклика сервера (95-й процентиль) | 87 мс | 118 мс |
| Количество просмотров страниц в секунду | 114 | 236 |
| Средняя загрузка ЦП (сервер приложений и интерфейсный веб-сервер) | 50 | 97 |
| Средняя загрузка ЦП (сервер SQL Server) | 7 | 10 |
| Максимальное использование памяти (сервер приложений и интерфейсный веб-сервер) | 9,9 ГБ | 10 ГБ |
На следующем графике представлена сводка этих результатов.
Рисунок 13. Влияние кэширования вывода с проверкой подлинности
См. также
Концепции
Планирование управления веб-контентом в SharePoint Server
Настройка решений для управления веб-содержимым в SharePoint Server
Настройка параметров кэша для веб-приложения в SharePoint Server
Планирование кэширования и производительности в SharePoint Server