Тестирование производительности для 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 (агент загрузки команды тестеров) для тестирования, то один компьютер будет использоваться как контроллер нагрузочного тестирования. Как правило, в качестве агентов нагрузочного тестирования используются два или более компьютеров. Агенты — это компьютеры, которые берут инструкции от контроллера тестирования о том, что следует тестировать и отправлять запросы в ферму 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 источник данных может быть представлен в разных форматах, но формат 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 простым правилом проверки может быть проверка 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