Share via

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

  • Статья

 

**Применимо к:**SharePoint Server 2013 Enterprise, SharePoint Server 2013 Standard

**Последнее изменение раздела:**2017-08-25

Сводка. Узнайте, как запланировать и провести тестирование производительности среды SharePoint Server 2013.

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

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

Далее представлены рекомендуемые этапы, которые необходимо реализовать перед переносом системы в рабочую среду:

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

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

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

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

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

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

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

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

В этой статье

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Тестовые серверы: при планировании тестовой среде, необходимо не только планирование для серверов в ферме, SharePoint Server 2013, также необходимо спланировать машины, необходимые для выполнения тестов. Как правило, которое будет включать 3 сервера по крайней мере; Дополнительные может потребоваться. Если вы используете Visual Studio Team System (агент группы для тестирования нагрузки) для тестирования, один компьютер будет использоваться как контроллер теста нагрузки. Как правило, 2 или более компьютеров, которые используются в качестве агентов нагрузочного тестирования. Агенты — это компьютеры, выполните инструкции из контроллера тестирования о том, что для тестирования и выдача запросов в ферме 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 вам потребуется и как вы будете связывать с ними пользователей.

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

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

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

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

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

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

После работы тестовой среде, настало время создание и настройка тесты, которые будут использоваться для измерения производительности мощности в ферме. В этом разделе будет иногда ссылаются специально для Visual Studio Team System (агент группы для тестирования нагрузки), но многие понятия, применимы независимо от того, какое средство тестовой нагрузки, можно использовать. Дополнительные сведения о Visual Studio Team System можно Visual Studio Team System в MSDN (https://msdn.microsoft.com/en-us/library/fda2bad5.aspx»).

Вы также можете использовать комплект SharePoint Load Test Kit (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 в качестве упражнения при планировании или нагрузочного теста перед обновлением.

Комплект Load Test Kit входит в состав набора средств Microsoft SharePoint 2010 Administration Toolkit v1.0, который доступен в Центре загрузки Майкрософт (https://www.microsoft.com/downloads/details.aspx?FamilyId=718447d8-0814-427a-81c3-c9c3d84c456e\&displaylang=en).

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

  • Всегда используйте правила проверки для теста. Например, если при запросе страницы возникает ошибка, часто в ответе будет содержаться страница error.aspx. С точки зрения веб-теста это всего лишь очередной положительные ответ, так как вы получаете код состояния HTTP 200 (успешное выполнение) в результатах нагрузочного теста. Очевидно, что произошла ошибка, поэтому ее нужно обработать по-другому. Одно или несколько правил проверки позволяет перехватывать передачу определенного текста в ответе, который вызывает сбой проверки и отмечает запрос как ошибочный. Например, в Visual Studio Team System простым правилом проверки может быть проверка ResponseUrl — она сообщает об ошибке, если страница, которая отображается следующей, не соответствует странице ответа, записанной в тесте. Вы также можете добавить правило FindText, которое сообщает об ошибке, если оно находит в ответе, например, фразу "в доступе отказано".

  • Используйте несколько пользователей в различных ролях для тестов. Определенные компоненты, например кэширование вывода, зависят от прав текущего пользователя. Например, администратор семейства сайтов или прошедший проверку пользователь с правами утверждения или создания не будут получать кэшированные результаты, так как мы хотим, чтобы они всегда видели самую последнюю версию контента. Анонимные пользователи будут получать кэшированный контент. Необходимо убедиться, что тестовые пользователи представляют сочетание этих ролей, которое приблизительно совпадает с составом ролей в рабочей среде. Например, в рабочей среде всего два или три администратора семейства сайтов, поэтому не следует создавать тесты, где 10% запросов к тестовому контенту исходят от учетных записей администраторов сайтов.

  • Синтаксический анализ зависимых запросов — это атрибут Visual Studio Team System, который определяет, следует ли агент тестирования попытаться получить только страницу или страницу и все связанные запросы, являющиеся частью страницы, такие как изображения, таблицы стилей, скрипты и т. д. При нагрузочном тестировании мы обычно игнорируем эти элементы по нескольким причинам:

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

    • Эти элементы не обычно поступают от сервера SQL Server, в SharePoint Server 2013-среды на основе. С включенным кэшированием больших двоичных ОБЪЕКТОВ, вместо этого обслуживаются с веб-серверов, они не создают нагрузки SQL Server.

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

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

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

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

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

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

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

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

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

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

  • Используйте шаблон постоянной нагрузки для наиболее надежный и воспроизводимый результаты. В Visual Studio Team System (агент группы для тестирования нагрузки), которые у вас есть возможность создания загрузить константу число пользователей (как описано в предыдущей точки потоков) последовательными копирование шаблон нагрузки пользователей или на основе целей тестирования об использовании. Шаблон последовательными — при запуске с меньшее число пользователей и затем «шаг» Добавление дополнительных пользователей каждые несколько минут. Использование тестового на основе целей при установить порог для определенных диагностики счетчика, как уровень использования ЦП, и выполняется попытка нагрузку для хранения этого счетчика между минимальный и максимальный порогового значения, определяющие его тестирования. Если вы пытаетесь только для определения максимальная пропускная способность, которые способен обрабатывать фермы SharePoint Server 2013 максимальной загрузки, гораздо более эффективным и точных выберите шаблон постоянной нагрузки. Который позволяет определить объем нагрузки в системе можно было перед началом работы регулярно превышает пороговые значения, которые должны сохраняться в работоспособном фермы.

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

See also

Планирование мощности для SharePoint Server 2013
Мониторинг и обслуживание SharePoint Server 2013
Мониторинг и создание отчетов в SharePoint Server 2016
Ограничения, связанные с программным обеспечением, в SharePoint Server 2016

Обзор управления емкостью и изменения размера в SharePoint Server 2013