Тестирование производительности MSPS (Microsoft Project Server)

Интро

Привет, Хабр!

До всех горячих событий в мире проводил тестирование производительности Microsoft Project Server 2019 (on-premise). Система большая, популярная для календарного планирования, не особо уже актуальная ввиду политики, однако, надеюсь, будет интересно и возможно, полезно. В сети можно найти результаты коллег (спасибо им большое), которые запустили несколько параллельных тестов через веб-интерфейс и получили какие-то результаты, однако, это скорее антипаттерн в тестировании производительности.

Итак, согласно Microsoft, Project Server — «это корпоративная система для управления портфелями проектов (PPM), которая устанавливается на локальных серверах компании. Она объединяет данные всех проектов в единую базу данных и обеспечивает совместную работу, распределение ресурсов и отслеживание KPI для крупных организаций».

Фабула

Компания X в начале 2010-х пыталась использовать MSPS, однако что-то пошло не так. Что именно никто из «живых» пользователей уже не знает, зафиксирован только итоговый результат — отказ от масштабирования на всю компанию. Однако отдельные подразделения успешно по-партизански пользуются и очень хотят распространить свои подходы на всю компанию.

Термины, сокращения и определения

MSPS – Microsoft Project Server 2019 (on-premise)

API – Application Programming Interface – программный интерфейс приложения

CSOM – SharePoint Client Side Object Mode – программный API для создания клиентских приложений SharePoint

PWA – Project Web App – это входящее в состав Microsoft Project Server веб-приложение, с помощью которого можно выполнять множество задач, аналогичных работе через толстый клиент

AD — Active Directory – службы каталогов корпорации Microsoft для операционных систем семейства Windows Server

Среда (инфраструктура) – комплекс информационных организационных структур, подсистем, обеспечивающих функционирование приложения в промышленной эксплуатации в Компании.

Профиль нагрузки – совокупность операций, участвующих в нагрузочном тестировании, выполняющихся с определенной интенсивностью

БД – база данных

ЦП – центральный процессор

Постановка гипотез

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

Гипотеза 1:

Проблемы работоспособности связаны с объемом данных и работой на клиенте: виртуальные мощности, большой объем подгружаемых данных (проектов, клиентов, сотрудников), особенности структуры планов и иных данных Компании.

Гипотеза 2:

Проблемы работоспособности связаны с серверной частью архитектуры (конфигурация оборудования, настройка сервиса, объем данных, очереди/конкурентный доступ к ресурсам)

Архитектура системы

Для тестирования производительности приложения была выбрана схема с предварительным пилотированием разворачивания приложения на виртуальном сервере с последующим переходом на железный сервер с рекомендованной двух узловой архитектурой (сервер переднего плана с распределенным кэшем + приложение с поддержкой поиска) и выделенной БД. Сервер БД  — MS SQL Server 2019.

Логическая архитектура приложения схематично

Конечный пользователь получает доступ к приложению через толстый клиент MS Project версии не ниже 2016, либо через PWA, используя браузер.

Параметры стендов

Для испытаний использовались два контура:

1) Однонодовая виртуальная машина (MSPSApp-test) с выделенной БД

2) Два железных сервера (ps-test1, ps-test2) в двухнодовой конфигурации с выделенной БД

Решения

Для проверки гипотезы №1 были проведены следующие работы

1) Разработан API на основе CSOM для создания и изменения объектов (проекты, задачи, назначения и т.д.), для анализа успешности операций и получения данных будет использован REST API MSPS

2) Для максимизации нагрузки на систему выставлена политика автоматического создания сайта проекта в PWA (не рекомендованная Microsoft из соображений производительности, но максимально удобная для пользователей)

3) Развернут однонодовый виртуальный сервер MSPSApp-test

4) На MSPSApp-test загружены данные согласно профилю данных (оракулом для профиля данных явилась текущая PPM система Компании)

5) На MSPSApp-test проведён анализ работоспособности под нагрузкой согласно профилю нагрузки с подключением фокус группы менеджеров проектов, имеющих опыт календарного планирования с записью их работы

6) MSPS развернут на железных серверах в двухнодовой конфигурации, загружены данные согласно профилю данных

Для проверки гипотезы №2 были проведены следующие работы

1) На железных серверах ps-test1, ps-test2 проведён анализ работоспособности под нагрузкой согласно профилю нагрузки

Профили нагрузки и данных

Профиль данных

Всего создано проектов — 2035.

Среднее количество участников проектной команды — 9. Среднее количество задач по активностям — 150 с 2 исполнителями.

Создано 10 проектов с пиковыми значениями: количество участников ПК — 120 сотрудников, задач в проекте — 1500 с 80 исполнителями по каждой, 10 уровневая вложенность задач.

Для работы с актуальными пользователями в MSPS синхронизирована AD группа.

Профиль нагрузки

Для эмуляции нагрузки предложен следующий базовый сценарий (за основу был принят сформулированный фокус группой режим работы):

50 конкурентных пользователей, выход на пик нагрузки через 1 час 15 минут (каждые 5 минут заходят 3 новых виртуальных пользователя). Пиковая нагрузка продолжается 250 минут. Далее пиковая нагрузка снижается по следующему сценарию: 3 пользователя прекращают работу в системе каждые 200 секунд. Интенсивность работы пользователей – не более 3-5 секунд между операциями. Процент ошибочных операций не более 1% (запланированное рассогласование между AD группой и профилем данных обеспечивает необходимый для анализа поведения системы при передаче некорректных данных уровень ошибок). Графическое отображение профиля нагрузки.

Пользователи создают новые проекты, задачи, назначают на задачи ресурсы и обновляются иные свойства задач (даты, комментарии, иерархичность). Каждый пользователь работает с проектом эксклюзивно во избежание ошибок конкурентного доступа через CSOM API. Начиная с присутствия в системе 10 виртуальных пользователей, 1 постоянно работает через PWA, используя chrome, оценивая возможную деградацию в тонком клиенте. Также как минимум один пользователь работает с «тяжелыми» проектами (большая команда, иерархичность, кол-во задач и т.д.)

Тест-кейсы нагрузки

1) Осуществить эксклюзивную блокировку проекта

2) Если проект не существует – создать проект

3) Удостовериться в корректности создания проекта

· Далее все операции осуществляются в случае успеха предыдущей, между всеми операциями время задержки с разбросом 3-5 секунд

4) Создать задачу

5) Удостовериться в корректности создания задачи

6) Создать назначение на задачу

7) Проверить есть ли у задачи родитель в иерархии

8) Проверить, существует ли родительская задача, если задача еще не создана – создать

9) Обновить задачу (даты начала и окончания, комментарии, место в иерархии задач проекта)

10) Освободить логическую блокировку проекта, предоставить другим пользователям возможность работы с проектом

11) Серфинг по проектам и задачам (не более 10% виртуальных пользователей)

Результаты тестирования

Обобщенные результаты

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

Ошибки

Серверные ошибки

В процессе тестирования при корректной работе с API серверные ошибки уровня операционной системы или выделения/использования ресурсов не выявлены. Проблем, связанных с виртуализацией сервера, также обнаружено не было.

Ошибки БД

Во время нагрузки не выявлено дедлоков, нагрузка на сервер БД крайне незначительна.

Ошибки уровня приложения и PWA

Деградации времени ответа серверной части в четкой зависимости от интенсивности, либо продолжительности нагрузки не выявлено. Однако, выявлена целая группа проблемных мест интерфейса PWA и архитектуры.

1. Периодические ошибки сортировки и фильтрации списка проектов. Четкой корреляции с нагрузкой не выявлено, ошибки носят постоянный характер.

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

3. Процесс Microsoft.Office.Project.Server.Queuing почти не возвращает оперативную память после затратных массовых операций (массовое удаление проектов и т.д.). Необходимо учитывать при планировании архитектуры риск периодической профилактической перезагрузки серверов или принудительного перезапуска сервисов.

 4. Внутренняя очередь MSPS находится перед API, поэтому кастомизировать работу с объектами MSPS через API при конкурентном доступе из различных источников к одной группе ресурсов невозможно – ресурс падает в дедлок, нужно учитывать это ограничение при планировании архитектуры. За конкурентный доступ отвечает вызывающий клиент.

Сводная информация

Разброс времени выполнения запросов к API в миллисекундах достаточно существенный, но он связан с данными (объем проекта, иерархичность задачи т.д.), а не с нагрузкой.

Время выполнения запроса к API от кол-ва конкурентных пользователей практически не зависит.

График производительности системы от кол-ва виртуальных пользователей практически линеен (за исключением и так очень быстрых REST запросов на получение данных), что указывает на отсутствие серьезных узких мест. Аппаратных мощностей достаточно, сервер может обслужить все запросы.

Показатели работы сервера приложений

Примечание:

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

1. Загрузка процессора.

 Из графика видна полная (пики нагрузки соответствуют пикам использования) корреляция между профилем нагрузки и загрузкой ЦП. Даже на выбросах загрузка не достигает 100%. Освобождение аппаратных ресурсов также своевременное, соответствующее профилю нагрузки. Очередь запросов к процессору своевременно разбирается, количество прерываний невелико (менее 800)

2. Память.

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

3. Жесткий диск, своп, сеть – в пределах нормы без ошибок и резких выпадов.