Тестирование производительности для SharePoint Server 2010

Статья
03/05/2017

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

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

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

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

Ниже перечисляются вспомогательные шаги, которые рекомендуется выполнить на этапе подготовки:

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

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

Содержание:

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

Создание плана тестирования

Убедитесь, что план включает следующие элементы:

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

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

После определения целей теста, необходимых измерений и требований к емкости фермы (на этапах 1 и 2 этого процесса), следующей целью будет проектирование и создание тестовой среды. Работа по созданию тестовой среды часто недооценивается. Тестовая среда должна как можно точнее соответствовать рабочей среде. При разработке тестовой среды следует продумать следующие компоненты и функции:

Проверка подлинности — выберите способ проверки подлинности, который будет использовать ферма: доменные службы 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, контроллеры доменов и т. д., чтобы гарантировать, что результаты тестов характеризуют настраиваемую ферму. Иногда агенты или контроллер нагрузки могут сами стать узким местом. Если это происходит, то демонстрируемая тестами производительность как правило не отражает то максимальное значение, которое может поддерживать ферма.
SQL Server — в тестовой среде следуйте руководствам, данным в разделах "Настройка SQL Server" и " Проверка и мониторинг хранилища и производительности SQL Server" статьи Планирование и настройка рабочих характеристик хранилища и SQL Server (SharePoint Server 2010).
Проверка набора данных — при выборе контента, с которым будут выполняться тесты, учтите, что наилучшим вариантом является использование данных из существующей рабочей среды. Например, можно создать резервную копию баз данных контента из рабочей фермы и восстановить их в тестовой среде, а затем присоединить базы данных к ферме. При выполнении тестов с искусственно созданными или типовыми данными результаты могут быть искажены из-за их отличия от реального контента.

Если необходимо создать типовые данные, учтите следующие соображения при построении такого контента:

Все страницы должны быть опубликованы; ничто не должно быть извлечено
Навигация должна быть реалистичной; не выходите за пределы того, чего достаточно для использования в рабочей среде.
Следует продумать настройки, которые будет использовать рабочий сайт. Например, реализованные в тестовой среде главные страницы, таблицы стилей, JavaScript и т. д. должны как можно точнее соответствовать рабочей среде.
Определите, сколько потребуется групп и/или уровней разрешений SharePoint и как связать с ними пользователей.
Определите, нужно ли импортировать профили и сколько времени это займет.
Определите, понадобятся ли аудитории и как они будут создаваться и наполняться.
Определите, нужны ли дополнительные источники контента для поиска и что потребуется для их создания. Если создавать их не нужно, определите, будет ли предоставлен сетевой доступ для их обхода.
Определите, достаточно ли типовых данных — документов, списков, элементов списков и т. д. Если данных недостаточно, запланируйте создание этого контента.
Запланируйте достаточно уникального контента для адекватного тестирования поиска. Распространенной ошибкой является отправка одного и того же документа — сотен или даже тысяч элементов — в разные библиотеки документов с разными именами. Это может повлиять на производительность поиска, так как обработчик запросов будет регулярно тратить время на повторное обнаружение, чего он не должен делать в рабочей среде с реальным контентом.

Создание тестов и средств тестирования

После подготовки тестовой среды необходимо создать и настроить тесты, которые будут использоваться для измерения производительности фермы. В этом разделе иногда будут приводиться ссылки на Visual Studio Team System (Team Test Load Agent), но многие концепции применимы независимо от используемого средства нагрузочного тестирования. Дополнительные сведения о Visual Studio Team System см. в статье о Visual Studio Team System на веб-сайте MSDN (https://msdn.microsoft.com/ru-ru/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, доступный в центре загрузки Майкрософт (Возможно, на английском языке) (https://www.microsoft.com/downloads/en/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-файлах для нагрузочных тестов
Отправка образцов документов в различные библиотеки документов и на сайты
Создание семейств веб-сайтов, веб-сайтов, списков, библиотек, папок и элементов списков
Создание личных сайтов
Создание 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), который определяет, должен ли агент тестирования пытаться получить только страницу или также все связанные запросы, являющиеся частью страницы, например изображения, таблицы стилей, скрипты и т. д. При нагрузочном тестировании эти элементы обычно игнорируются по нескольким причинам:
- После первого обращения пользователя к сайту эти элементы часто кэшируются локальным браузером
- Как правило, эти элементы не поступают из SQL Server в среде, основанной на SharePoint Server 2010. При включенном кэшировании больших двоичных объектов они обслуживаются веб-серверами и поэтому не создают нагрузку на SQL Server.

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

Не забудьте также выполнить моделирование действий клиентского приложения. Клиентские приложения, такие как Microsoft Word, PowerPoint, Excel и Outlook, также порождают запросы ферм SharePoint Server 2010. Они добавляют нагрузку на среду, отправляя такие запросы сервера, как получение RSS-каналов, получение социальных сведений, запросы сведений о структуре сайтов и списков, синхронизация данных и т. д. Эти типы запросов должны включаться в тесты и моделироваться, если в реализации есть такие клиенты.
В большинстве случаев веб-тест должен содержать только один запрос. Если тест содержит только один запрос, это упрощает настройку и диагностику окружения теста и отдельных запросов. Как правило, веб-тесты должны содержать несколько запросов только в тех случаях, когда моделируемые ими операции состоят из нескольких запросов. Например, многошаговый тест потребуется для тестирования такого набора действий: извлечение документа, его редактирование, возвращение и публикация. Для этого документа также требуется резервирование состояния между действиями — например, одна и та же учетная запись должна использоваться для его извлечения, правки и возвращения. Такие многошаговые операции, требующие переноса состояния между действиями, лучше всего обслуживаются несколькими запросами в одном веб-тесте.
Проверьте каждый веб-тест в отдельности. Убедитесь, что каждый тест способен успешно выполняться, перед тем как выполнять его в более крупном нагрузочном тесте. Убедитесь, что все имена веб-приложений разрешаются, а используемые в тесте учетные записи пользователей обладают достаточными правами для его выполнения.

Веб-тесты содержат запросы отдельных страниц, отправки документов, просмотра элементов списков и т. д. Все эти запросы действуют совместно в нагрузочных тестах. В нагрузочный тест включаются все различные веб-тесты, которые должны быть выполнены. На выполнение каждого веб-теста может быть выделен определенный процент времени — например, если вы считаете, что 10% запросов в рабочей ферме — это поисковые запросы, настройте в нагрузочном тесте для выполнения веб-теста поисковых запросов 10% времени. В Visual Studio Team System (Team Test Load Agent) для нагрузочных тестов также можно настроить такие элементы, как набор браузеров, набор сетей, шаблоны нагрузки и параметры выполнения.

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

Используйте в тестах подходящее соотношение операций чтения/записи. Перегрузка теста операциями записи может существенно повлиять на общую производительность теста. Даже в фермах для совместной работы в соотношении операций чтения/записи операций чтения значительно больше. Дополнительные сведения см. в статье Performance and capacity technical case studies (SharePoint Server 2010).
Учитывайте влияние других ресурсоемких операций и продумайте, должны ли они происходить во время нагрузочного тестирования. Например, во время нагрузочного тестирования обычно не выполняются такие операции, как резервное копирование и восстановление. Во время нагрузочного тестирования обычно не выполняется полный обход контента при поиске, тогда как добавочный обход можно считать нормальным. Необходимо учесть, как такие задачи будут запланированы в рабочей среде — будут ли они выполняться во время пиковой нагрузки? Если нет, их вероятно следует исключить во время нагрузочного тестирования, когда определяется максимальная для стабильного состояния нагрузка, которая может поддерживаться для пикового трафика.
Не используйте время задержки. Время задержки — это функция Visual Studio Team System (Team Test Load Agent), которая позволяет моделировать время паузы между нажатиями пользователя на странице. Например, типичный пользователь может загрузить страницу, потратить три минуты на ее чтение, а затем щелкнуть ссылку на странице, чтобы перейти на другой сайт. Правильное моделирование такой ситуации в тестовой среде практически невозможно и в сущности не сделает результаты тестирования более ценными. Трудность моделирования обусловлена тем, что в большинстве организаций нет способа отслеживания действий различных пользователей и времени, которое проходит между нажатиями пользователей на разных типах сайтов SharePoint (например, на сайтах публикации, сайтах поиска, сайтах для совместной работы и т д.). Это также не имеет практического смысла, так как пользователь может делать паузы между запросами страниц, а серверы на основе SharePoint Server 2010 — не могут. Они просто получают равномерный поток запросов, который может иметь пики и провалы с течением времени, но не простаивают в состоянии ожидания во время пауз между нажатиями пользователей на ссылки на страницах.
Следует понимать разницу между пользователями и запросами. В Visual Studio Team System (Team Test Load Agent) имеется шаблон нагрузки, в который можно ввести число моделируемых пользователей. Это число не имеет отношения к пользователям приложения, а просто определяет, сколько потоков должно использоваться в агентах нагрузочного тестирования для создания запросов. Будет ошибкой считать, что если в развертывании имеется, к примеру, 5000 пользователей, то и в 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

Создание плана тестирования

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

Создание тестов и средств тестирования

See Also

Concepts

Дополнительные ресурсы