Интро
Привет, Хабр!
До всех горячих событий в мире проводил тестирование производительности 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 запросов на получение данных), что указывает на отсутствие серьезных узких мест. Аппаратных мощностей достаточно, сервер может обслужить все запросы.
Показатели работы сервера приложений
Примечание:
Приведены метрики, представляющие интерес для дальнейшей оптимизации аппаратных средств приложения. Метрики, показавшие отсутствие зависимости между нагрузкой на приложение и самой количественной характеристикой, в отчете не представлены.
Загрузка процессора.
Из графика видна полная (пики нагрузки соответствуют пикам использования) корреляция между профилем нагрузки и загрузкой ЦП. Даже на выбросах загрузка не достигает 100%. Освобождение аппаратных ресурсов также своевременное, соответствующее профилю нагрузки. Очередь запросов к процессору своевременно разбирается, количество прерываний невелико (менее 800)
2. Память.
Расход оперативной памяти имеет очень небольшую повышательную тенденцию с начала нагрузки на MSPS. Понижения объема используемой памяти после снижения нагрузки не происходит. Есть риск необходимости периодических профилактических перезагрузок серверов или сервисов MSPS.
3. Жесткий диск, своп, сеть – в пределах нормы без ошибок и резких выпадов.
