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

ОБЛАСТЬ ПРИМЕНЕНИЯ:2013 2016 2019 Subscription Edition SharePoint в Microsoft 365

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

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

Ниже приведены рекомендуемые ниже действия, которые следует выполнить для предварительной подготовки.

• Создайте тестовую среду, имитирующую изначальную архитектуру, созданную в разделе Шаг 2. Разработка.

• Заполните хранилище набором данных или его частью, как определено на этапе Шаг 1. Модель.

• Создайте в системе искусственную нагрузку, которая соответствует рабочей нагрузке, определенной на этапе Шаг 1. Модель.

• Выполните тесты, проанализируйте результаты и оптимизируйте свою архитектуру.

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

• Проанализируйте результаты работы пилотной среды, определите возможные "узкие места" и оптимизируйте архитектуру. Повторите тестирование при необходимости.

• Разверните систему в рабочей среде.

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

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

Убедитесь, что в ваш план включено:

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

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

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

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

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

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

• Проверка подлинности. Решите, будет ли ферма использовать доменные службы Active Directory (AD DS), проверку подлинности на основе форм (и, если да, с каким каталогом), проверку подлинности на основе утверждений и т. д. Независимо от того, какой каталог вы используете, сколько пользователей требуется в тестовой среде и как их создавать? Сколько групп или ролей вам потребуется и как вы будете их создавать и заполнять? Кроме того, необходимо убедиться, что для служб проверки подлинности выделяется достаточно ресурсов, чтобы они не стали узким местом во время тестирования.

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

• Балансировка нагрузки. Если вы используете несколько серверов (что обычно требуется или у вас, скорее всего, недостаточно нагрузки для нагрузочного тестирования), вам потребуется какое-то решение подсистемы балансировки нагрузки. Это может аппаратная подсистема или программное решение, например Windows NLB. Определите, что вы будете использовать, и запишите все сведения о конфигурации, необходимые для быстрой и эффективной настройки. Кроме того, следует помнить, что агенты нагрузочного тестирования обычно пытаются разрешить адрес в URL-адрес только каждые 30 минут. Это означает, что для балансировки нагрузки не следует использовать локальный файл hosts или dns с циклическим перебором, так как агенты тестирования, скорее всего, будут переходить на один и тот же сервер для каждого запроса вместо балансировки между всеми доступными серверами.

• Тестовые серверы. При планировании тестовой среды необходимо не только планировать серверы для фермы SharePoint Server 2013, но и планировать компьютеры, необходимые для выполнения тестов. Как правило, это будет включать как минимум три сервера; может потребоваться больше. Если вы используете Visual Studio Team System (team Test Load Agent) для выполнения тестирования, один компьютер будет использоваться в качестве контроллера нагрузочных тестов. Как правило, в качестве агентов нагрузочного тестирования используются два или более компьютеров. Агенты — это компьютеры, которые берут инструкции от контроллера тестирования о том, что следует тестировать и отправлять запросы в ферму SharePoint Server 2013. Результаты теста сохраняются на компьютере с SQL Server. Не следует использовать тот же компьютер под управлением SQL Server, который используется для фермы SharePoint Server 2016, так как запись тестовых данных приведет к перекосу доступных ресурсов SQL Server для фермы SharePoint Server 2013. Кроме того, необходимо отслеживать тестовые серверы при выполнении тестов так же, как и серверы в ферме SharePoint Server 2013, контроллерах домена и т. д., чтобы убедиться, что результаты теста являются репрезентативными для настраиваемой фермы. Иногда агенты или контроллер тестирования сами могут стать узкими местами. Если это произойдет, пропускная способность, которую вы видите в тесте, обычно не является максимальной поддержкой фермы.

• SQL Server. В тестовой среде следуйте инструкциям в разделах "Настройка SQL Server" и "Проверка и мониторинг производительности хранилища и SQL Server" в статье Планирование и настройка емкости хранилища и SQL Server (SharePoint Server).

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

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

• Все страницы должны быть опубликованы, не должно быть извлеченных элементов.

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

• Вы должны иметь представление о настройках, которые будет использовать рабочий сайт. Например, эталонные страницы, таблицы стилей, JavaScript и т. д. должны быть реализованы в тестовой среде как можно ближе к рабочей среде.

• Определите, сколько групп и (или) уровней разрешений SharePoint вам потребуется, и как вы будете связывать с ними пользователей.

• Установите, нужно ли вам будет импортировать профили и сколько времени этой займет.

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

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

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

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

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

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

Вы также можете использовать пакет нагрузочных тестов SharePoint (LTK) с VSTS для нагрузочного тестирования ферм SharePoint 2010. Комплект Load Test Kit создает нагрузочный тест Visual Studio Team System 2008 на основе журналов Windows SharePoint Services 3.0 и Microsoft Office SharePoint Server 2007 IIS. Нагрузочный тест VSTS можно использовать для создания искусственной нагрузки для SharePoint Foundation 2010 или SharePoint Server 2010 в рамках упражнения по планированию емкости или предварительного стресс-теста.

Комплект нагрузочных тестов входит в набор средств администрирования Microsoft SharePoint 2010 версии 2.0, доступный в Центре загрузки Майкрософт.

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

В Visual Studio Team System (Team Test Load Agent) источник данных может поступать в различных форматах, но формат CSV-файла часто проще всего управлять и передавать между средами разработки и тестирования. Помните, что для создания CSV-файлов с этим контентом может потребоваться разработать настраиваемые средства для перечисления объектов среды на основе SharePoint Server 2013 и записать различные используемые 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, который определяет, следует ли агент тестирования попытаться получить только страницу или страницу и все связанные запросы, являющиеся частью страницы, такие как изображения, таблицы стилей, скрипты и т. д. При нагрузочном тестировании мы обычно игнорируем эти элементы по нескольким причинам:

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

  • Обычно данные элементы не поступают от SQL Server в среде на основе SharePoint Server 2013. Если кэширование BLOB-объектов включено, они обслуживаются веб-серверами, чтобы не создавать нагрузку SQL Server.

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

• Не забудьте также моделировать действия клиентского приложения. Клиентские приложения, такие как Microsoft Word, PowerPoint, Excel и Outlook, также создают запросы к фермам SharePoint Server 2013. Они добавляют нагрузку на среду, отправляя серверные запросы, такие как получение RSS-каналов, получение сведений о социальных сетях, запрос сведений о структуре сайта и списка, синхронизация данных и т. д. Эти типы запросов следует включать и моделировать, если в реализации есть эти клиенты.

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

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

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

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

• Используйте разумное отношение операций чтения и записи в своих тестах. Слишком большое число операций записи может сильно повлиять на общую пропускную способность теста. Даже в фермах совместной работы число операций чтения в большинстве случаев намного превышает число операций записи.

• Рассмотрите влияние других ресурсоемких операций и определите, следует ли их выполнять во время теста. Например, такие операции, как резервное копирование и восстановление обычно не выполняются во время нагрузочного теста. Полный обход поиска не проводится во время нагрузочного теста, а вот добавочный обход может выполняться. Следует проанализировать, как эти задачи будут запланированы в рабочей среде — они будут выполняться при пиковой нагрузке? Если нет, то они, вероятно, должны быть исключены во время нагрузочного тестирования, когда вы пытаетесь определить максимальную постоянную нагрузку, которую вы можете поддерживать для пиковой нагрузки.

• Не используйте время на обдумывание — возможность Visual Studio Team System, позволяющая имитировать время ожидания пользователей между щелчками на странице. Например, типичный пользователь может загрузить страницу, потратить три минуты на ее чтение, а затем перейти по ссылке на другой сайт. Смоделировать это в тестовой среде корректно практически невозможно, а эффективность результатов теста это не повышает. Сложность моделирования связана с тем, что у большинства организаций нет средств для отслеживания различных пользователей и времени, которое проходит между переходами на различные сайты SharePoint (например, сайты публикации или совместной работы и т. д.). Это также не добавляет ценности, потому что даже если пользователь может приостановить между запросами страницы, серверы на основе SharePoint Server 2013 этого не делает. Они просто получают устойчивый поток запросов, которые могут иметь пики и долины с течением времени, но они не ждут бездействия, так как каждый пользователь останавливается между щелчком по ссылкам на странице.

• Понимать разницу между пользователями и запросами. Visual Studio Team System (team Test Load Agent) имеет шаблон нагрузки, в котором требуется ввести число пользователей для имитации. Это не имеет ничего важного для пользователей приложений, это просто то, сколько потоков будет использоваться в агентах нагрузочных тестов для создания запросов. Распространенная ошибка заключается в том, что, например, если в развертывании будет 5000 пользователей, то 5000 — это число, которое должно использоваться в Visual Studio Team System (team Test Load Agent) — это не так! Это одна из многих причин, почему при оценке требований к планированию емкости требования к использованию должны основываться на количестве запросов в секунду, а не на количестве пользователей. В нагрузочном тесте Visual Studio Team System (team Test Load Agent) вы обнаружите, что часто можно создавать сотни запросов в секунду, используя только от 50 до 75 нагрузочных тестов "users".

• Используйте постоянный шаблон нагрузки для получения надежных и воспроизводимых результатов тестирования. В Visual Studio Team System (team Test Load Agent) вы можете основывать нагрузку на постоянном количестве пользователей (потоки, как описано в предыдущем пункте), шаблоне более поздней нагрузки пользователей или тесте использования на основе целей. Ступенчатый шаблон нагрузки начинает тест с небольшого числа пользователей и затем добавляет дополнительных пользователей каждые несколько минут. Тест использования на основе целевых показателей позволяет указать пороговое значение для определенного счетчика диагностики, например использование ЦП, а затем пытается изменять нагрузку, чтобы держать значение счетчика между минимальным и максимальным ограничением. Однако если вы просто пытаетесь определить максимальную пропускную способность фермы SharePoint Server 2013 во время пиковой нагрузки, эффективнее и точнее выбрать шаблон постоянной нагрузки. Так вам будет легче определить, какую нагрузку выдержит система, перед тем как регулярно будут превышаться пороговые значения, которые должны поддерживаться в работоспособной ферме.

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

См. также

Концепции

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

Мониторинг и обслуживание SharePoint Server 2013

Ограничения, связанные с программным обеспечением, в SharePoint Server 2016

Другие ресурсы

Capacity management and sizing overview for SharePoint Server 2013