Нагрузочное тестирование 5000+ пользователей онлайн — играем в игру

Задачи на тест: 

• понять, будет ли адекватно работать система на Postgre SQL вместо MS SQL на такой же нагрузке;
• подобрать и проверить параметры сервера под 1500+ пользователей онлайн;
• определить максимальные возможности серверов;
• найти "узкие" места в конфигурации ERP.

План тестирования:

• выполняем предварительный нагрузочный тест с помощью фоновых заданий и выполнения в них некоторого набора операций;
• выполняем нагрузочный тест с моделированием поведения пользователей и запуском клиентских соединений: линейный запуск клиентов тестирования по наборам значений 100, 150, 200, 250, 300 и т.д. ботов.

Вступление:

Эта статья в первую очередь будет интересна тем, кто задумался использовать СУБД Postgre SQL в качестве основной или как замену MS SQL. А также тем кого интересует проведение альтернативного нагрузочного тестирования на практике.

В этой части мы рассмотрим процедуру выполнения нагрузочного тестирования, во второй остановимся на выявленных проблемах быстродействия и их исправлению - часть из них актуальна для последних версий типовой конфигурации ERP/УТ/КА.

Срок на выполнение данного проекта был серьезно ограничен и на выполнение работ отводился ровно 1 месяц. Поэтому мы решили ограничить объем предстоящих работ и не включили некоторые интересные доработки - отказались от модификации отчета тепловой карты нагрузки (она красива и удобна), не включили проверку контуров производственного, качество и бюджетирования, не довели до полноценного релиза изменения в Фреймворке "Тестирование 3.0" (доработаем и выложим в ближайшее время) и некоторые другие вопросы. Серьезно пришлось поработать молотком и напильником, но это того стоило. По результатам, которого мы получили бесценный опыт, доработанную концепцию, инструмент и теперь  знаем гораздо лучше что и куда смотреть.

Выражаю благодарность команде из Раруса (Олег, Георгий и др.) за помощь в части стендов тестирования и обсуждения технических вопросов. Методика и инструментарий были с нашей стороны.

Замечания: 

Критерием мы не ставим во главу угла количество пользователей в базе онлайн или активных пользователей, т.к. этот критерий не о чем. Критерий - это сколько пользователей сервис 1С может обслуживать одномоментно. Вот этот основной критерий оценки. 

Это достаточно объективный критерий подтвержденный практикой. Исходя из этого, мы в  отличии от реального запуска большого количества ничего не делающих пользователей будем моделировать нагрузку меньшим количеством но равных по количеству одновременных операций/действий производимых пользователями. Проще можно сказать так: 1500+ пользователей одновременно будут нажимать 50 клавиш и наши боты будут делать столько же нажатий. Поэтому можно считать что тесты эквивалентны.

Приблизительную формулу связи обращений к сервисам 1С в единицу времени и количества пользователей онлайн для обычной стандартной нагрузки можно описать как:

количество обращений к сервисам 1С в ед. времени = количество пользователей онлайн * от 4% до 6%

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

И обратная формула:

количество пользователей онлайн = количество обращений к сервисам 1С в ед. времени/ от 4% до 6%

где количество обращений к сервисам 1С в ед. времени - это очередь время вызова (текущее) (отражает нагрузку 1С) или очередь захвачено СУБД (отражает нагрузку на СУБД), про них можно посмотреть тут: Анализ проблем производительности по динамике мониторинга RAS 1C

В статье приведем процесс выполнения и последовательность шагов, которые мы выполнили, а также сделаем необходимые выводы. 

Структура статьи:

• I) Подготовка к началу тестирования
• II) Предварительный много поточный тест в фоновых заданиях.
• III) Замечания по выполнению тестирования с использованием клиентских приложений
  • Как все это запускать?
  • Не используйте API Automation UI
  • Особенности создания скриптов
• IV) Запускаем большую игру
  • Первый запуск на большой нагрузке и необходимость изменить настройки кластера
  • Запуск 350+ ботов и эквивалент 5000+ пользователей 40 ядер СУБД
  • Запуск 200+ ботов и эквивалент 2000+ пользователей 28 ядер СУБД
  • Запуск 200+ ботов и эквивалент 2000+ пользователей 40 ядер СУБД
• V)Смотрим поведение на рабочей базе после переезда, делаем выводы
• Резюме
• Ссылки

I) Подготовка к началу тестирования:

Инструменты:

Требуется достаточный минимум:

• Фреймворк «Мониторинг производительности»;
• Фреймворк «Тестирование 3.0».

Дополнительно можно:

• Zabbix (обычно ставят по умолчанию);
• Настройка Apdex в целевой конфигурации;
• И другое, все что нужно для ваших замеров.

Стенд:

Создали стенд, который должен будет имитировать будущую реальную базу и  это два сервера:

• под 1С 8.3.16 — ОС: Windows Server, RAM: 200 ГБ, CPU: 24 -32 ядра;
• под СУБД  Postgres 11 — ОС: Linux (Ubuntu); RAM: 150 ГБ; CPU: 24-40 ядер.

Стенд для много поточного тестирования:

Этот стенд использовался для предварительной оценки разницы в работе между двумя СУБД. Сервер 1С и обе СУБД находятся на одной машине. В процессе тестирования отключалась одна или другая база данных:

• ОС: Windows Server; RAM: 128 ГБ; CPU: 6/12. 

Стенд для разработки сценариев и проверки:

Для разработки и отладки мы использовали стенд на одном сервере под 1С и СУБД Postgres:

• ОС: Windows Server, RAM: 128 ГБ, CPU: 12 ядер.

Стенд для формирования нагрузки:

Это наши сервера для разработки, персональные компьютеры — все то где мы можем запустить клиентов 1С. От характеристик зависит то количество клиентов, которое можно запустить. В нашем случае важную роль играет CPU, т.к. бот запускался на легкой базе 1С «Тестирование 3.0» и потреблял не более 250 МБ, а браузер не более 150 МБ.

По опыту не рекомендуем в одной сессии запускать более 24 клиентов, иначе начинает твориться полная жесть — глючит UI интерфейс и формы.

Приведем пример нескольких машин, большинство из них виртуальные:

• ОС: Windows 10; RAM: 8 ГБ; CPU: 4/4;  под 10 клиентов
• ОС: Windows 10; RAM: 32 ГБ; CPU: 4/8;  под 16 клиентов
• ОС: Windows 10; RAM: 32 ГБ; CPU: 6/12; под 16 клиентов
• ОС: Windows Server; RAM: 48 ГБ; CPU: 12/12; под 24 клиента
• ОС: Windows Server; RAM: 256 ГБ; CPU: 4/8; под 20 клиента
• ОС: Windows Server; RAM: 256 ГБ; CPU: 10/20; под 56 клиентов  (2-3 сессии RDP)
• ОС: Windows Server; RAM: 128 ГБ; CPU: 16/32; под 64 клиентов (2-3 сессии RDP)

Схема стенда:

Критерии оценки результатов:

Оценивать результаты нагрузочного теста можно по различным показателям. Обычно предлагают смотреть количество запустившихся клиентов и значения показателей APDEX ключевых операций. Но мы будем смотреть и оценивать следующие параметры (приведем основные):

    • очередь к сервисам 1С (захвачено СУБД и время вызова (текущее));
    • время выполнения ключевых операций (проведение документов, обновление динамических списков);
    • основные показатели оборудования серверов (CPU Load и Queue).

Сценарии процессов:

• продажи — охвачен контур продаж товаров и услуг; подразумевается создание полного пакета документов для выполнения цепочки продажи — «Заказ клиента», «Задание на перевозку» «Реализация товаров и услуг», «Акт выполненных работ», «Расходный ордер на товары».
• перемещения — контур внутреннего перемещения товаров между складами; подразумевается создание полного пакета документов: «Заказ на перемещение», «Задание на перевозку», «Перемещение товаров и услуг», «Приходный ордер на товары», «Расходный ордер на товары».
• закупки — контур закупок товаров у поставщиков;  набор документов - «Заказ поставщику», «Задание на перевозку», «Приобретение товаров и услуг», «Приходный ордер на товары».
• аналитические отчеты — различные отчеты по наборам фильтров и без, т.е. просмотр отчетов идет отдельно от цепочек выше. Используемые отчеты — по остаткам товаров на складах, взаиморасчеты с клиентами, взаиморасчеты с поставщиками, коммерческие товары на складах, резервы товаров на складах и др.

Методология управления нагрузкой:

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

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

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

Виды ботов:

Мы создали достаточно широкий набор ботов, которого вполне достаточно для выполнения нагрузочного теста:

• снабженец — выполняет задачи по закупке, создает заказы на поступление;
• ДОУ закупки — создают приобретения товаров услуг, печать накладных;
• кладовщик на приемке — выполняет задачи по созданию приходных ордеров, заведения серий;
• кладовщик на отгрузке — выполняет задачи по созданию расходных ордеров;
• бухгалтер — выполняет работу связанную с заведением поступления и списания БДС;
• продаван — выполняет создание документов коммерческих предложений и заказов клиентов;
• продаван процессинг - управляет жизненным циклом документа заказ клиента;
• ДОУ продажи — создает документы реализаций товаров, акты, печать накладных;
• логист — управляет жизненным циклом документа задание на перевозку;
• отчеты продажи — смотрят отчеты в разрезах аналитик продажи;
• отчеты товары — смотрят отчеты по складам: остатки, наличие и т.п.;
• отчеты резервы — смотрят отчеты в разрезах резервов товаров;

Масштабирование теста:

Масштабом теста мы управляли путем заведения набора следующих разрезов аналитик:

• склады; 
• организации;
• клиенты;
• поставщики;
• номенклатура;
• клон (определяет количество дублей ботов);

Итоговое количество комбинаций зависит от типа бота. К примеру, для кладовщика имеют значения аналитика склад и клон (для клона надо учитывать вопросы конфликтов обработки одних и тех же распоряжений, к примеру, деление по типу, направлению - снизу или сверху), а для продавана будут аналитики: организация, склад, клиент, номенклатура, клон. Итого грубый подсчет только по боту продавану может дать нам (складов 10, организаций 2, клиентов 4, поставщиков 4, номенклатур 2, клон 1): 2*10*4*2*1=160 уникальных комбинаций.

Отчетность из коробки:

• Графики по различным параметрам состояния оборудования 1С и SQL серверов
• Графики по различным аналитикам состояния сервисов 1С
• Время выполнения ключевых операций через Тестирование 3.0
• Использование встроенного Apdex
• Регистр замеры времени из тестируемой конфигурации
• Журнал регистрации
• Медленные запросы из Технологического журнала
• Блокировки из Технологического журнала
• Ошибки из Технологического журнала

Бонусы:

Отразим некоторые удобные моменты, которые мы выявили в процессе тестирования:

• Подход позволяет использовать значительно меньшее количество лицензий чем в при обычном режиме. И даже на уровне ПРОФ (ограничение до 500 пользователей) выполнить проверку возможной работы с параметрами КОРП.
• Время на подготовку и прогон минимально, достаточно в каждом сеансе запустить сервис WinAutoamionUI, а можно его вообще прописать в загрузку и все. Далее только жмем старт)
• Управляемость
  • Есть возможность через человеко понятные команды управлять ботами в группе, так и индивидуально, если хотите перейти на ручное тестирование
  • Можно управлять через специализированное АРМ
  • Возможна передача пакета команд через чат)
  • Можно получить статус состояния каждого клиента через чат или в общем    
• Настройка теста не зависит от  выбранной конфигурации
• Готовые сценарии библиотеки можно пере использовать для различных конфигураций имеющих одинаковые метаданные.
• Просто выглядит процесс доработки, удобный ide интерфейс, методика.
• Минимум кода, точнее его не нужно вообще писать)
• Поддержка запуска различных обработок, если не достаточно сценариев (если нужен код)
• Максимально приближенное моделирование к поведению системы
• Большой набор документации по анализу данных статьи на текущем ресурсе, вики проектов, видео уроки
• Сценарий нагрузочного тестирования
• Хранение настроек сценария в скриптах
• Гибкая настройка сценария нагрузочного:
  • выбор и указание клиентов-серверов для формирования нагрузки, 
  • выбор и формирование состава аналитик, заполнение их значений,
  • управление генерацией нагрузки
  • фильтры, информативность состояния
  • вы легко можете балансировать от ввода документов до создания отчетов и просмотра списков, меняя параметры целевой системы под тип работы в своей базе

II) Предварительный много поточный тест по нагрузке в фоновых заданиях

Мы решили выполнить быстрый тест — запуск серверных скриптов в фоновых заданиях. Этот тест прост, быстр и дает приблизительную картинку по результату нагрузки сервера. В качестве критериев сравнивалось время выполнения одинакового количества операций. 

Цель этого теста - определить процент снижения производительности СУБД Postgres от MS SQL.

Для этого теста была специально написана обработка, пример на рисунке ниже:

В рамках этой процедуры выполнялась загрузка документов, записей регистров в потоках, а также набор некоторых запросов в цикле. В итоге - Postgres в сравнении с MS SQL показал, что он медленнее от 10%-30%, а в среднем на 20%. Ниже приведена картинка некоторых результатов этого теста.

Граничное значение в 12 потоков выбрано, потому что это предельное значение при котором сервер еще работает. Ниже на рисунке видно что происходит во время теста с нашим сервером.

Текущие результаты выглядят довольно оптимистично, т.к. на целевом сервере СУБД использовалось 24 ядра. При переводе на открытую базу данных мы могли нарастить без проблем до 40 ядер, т.е. это падение вполне возможно компенсировать распараллеливанием. 

Движемся дальше и переходим к более сложному сценарию.

Почему нагрузочное тестирование запуском регламентных заданий не то?

Когда вы запускаете регламентное задание — вы фактически проверяйте сколько сервер держит регламентных заданий. Смоделировать такими заданиями поведение пользователя на клиенте совсем неблагодарное дело.

Использование сценариев поведения пользователей — более простой и точный путь для моделирования, который учитывает все изменения между клиентом и сервером, настройки и поведение форм элементов, списков, отчетов и др.

III) Замечания по выполнению тестирования с использованием клиентских приложений

Как происходит запуск нагрузочного теста?

1. Сначала поднимаются на машинах службы WinAutomationUI – можно вручную или в автозагрузку. Эта служба позволяет выполнить запуск виртуального помощника / бота с некоторыми начальными настройками. Также она отвечает за взаимодействие с API Selenium. В ручную открывается RDP соединение и запускается служба.
2. В АРМ управления нагрузкой выполняются команды запуска ботов на соответствующих машинах — это происходит автоматически с некоторым интервалом в 10-15 с.
3. Далее передаются команды инициализации модели поведения для каждого бота. Изначально машины не имеют специализации.
4. Запускается возмущение — начинают приходить команды на продажу и закупку товаров, база оживает. Чем больше ботов продаванов и снабженцев вступают в игру, тем больше других ботов начинают работу по обслуживанию вспомогательных процессов.
5. Смотрим графики, ждем запуска всех ботов. Можем еще повставлять палки в колеса поработать за джокера — запустить удаление помеченных, какой-нибудь регламент пересчета и посмотреть что произойдет. К примеру, при запуске удаления помеченных вовремя теста значительно увеличилось время тайм аутов (TTIMEOUT) и дедлоков (TDEADLOCK)

Ниже на рисунке приведено табло управления нагрузочным тестом. На нем есть возможность увидеть основные параметры ботов: текущий статус, PID, порт, компьютер (на котором запущен), тексты ошибок. Также через него выполняется массовые команды для передачи команд.

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

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

API 1C Automation UI не подходит для нагрузочного тестирования

Запуск первый!  Компания 1С уже отвечала о том, что 1С Automation UI не подходит для выполнения нагрузочного тестирования. Но мы решили еще раз посмотреть на сколько все тут плохо. У нас наработана большая библиотека сценариев под это API, и было бы довольно здорово использовать ее. 

Мы использовали три компьютера для запуска ботов (8 ГБ и 4 ядра под каждый), на каждом по 4-6 ботов. Запустили тест. Клиентские компьютеры загрузили процессоры почти в 100%  и сам сервер значительно просел. Мы не смогли понять что делает сервер при передаче данных по 1С Automaton UI (остается загадкой и по сей день), но это что-то существенно съедает ресурсы. Картинка на клиенте была наподобие той, что ниже:

Мы сделали вывод и еще раз подтвердили рекомендации компании 1С— нельзя тестировать нагрузку через API 1С Automation UI. Движемся дальше…

Будем работать через браузер на API Selenium. Сели и потратили время на создание и отладку тестовых скриптов, супер удачно что тут есть возможность использовать одинаковые блоки из библиотек ив результате за 7-10 дней мы справились с этим — получилось порядка 200 скриптов для библиотеки.

Далее нам пришлось  существенно доработать менеджер нагрузочного теста. Но, это все лирика и не относится к самому тесту.

Скорость выполнения операций нормируется сервером

В процессе тестирования предполагалось что небольшое количество ботов позволит достаточно нагрузить сервер, но столкнулись с ситуацией выравнивания нагрузки. Т.е. если один бот работает быстро — отрабатывает сценарий за 40 с, то при росте пользователей время выполнения будет расти до 50 с, 1 мин и т.д. Тем самым система можно сказать автоматически "балансирует" нагрузку увеличивая время операции в ответ на увеличение числа запросов / очереди к сервисам 1с и СУБД.

В результате очередь к сервисам 1С растет медленнее чем количество подключаемых ботов в начале сценария. При постепенной загрузке мощностей происходит постепенное снижение этого коэффициента.

Устойчивость сценариев для тестов

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

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

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

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

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

IV) Запускаем большую игру

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

При высокой нагрузке пользователей меняйте настройки кластера

Наконец, то мы перешли на боевой стенд. Начали тест. Я налил кофе и взял круасан. Ничто не предвещало проблем. Но через 10 минут нагрузка пошла вниз. На всех клиентах появилось сообщение — хост разорвал соединение.

Да, упал rphost.  В чем проблема? А оказывается, что он не держит более определенного количество активно работающих сеансов, по крайней мере версия платформы 8.3.16.

И действительно после обратного подсчета нагрузки (посмотрели какие настройки на текущем сервере) мы получили - что такая нагрузка обычно запускает 6-7 хостов. На тестовом стенде в рабочем режиме светился только 1 хост, который свалившись завалил всех клиентов.  

Мы изменили настройки кластера и изменили параметр количество соединений уменьшив в 4 раза по сравнению с первоначальными (по умолчанию).

Ниже приведены графики первого запуска на нашем стенде. В момент достижения 40% произошло аварийное завершение процесса rphost и все клиенты ожидаемо были сброшены.

График нагрузки 1С:

График нагрузки на СУБД:

Выводы: При нагрузочном тестировании управляйте настройками сервисов 1С.

Нагружаем тестовый сервер 350+ ботов и эквивалент  5000+ пользователей онлайн

Исходные данные:

• СУБД Server Linux Postgres 40 ядер
• 1С Server Windows 30 ядер.

Графики параметров RAS 1C и основные показатели:

• Число пользователей — идет резкий рост, стабилизация, когда все боты запустились
• Очередь захвачено СУБД и очередь время текущее — похож на график пользователей, т. к. отражает количество обращений к службам 1С и SQL сервера. В конце графика видны значительные колебания — они вызваны перегрузкой сервера 1С и СУБД, когда из-за роста нагрузки он снижает время обслуживания клиентов, слегка восстанавливается и по новой догружается. По методике оценки такая нагрузка эквивалентна 4000-5000 пользователей. Но работать на такой нагрузке не комфортно. Считаем что до уровня очереди 150 пользователей сервер более или менее справляется — итого это около 3000 пользователей онлайн.
• Средняя доступная производительность — она логично снижается в процессе рост количества пользователей и достигает порядка 50 единиц в самый пик нагрузки. Сервер жив и даже может работать. По нашему опыту при достижении показателей в 10-30 единиц — это практически мертвец. 
• Среднее время вызова сервисов 1С — это время на каждую операцию, идеально, чтобы она была как можно ближе к 0. На графике видно что это время достигает 2+ секунд. А это значит что на каждый запрос клиент будет ожидать эти самые 2 секунды. Это очень много. Посмотрите время на своих рабочих серверах.

График количества процессов

На графике количества процессов все понятно, с ростом нагрузки — растет количество. 

Нагрузка на сервере СУБД Postgres 

Как мы видим, то в районе 22:50 он достигает 80%, что соответствует очереди к сервисам в 150 ботов. Такая высокая нагрузка уже считается пограничной, при которой стоит задуматься о процессе оптимизации базы или увеличении мощности серверов.

Нагрузка на сервере 1C 

Как мы видим, то 1С сервер ведет себя достаточно неоднозначно, давайте посмотрим почему. Нагрузка растет до 80% при достижении времени в 22:40, немного держится и начинает снижаться. Во время снижения сервер СУБД начинает подходить к пику и теперь 1С начинает ждать ответов. Последний всплеск — это инициация завершения всех ботов.

График времени выполнения некоторых ключевых операций

На рисунке ниже приведено среднее время выполнения некоторых ключевых операций:

• Заказ на перемещение провести и закрыть
• Заказ клиента провести и закрыть
• Заказ поставщику провести и закрыть

Видно как вместе с нагрузкой растет время выполнения. В районе 22:40 мы видим сильный всплеск для документов "заказ на перемещение" и "заказ поставщику", в это время загрузка процессора на сервере 1С достигла 100%. И в конце графика в районе 23:00 видны всплески и далее идут сильные колебания - в это время когда сервер SQL уже находится в под неприлично большой нагрузкой в районе 100%. Мы достигли предельных возможностей сервера. Далее уже начинают сыпаться блокировки и происходят довольно сильные колебания.

Наиболее существенно видно рост нагрузки для документа «Заказ клиента», время выполнения операции с 10-15 с возрастает до 50-60 с. Он самый сложный с точки зрения выполнения проверок и движений, он заслуживает более серьезного анализа. И потом мы действительно обнаружили причину такого поведения — повлияла ошибка платформа 1С — Postgres, о ней мы писали в статье "Пример пошагового решения проблемы производительности на базе Postgres SQL с картинками".

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

Как мы увидели что в базе начались проблемы?

С точки зрения железа - видно по загрузке процессора до 100% и роста очереди к нему. Но при некотором значении система начала снижать нагрузку и появились биения. Что произошло? Ответ на картинке ниже:

Начали появляться блокировки «Dead Lock» и «Time Out Lock». В принципе этого достаточно для завершения выполнения теста. Их избежать можно было бы увеличив количество аналитик — организаций, складов, но согласитесь, что в реальной базе достаточное количество пользователей работают с одинаковым набором складов и организаций, кое-где может даже быть одна управленческая. Поэтому такое поведение очень похоже на реальную ситуацию.

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

Нагружаем тестовый сервер 200+ ботов 28 ядер и 2000+ пользователей онлайн

Исходные данные:

• Server Linux Postgres в 28 ядер.
• 1С Server Windows в 24 ядра.

График параметров RAS 1C:

График сервера 1С ниже

График СУБД Postgres ниже

График времени выполнения ключевых операций:

Нагружаем тестовый сервер 200+ ботов 40 ядер и 2000+ пользователей онлайн

Исходные данные:

• Server Linux Postgres в 40 ядер
• 1С Server Windows в 24 ядра.

График RAS 1C:

График сервера 1С

График сервера СУБД Postgres ниже

Графики времени выполнения ключевых операций:

Выводы:

Мы видим что дополнительное количество процессоров значительно снижают общую нагрузку на CPU СУБД, поведение системы более стабильное - виден запас по "мощности".

Одновременно по запасу мощности обе системы по СУБД выдерживают нагрузку, во втором случае запас больше.

Показательно также в данном случае сравнение графиков очередей к сервисам 1С — «Захвачено СУБД» и «очередь время вызова текущее». На первом они совпадают и в среднем достигают 100 единиц, а во втором случае очередь к СУБД меньше и в среднем находятся в районе 50 единиц.

V) Смотрим поведение на рабочей базе после переезда, делаем выводы

После перевода базы на новый сервер (работы были выполнены в начале 2022 года), мы получили ожидаемую картину нагрузки — сервер спокойно справлялся с возложенными на него задачами. В момент снятия графиков количество пользователей было в районе 1000 онлайн.

Графики 1С RAS:

График 1С:

Из графика видно, что запас прочности достаточно большой. Пик в районе 100% связан с падением одного из rphost и переброской всех пользователей на "резервные".

График СУБД:

Выводы:

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

2. Заявленные мощности были подтверждены как экспериментально так и практически после перевода системы на новую СУБД. Текущее оборудование держит успешно создаваемую нагрузку, виден явный запас по мощности. На самом деле в момент перехода можно было смело снизить количество ядер на СУБД до 28 и она также бы работала без сбоев. В текущей ситуации чтобы использовать существующие мощности можно дать рекомендацию в настройках сервера Postgres изменить параметры влияющие на распараллеливание запросов в сторону увеличения вероятности их использования, чтобы тяжелые отчетные запросы выполнялись быстрее и эффективнее. Рекомендация использовать чрезмерные мощности исходила из задачи максимально снизить возможные риски, для нас это был проект.

3. В результате проведения теста было определено, что подобная конфигурация системы способна выдержать кратковременную работу до 5000 пользователей онлайн, особенно если у пользователей будет смещен баланс работы в сторону оперативной деятельности. В случае наличия требований по просмотру отчетности,  то рекомендуется использовать механизмы распараллеливания нагрузки по подобию 1С акселератор. 

4. "Узкие" места в конфигурации ERP были обнаружены. Но не все, а только в рамках рассмотренных основных процессов. Однако, это практически не повлияло текущую на работу пользователей. Про это будет рассказано отдельно.

Резюме:

1. Перед процедурой нагрузочного тестирования выберите основные цепочки и операции, все включать как для сценарного тестирования не имеет смысла. 
   Тут можно привести принцип Парето  - 20% основных действий дают 80% описания поведения пользователей.  Они будут адекватно описывать нагрузку, но не все моменты. Часть моментов вам возможно придется исправлять в процессе работы пользователей на реальной базе. Мы рекомендуем для продуктовой базы сразу настраивать конфигурацию мониторинг производительности и следить за возникающими проблемами.
2. 1C Automation UI не подходит для тестирования нагрузки. 
   Это API создает излишнюю нагрузку на компьютеры клиентов и сам сервер, к тому же сама компания 1С присылала ответы на подобные запросы — что оно не предназначено для выполнения нагрузочного тестирования. И если, кто-то выполнял для вас подобные работы по тестированию на этом API, то этим результатам не следует доверять, а распечатки можно спустить в шредер и далее мусорное ведро.
   Мы для целей тестирования мы использовали и доработали Фреймворк «Тестирование 3.0», нагрузка формировалась в браузере через selenium драйвер.
3. Когда тестируете нагрузку обращайте внимание на настройки кластера. Неправильные параметры могут сильно исказить полученные результаты.
4. При выполнении тестирования обязательно ведите логирование основных параметров серверов, срервисов 1С, технологического журнала.
   Это позволит вам увидеть проблемы, взаимосвязи, оценить результаты после выполнения работ. Мы для этих целей использовали Фреймворк «Мониторинг производительности». К основным параметрам относим: 
   • нагрузку и очередь к ЦПУ;
   • очередь к дискам;
   • потребляемая память;
   • очередь к параметрам сервиса 1С «Захвачено СУБД» и «Очередь время вызова (текущее)», количество процессов, количество пользователей, среднее время вызова сервисов 1С, средняя доступная производительность.
5. По результатам нагрузки смотрите логи и ищите проблемные места.
   К примеру, по результатам нагрузочного теста можно посмотреть на параметры медленных запросов их план, чтобы оценить причины поведения и выполнить мероприятия по оптимизации. Это особенно важно если вы переходите с одного типа СУБД на другой.
6. Для нагрузочного теста не подходят «пустые» базы, наподобие демонстрационной базы от компании 1С. Потому что они не дадут адекватной нагрузки, не будут проявляться проблемы быстродействия запросов. Если вы только планируете переходить на 1С или в ERP, то стоит набить достаточное количество документов по разным процессам. К примеру, заказов клиентов оптимально должно быть не менее 100 тысяч. Обратите на это внимание — это очень важно.
7. Готовьтесь выполнять оптимизацию системы после перехода на СУБД Postgres. Не смотря на выполненные превентивные вопросы оптимизации до перехода, после мы были вынуждены исправлять в горячем режиме проблемные места. Часть из них была решена в течении первых двух дней с применением расширений, а оставшиеся мы вылавливали в течении двух недель. Ошибки были различные, но в основном из разряда описанные тут - "Распространенные ошибки разработчиков, приводящие к проблемам производительности". В следующей статье приведем актуальные и существующие ошибки для текущих версий ERP/УТ/КА (подписывайтесь будет интересно).
8. Делайте запас по нагрузке на пользователей в 20-30%. При анализе выдерживаемой нагрузки делайте обязательно запас по пользователям в районе 20-30% сверху, что позволит системе выдержать краткие перегрузки возникающие по разным причинам. Эта рекомендация следует из опытной эксплуатации различных систем.

Ссылки:

Ниже приведены ссылки на бесплатные инструменты, а также статьи по тематике вопросов производительности:

• Фреймворк «Тестирование 3.0»
• Фреймворк «Мониторинг производительности»
• Анализ проблем производительности по динамике мониторинга RAS 1C
• Мониторим производительность с помощью 1С RAS
• 5 простых шагов и 15 минут на разворачивание инструмента мониторинга проблем производительности базы 1С
• Фреймворк "Мониторинг производительности". Руководство пользователя
• Распространенные ошибки разработчиков, приводящие к проблемам производительности
• Пример пошагового решения проблемы производительности на базе Postgres SQL с картинками