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

16.05.22

База данных - HighLoad оптимизация

Тестируем ERP под Postgre SQL. Альтернативный нагрузочный тест.

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

  • понять, будет ли адекватно работать система на 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) Подготовка к началу тестирования:

 

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

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

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

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


Ссылки:

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

 

нагрузочный тест ERP мониторинг производительности

См. также

Автотесты для типовых конфигураций ERP Управление предприятием 2 и Комплексная автоматизация 2 (для vanessa automation)

Тестирование QA DevOps и автоматизация разработки Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Комплексная автоматизация 2.х Россия Бухгалтерский учет Налоговый учет Платные (руб)

Готовые тестовые сценарии, предназначенные для регресс-тестирования функционала конфигурации после обновления типовым релизом. Сценарии проверяют интерактивное заполнение форм документов, справочников и результат проведения документов. Сценарии возможно использовать как для vanessa-automation, так и для СППР. Поддерживаемые версии конфигураций ERP2 и КА2: 2.5.15.111.

2220 руб.

04.07.2022    6733    26    0    

23

Автотесты для типовых конфигураций Бухгалтерия предприятия КОРП 3.0 и Бухгалтерия предприятия 3.0 (vanessa automation)

Тестирование QA DevOps и автоматизация разработки Платформа 1С v8.3 1С:Бухгалтерия 3.0 Россия Бухгалтерский учет Налоговый учет Платные (руб)

Готовые тестовые сценарии, предназначенные для регресс-тестирования функционала конфигурации после обновления типовым релизом. Сценарии проверяют интерактивное заполнение форм документов, справочников и результат проведения документов. Сценарий – feature-файл, разработанный с помощью vanessa-automation. Запуск сценария выполняется интерактивно с помощью vanessa-automation или с помощью vanessa-runner в CI-системах. Доступно тестирование тонкого клиента. Поддерживаемые версии конфигураций 1С:Бухгалтерия предприятие 3.0 и версии КОРП: 3.0.144.49.

1728 руб.

20.01.2022    6594    10    0    

9

Анализируем SQL сервер глазами 1С-ника

HighLoad оптимизация Инструменты администратора БД Платформа 1С v8.3 Конфигурации 1cv8 Абонемент ($m)

Обработка для простого и удобного анализа настроек, нагрузки и проблем с SQL сервером с упором на использование оного для 1С. Анализ текущих зааросов на sql, ожиданий, конвертация запроса в 1с и рекомендации где может тормозить

1 стартмани

15.02.2024    7667    159    ZAOSTG    68    

96

Удаление строк из таблицы значений различными способами с замером производительности

HighLoad оптимизация Платформа 1С v8.3 Конфигурации 1cv8 Абонемент ($m)

Встал вопрос: как быстро удалить строки из ТЗ? Рассмотрел пять вариантов реализации этой задачи. Сравнил их друг с другом на разных объёмах данных с разным процентом удаляемых строк. Также сравнил с выгрузкой с отбором по структуре.

09.01.2024    6005    doom2good    48    

63

Опыт оптимизации 1С на PostgreSQL

HighLoad оптимизация Бесплатно (free)

При переводе типовой конфигурации 1C ERP/УТ/КА на PostgreSQL придется вложить ресурсы в доработку и оптимизацию запросов. Расскажем, на что обратить внимание при потерях производительности и какие инструменты/подходы помогут расследовать проблемы после перехода.

20.11.2023    8893    ivanov660    6    

76

ТОП проблем/задач у владельцев КОРП лицензий 1С на основе опыта РКЛ

HighLoad оптимизация Бесплатно (free)

Казалось бы, КОРП-системы должны быть устойчивы, быстры и надёжны. Но, работая в рамках РКЛ, мы видим немного другую картину. Об основных болевых точках КОРП-систем и подходах к их решению пойдет речь в статье.

15.11.2023    5117    a.doroshkevich    20    

72

Начните уже использовать хранилище запросов

HighLoad оптимизация Запросы

Очень немногие из тех, кто занимается поддержкой MS SQL, работают с хранилищем запросов. А ведь хранилище запросов – это очень удобный, мощный и, главное, бесплатный инструмент, позволяющий быстро найти и локализовать проблему производительности и потребления ресурсов запросами. В статье расскажем о том, как использовать хранилище запросов в MS SQL и какие плюсы и минусы у него есть.

11.10.2023    16201    skovpin_sa    14    

98
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. starik-2005 3033 16.05.22 10:41 Сейчас в теме
Отлично структурированная статья с кучей орфографических ошибок. Но это делу не мешает )
Krio2; it-expertise; awk; +3 Ответить
2. ivanov660 4332 16.05.22 10:43 Сейчас в теме
(1)Дописывал сегодня ночью. Часть поправил, спасибо за помощь.
it-expertise; +1 Ответить
27. Gilev.Vyacheslav 1910 16.05.22 17:48 Сейчас в теме
(2) в очередной раз статья убеждает что честный нормальный тест в фирме 1С не делают (только фикцию какую то) )))

нагрузка в 80% для 40 ядер это многовато, какие то ядра значит лежат под 100%, некоторые тормоза начинаются с общей загрузки в 50%

40 ядер для 5000 в реальности мало под типовую ЕРП, её надо либо сильно допиливать, либо более мощное железо подкладывать

и я всё жду когда кто то всё таки напишет нормальный ОБЪЕМНЫЙ тест, ведь при такой интенсивности блокировки вследствии террабайт базы будут большей проблемой чем железо с нагрузочным тестом

статья хорошая и полезная, особенно тем кто задают вопрос можно ли на постгрессе впринципе запустить толпу народу
Jimbo; GorkyGorod; Krio2; ivanov660; +4 Ответить
29. ivanov660 4332 16.05.22 17:59 Сейчас в теме
(27) Да, мало. При такой пиковой нагрузке работать живым людям практически не реально, время проведения увеличивалось в 10-15 раз, да еще и местами на блокировках отваливалось.
С Вашими цифрами согласен, подобное наблюдалось на стенде.
3. Константин С. 666 16.05.22 11:15 Сейчас в теме
Несколько узковато набок тестируемых задач.
Яб добавил в список хотябы открытие форм справочников/документов.
К примеру замечена проблема с ОС, открытия справочника на Postgres SQL (релизах 2.5.7.402 - 2.5.8.179).
4. ivanov660 4332 16.05.22 11:22 Сейчас в теме
(3)Вы видимо не читали статью или о чем-то другом. В рамках нагрузочного теста выполнялась полная имитация работы пользователей по ролям - методология описана тут Тестирование - игровое моделирование. Это включает в себя создание документов, работа с динамическими списками, АРМ, поиск в динамических списках, открытие отчетов, проведение, заполнение данными. Все по взрослому. И таких ролевых ботов в базу мы запускали в количества 350+. Если каких-то операций не хватает, типа всех кнопки нажимальщика, можно при необходимости добавить.
5. Константин С. 666 16.05.22 11:45 Сейчас в теме
(4)
а это от чем:
Сценарии процессов:
продажи — ***
перемещения — ***
закупки —***
аналитические отчеты —**
8. ivanov660 4332 16.05.22 12:26 Сейчас в теме
(5) Пример схему бизнес-процесса "продажи" можете посмотреть тут: пример создания сценарного UI теста для платформы 1С - БП продажи. Обратите внимание на дорожки для которых указан исполнитель.

Подобные схемы описания используются для двух других процессов. Что происходит, как создавались под них сценарии действий можете ознакомиться в видео-уроках (только в текущем случае используется API selenium): Видео-уроки по Фреймворку "Тестирование 3.0".
6. SerVer1C 749 16.05.22 12:00 Сейчас в теме
Класс!!! Хотелось бы увидеть результаты тестирования под более свежим (последним) Постгресом. Там же улучшена работа с временными таблицами.
7. ivanov660 4332 16.05.22 12:19 Сейчас в теме
(6) Работает значительно шустрее, по результатам перевода продуктовой базы на PG 14 в ERP часть проблемных запросов просто исчезла. Не только с временными таблицами, но и планировщик стал более умным.
Jimbo; shard; Krio2; PowerBoy; mrChOP93; m_aster; Gilev.Vyacheslav; dvissarov5; sapervodichka; SerVer1C; +10 Ответить
9. Pr-Mex 136 16.05.22 12:59 Сейчас в теме
(0)
Вы специально запускали клиентов в браузере, а не в тонком клиенте?
11. ivanov660 4332 16.05.22 14:28 Сейчас в теме
(9)
- API 1c Automation не подходит для выполнения нагрузочного тестирования,
- с Microsoft Automation UI и 1С управляемыми формами - честно утомился, уж очень "голые" объекты

И что остается? Selenium и веб браузер.
12. Pr-Mex 136 16.05.22 14:34 Сейчас в теме
(11)
Вроде уже были статьи про успешное нагрузочное тестирование, где использовался тонкий клиент и апи автотестов.
https://infostart.ru/1c/articles/1182048/
14. ivanov660 4332 16.05.22 14:57 Сейчас в теме
(12) Вы же рядом там где-то с 1С, спросите у них почему.

Я основывался на следующих фактах:

1. Нам был официальный ответ про то что это API не предназначено для выполнения нагрузочного тестирования. Когда мы пробовали выполнить работы, на наш вопрос почему сервер уходит в себя при такой незначительной нагрузке.
2. Я специально провел тест на машине (результаты которого описал), думал что-то изменилось на текущий момент. Но 6 клиентов буквально положили 4х ядерный 8 ГБ виртуальный сервер для формирования нагрузки, в момент когда началось активная работа. У меня создалось впечатление что каждый клиент отжирал по 10-20%. При переключении работы на Selenuim, мы легко смогли запустить до 12 клиентов.
3. К тому же у нас есть сервер для выполнения сборки релиза и он буквально под 80-90% процентов нагружается, когда идет сценарный тест по ролям, в нем запускается 10 клиентов под ролями.

В приведенной Вами статье:
- Я не вижу графиков нагрузки оборудования, не вижу графики параметров сервисов 1С. Это очень важно. Вообще нет ничего привязанного к временной шкале.
- Приведенный тест на 50 пользователей, это не о чем. В текущем ключе вы вполне можете не увидеть паразитной загрузки сервера взаимодействием в рамках API 1C Automation UI, а то что на клиентах греется воздух на это не обращают внимание.
- Есть отчет со значениями APDEX (время операции). Но вы учтите что эти 50 клиентов могут нажимать по очереди кнопки в течении 1-го часа. И показатели будут шикарными. Нет временного интервала.

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

Очень странно, что в сообществе почему-то считают что API от 1С, можно использовать в нагрузочном тестировании.
JohnyDeath; Gilev.Vyacheslav; +2 Ответить
15. Pr-Mex 136 16.05.22 15:04 Сейчас в теме
(14)
Я надеюсь, что вы понимаете, что трафик ходит разными путями для клиента тестирования как тонкого клиента и для клиента тестирования как web клиента. Если клиент тестирования запущен как web клиент - то трафик от менеджера тестирования к клиенту тестирования действительно будет ходить через сервер 1С.
Если клиент тестирования запущен как тонкий клиент не вижу проблем для запуска нагрузочного теста.
21. ivanov660 4332 16.05.22 15:37 Сейчас в теме
(15) Еще раз я изложил факты. Как работает именно это API, что оно передает дополнительно, я не разбирался и не вижу в этом смысла.
16. Pr-Mex 136 16.05.22 15:05 Сейчас в теме
(14)
Можно как-то посмотреть на текст "официального ответа"?
22. ivanov660 4332 16.05.22 15:38 Сейчас в теме
(16) Письмо поищу, а вы со своей стороны задайте этот вопрос, думаю вам быстрее ответят. Вдруг что-то поменялось.
39. ivanov660 4332 16.05.22 20:27 Сейчас в теме
(16) вот такой ответ пришел нам, запрашивали через коллег:

От компании «1С» получили официальный ответ: "что клиент тестирования и менеджер тестирования не предназначены и не проектировались под использование в нагрузочных тестах."

Может кто-то спросит у 1С еще раз - подтвердит или опровергнет данное сообщение. Я очень не люблю общаться с поддержкой 1С, только когда иного выхода нет.
shard; Gilev.Vyacheslav; +2 Ответить
10. evvakra 302 16.05.22 13:58 Сейчас в теме
Хотелось бы конечно более развернутого описания, почему Автор приравнивает работу 350 ботов к работе 5000 реальных пользователей.
Может есть какая-то доказательная база?
По моим расчетам, даже если взять Ваши слова за истину, то получится следующий расчет:
350 ботов = 5000 пользователей, т.е. 1 бот = 14 пользователей.
Почему далее по тексту статьи говорится про то, что 200 ботов это 2000 пользователей (хотя 200 *14 = 2800). Допущение в 30% это крайне не точная оценка.. Каким образом получена корреляция времени вызовов к количеству пользователей онлайн? Без этого понимания крайне сложно сделать корректную оценку результатов тестирования.
sapervodichka; +1 Ответить
13. ivanov660 4332 16.05.22 14:36 Сейчас в теме
(10) В самом начале привел описание и выделил жирным формулу, получается не совсем понятно ,поправим:

1. Критерий оценки - сколько пользователей сервис 1С может обслуживать одномоментно. Проще можно сказать так: 1500+ пользователей одновременно будут нажимать 50 клавиш и наши боты будут делать столько же нажатий. Поэтому можно считать что тесты эквивалентны.
2. количество обращений к сервисам 1С в ед. времени = количество пользователей онлайн * от 4% до 6%

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

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

Имеем очередь в 200 обращений -> 200/0.04=5000
26. Gilev.Vyacheslav 1910 16.05.22 17:41 Сейчас в теме
(10) если оценивать грубо, то для оценки работы субд такое упрощение приемлемо, там действительно будет соизмеримая интенсивность запросов
если оценивать приложения на толстом клиенте то тоже достоверно
если оценивать тонкий клиент, то упрощение не точно хотя бы потому что нет идентичных процессов типа быстрого поиска по полнотекстовому поиску, недостаточно много одновременных быстрых запросов по отрисовке форм и другие нюансы, но если нужно за вменяемые деньги получить хоть какую то картину для "начальной точки отчета" это всё равно наилучший вариант
вы же в фоновиках всё равно интерактивные операции идентично не сгенерите, а често стартовать 5000 клиентов это 5000 лицензий клиентских корп выложить надо, но и это не всё, по идее еще надо 40 терминалок, я таких практически не видел, поэтому в данном случае это разумный РЕАЛИСТИЧНЫЙ компромис
Krio2; sapervodichka; ivanov660; +3 Ответить
30. ivanov660 4332 16.05.22 18:07 Сейчас в теме
(26)Опять соглашусь.

Вопросы отрисовки и всякие сопутствующие служебные моменты учесть можно только запустив идентичное количество. И создавать полную модель - это очень затратно. Мы ограничились определенным набором действий, что было достаточно. Для учета этих отклонений накинули запас в 20%-30%.

Хоть текущая концепция и позволяет выполнить тест и с реальным количеством запущенных пользователей, добавить больший перечень операций, но думаю на это не пойдет и сама 1С.
34. evvakra 302 16.05.22 18:56 Сейчас в теме
(26)
Интересная ситуация будет когда клиент основываясь на данных прикидках построит свой продакшн, а по итогу из-за некорректно построенной системы потеряет десяток-другой миллионов.. реалистичный компромис может стоить вполне реальных денег…
При этом я не утверждаю что теория высказанная в статье некорректна, наоборот хочется объективного подтверждения что она корректна
36. Gilev.Vyacheslav 1910 16.05.22 19:11 Сейчас в теме
(34)
на вопрос корректности должен отвечать Заказчик
вы ему говорите - вот с упрощением тест стоит миллион, у него такие то риски
полностью идентичный со всеми терминалками, лицензиями и блэкджеком, когда в будущем код изменится риски тоже возникнут - 150 миллионов (и то с суммой я наверняка ошибся, сейчас лицензии и железо на такую толпу стоят больше)
вы какой вариант выбираете...
37. evvakra 302 16.05.22 19:21 Сейчас в теме
(36)
Конечно, такой разговор имеет место быть, когда стоимость рисков гораздо выше стоимости полноценного теста
17. grumagargler 723 16.05.22 15:15 Сейчас в теме
Спасибо за статью!

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

А можете ссылку дать? Дело в том, что мы успешно тестируем сотни тонких клиетов через 1С Automation UI, и на довольно старом оборудовании. Каждый клиент, отдельная маленькая виртуальная машина под линуксом.
19. ivanov660 4332 16.05.22 15:29 Сейчас в теме
(17)
Во-первых, я веду речь про нагрузочное тестирование.
Для сценарных тестов это самое то и удобное. Одно из лучших API.

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

Думаю, что мы выложим наработки в некотором будущем и можно будет проверить независимо эти выводы.
31. grumagargler 723 16.05.22 18:30 Сейчас в теме
(19) ...не понял на какой вопрос вы отвечали, я лишь спросил ссылку где 1с не реккомендует использовать их апи для запуска большого числа сессий. Если нет под рукой, не помните, речь вероятно идет о запуске _на одной_ машине десятков тест-менеджеров-клиентов?
38. ivanov660 4332 16.05.22 20:20 Сейчас в теме
(31)Может мы немного о разном. Тогда напишу так:
- от 1С ответов на вопросы с клещами и огнем не дождешься, честно меня такое общение напрягает и желания тратить время на подобную переписку все меньше и меньше;
- ссылок нет, но нет и подтверждающих обратное;
- можете запускать столько сессий сколько вам нужно, но мы столкнулись с тем на практике, что при запуске большого количества клиентов с несколькими тест менеджерами система начинает глючить - растет непонятная нагрузка на процессор, некоторые операции с памятью и что-то еще уже не помню.
Возможно вы на это даже не обращали внимание, не с чем сравнить, все равно на такую ситуацию может разные условия в окружении. Для нас при проведении нагрузочного теста - оказалось критично.
В рамках же запуска сценарных тестов - вариантов нет пользуемся и будем пользоваться.

Вот лог переписки с 1С, запрос делали через коллег:
За объяснением относительно аномально нагрузки на сервер приложений при эмуляции работы 10 пользователей обратились в службу поддержки компании «1С».
"От компании «1С» получили официальный ответ, что клиент тестирования и менеджер тестирования не предназначены и не проектировались под использование в нагрузочных тестах."
18. evvakra 302 16.05.22 15:22 Сейчас в теме
(13)
1. Так вот откуда взялась эта цифра, что именно 1500+ пользователей будут нажимать 50 клавиш одновременно? Может там активные пользователи и они за единицу времени нажимают 100 клавиш.. А при таком допущении получим двукратный разброс в результатов...
В таком случае тест получается ничем не информативнее чем "Стандартное нагрузочное тестирование" от Вендора. Но там хотя бы есть четкое понимание, как происходит пересчет "стандартных" пользователей в "реальных".. вот в этой статье: https://its.1c.ru/db/kip#content:46:1
2. Действительно, не хватает подробного описания как время вызова (текущее) превращается в очередь. Также идет подмена понятий, ведь в консоли администрирования кластера 1С есть как колонка "время вызова (текущее)" так и "время вызова сервиса (текущее)" какой именно показатель используется в формуле - вопрос.
20. ivanov660 4332 16.05.22 15:32 Сейчас в теме
(18)
По п.1 Не соглашусь с вами.
По п.2 Добавил информацию. Какой из показателей за что отвечает, я написал. Рекомендую брать первый. Отмечу что, всегда первый больше или равен второму. Подмены понятий нет, прочитайте статью, в которой я описываю что такое показатель очередь и как его считаем.
23. evvakra 302 16.05.22 15:58 Сейчас в теме
(20) Вы поймите, я задаю вопросы не спора ради, а чтобы понять достоверность указанных цифр. На чем они основываются - из статьи не понятно, увы... Ваше слово против моего.. Вы говорите что данная нагрузка характерна для 1500 пользователей, нажимающих 50 клавиш одновременно, а я говорю 50 клавиш одновременно в среднестатистической системе нажимают 3000 пользователей.. кто прав?
24. ivanov660 4332 16.05.22 16:45 Сейчас в теме
(23) Информации много, изложить детально каждый пункт довольно много текста получится. Попробую объяснить:

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

2. Делал замеры на разных серверах, к которым имею доступ, общался с коллегами и в разговоре получил информацию, что в других компаниях данная формула справедлива. Исходя из этого я делаю соответствующие выводы. Вы говорите теоретически, проверьте у себя, отпишитесь.

3. Компания, которую я рассматриваю среднестатистический пользователь ERP. По замерам на рабочей базе было установлено (я привожу графики), что для 1000 пользователей количество не нулевых значений в поле время вызова (текущее), в среднем (при работе в пике) каждый срез замера насчитывается 50-55 значений. Ночью, к примеру, этот показатель 2-3. В моменты отчетности или другие пики он может подниматься до 100 (злодей запустить удаление помеченных, завис rphost и т.п.).
50/1000 = 0.05 это 5%.

4. Действительно можно запустить и 10 000 пользователей, но все они ничего не будут делать. Или же запустить как я в тесте 350 пользователей и заставить их в максимально возможном ритме формировать документы. Или же выполнять обработку в потоках по загрузке документов, тогда вообще 12-20 пользователей положат сервер. Мы тут делаем акцент на статистике. На нашем примере, в вашем случае коэффициент может быть другой (об этом я упоминаю в ведении). Будет у вас коэффициент 0.5%, отлично можете при выполнении нагрузочного теста придерживаться его. Но важна цель выполнения, что вы пытаетесь решить: перевод на другую СУБД, оценку мощностей для роста компании, нагрузочное тестирования при разработке, что-то другое?

5. Тест центр мне не нравится, но мой "организм" не принял его. Как и "Сценарное тестирование".
kabanoff; Gilev.Vyacheslav; +2 Ответить
25. evvakra 302 16.05.22 17:22 Сейчас в теме
(24)
А, тогда все понятно, соотношение выявлено опытным путем. По-хорошему для каждой системы должно рассчитываться отдельно.
28. Gilev.Vyacheslav 1910 16.05.22 17:52 Сейчас в теме
(25) ну так то по вашей логике если нудеть, то не просто отдельно, а после каждой правки в код еще и снова пересчитываться, надо объяснять почему? )))
тут надо еще брать денежную составляющую, так сразу всё становится более четко
sapervodichka; +1 Ответить
32. evvakra 302 16.05.22 18:35 Сейчас в теме
(28)
Мы сейчас не рассматриваем денежную составляющую. Только точность расчетов.
Бесплатно можно посмотреть результаты тестирования сферической системы в вакууме на сайте завершенных проектов ЦКТП и примерно рассчитать необходимые ресурсы.
На мой взгляд, изюминка подхода, описанного в статье, как раз и заключается в том, что не нужно тратить большой бюджет на лицензии, а можно протестировать экстремальных пользователей(ботов) и через определенный, не взятый с потолка, коэффициент посчитать эквивалент нагрузки реальных пользователей. Поэтому и пытаюсь раскрыть эту тему в комментариях..
33. Gilev.Vyacheslav 1910 16.05.22 18:46 Сейчас в теме
(32)
(32)
Мы сейчас не рассматриваем денежную составляющую.
это ошибка 99% ИТшников
любые технические решения нельзя рассматривать отдельно от денежной составляющей, кто это не понимает, вынужден биться головой о реальность, получая фрустрации
35. evvakra 302 16.05.22 19:01 Сейчас в теме
(33)
Про экономическую составляющую как раз написал в (34)
47. ivanov660 4332 21.05.22 23:21 Сейчас в теме
(35) Данный тест был ничуть не бесплатный, а стоил достаточно хорошее количество денег. Даже выполнение всем известного теста Гилева стоит определенных "денег".
Т.е. хотите или нет, но бюджет перед выполнением проекта должен быть. И в зависимости от этого можете отталкиваться что сможете сделать, а что нет.
40. cdiamond 233 19.05.22 07:03 Сейчас в теме
Вопрос только зачем тестировать ERP без производства? Результаты будут ни о чём. Взяли бы уж УТ или хотя бы заголовок статьи не такой кликбейтный. В сценарии тестирования ERP критичен расчёт себестоимости, и на Postgres именно там и будут проблемы, плюс обязательно нужно многопользовательское тестирование во время расчёта себестоимости. К самой методике вопросов нет, расписано хорошо.
41. ivanov660 4332 19.05.22 09:11 Сейчас в теме
(40) Отвечаю на вашу критику:
1. ERP/УТ/КА - это одна и та же конфигурация, не знали?
2. Кто в здравом уме будет запускать расчет себестоимости при максимальной пиковой нагрузке, если только от безнадеги. Я не знаю, как на очень больших базах с ТБ это делают, но мы запускаем только на ночь и на выходных, иначе она даже может не запуститься. По обязательности наличия такого специфического теста я с Вами не соглашусь. Его обычно вставляют в различные проверки из-за того что нужно что-то выбрать и это очень тяжелая операция. Но ни разу не слышал, чтобы одновременно тестировали при этом нагрузку из пользователей.
3. У нас были определенные задачи тестирования, приоритеты, определенные ограничения по времени, во всех этих рамках мы выполнили тест. У вас возможно перекос со стороны производства, соответственно иные приоритеты и рамки и имеет смысл выполнять в комплексе с производством.
4. Чуть позже, думаю что мы выложим готовый инструмент по управлению нагрузкой, и все желающие смогут поиграться у себя. И даже поделиться с сообществом результатами, будет интересно ознакомиться.
42. cdiamond 233 19.05.22 09:17 Сейчас в теме
(41) Дело в том, что при использовании Postgres и хорошей детализации учёта ночного времени или даже выходных для расчета может не хватить, и придётся пользователям совмещать рабочее время с расчётом. Я такое уже проходил. Оптимизация и сокращение времени расчета может занять длительное время, а также имеет свойство резко меняться после очередного обновлениях конфигурации или платформы. Но производство результатов от эксперта ждать не будет, поэтому держать нагрузку система должна. Плюс существуют непрерывные производства или работа в 3 смены, про них тоже мало кто в 1С думает.
43. ivanov660 4332 19.05.22 09:36 Сейчас в теме
(42) Уточню мы проводили тест на определенной целевой базе. Ваша целевая база ваши условия, будет другой сценарий и другой тест.
1. В рассматриваемой базе себестоимость не поехала, просто не поехала вообще не считалась. Мы ее оптимизировали, стала 3-6 часов. В ночь укладывается. Поэтому не критично.
2. Еще раз разные целевые базы - разные сценарии.
44. JohnyDeath 301 21.05.22 22:24 Сейчас в теме
Отличная статья. Спасибо.
Возникло пару вопросов:
1. Почему тестирование проводили на платформе 8.3.16? На конец 2021 года (насколько я понял именно тогда и проводилось данное тестирование) это уже была достаточно старенькая платформа.
2. Вы могли бы сделать такие же тесты на, например, 21й платформе? Было бы интересно посмотреть как поменялась производительность в разрезе сервера 1с (многие пишут, что от релиза к релизу она падает)
3. Не очень понял какие настройки кластера были сделаны. Как настроены рабочие процессы и какие ограничения для них создавали? По количеству пользователей/по памяти?
45. ivanov660 4332 21.05.22 23:11 Сейчас в теме
(44)
1. Может вы удивитесь, но кое-кто сидит еще на 8.2. Т.е. какие входные условия от заказчика пришли, на тех данных и проводили тестирование. Это была реальная практическая задача, а не "just for fan".
2. Это конечно интересно, также здорово посмотреть как меняется производительность на этих платформах для версий PG 11,13,14 и MS SQL. На это требуется время, подготовка, проведение, ресурсы. Для теста нужна конфигурация с достаточным объемом данных, а тут, процедура выгрузки-загрузки базы под 1 ТБ, будет занимать практически сутки.
Как только появится достаточно времени и свободных ресурсов, то попробуем выполнить хотя бы часть. Попробую написать генератор данных для демонстрационной базы, это будет значительно проще, хотя и не так уже объективно.
Что-то падает, что-то лучше становится.
3. Как мы писали выше, то изменили количество соединений на хост от дефолтных - это где-то в 4-6 раз меньше. Для теста мы не ограничивали расход памяти, а управление оставили по производительности. Остальные параметры можно принять дефолтными.
JohnyDeath; +1 Ответить
46. JohnyDeath 301 21.05.22 23:19 Сейчас в теме
(45) 1. про релиз платформы теперь понятно. Требование заказчика. Хотя немного странное.
Вроде бы как раз начиная с этого релиза пошли массовые жалобы на платформу. Многие на 8.3.15 остались. Но тех, кто остановился именно на 16й версии по собственной воли не знал до этого момента.
48. ivanov660 4332 21.05.22 23:27 Сейчас в теме
(46) Уже нет, после детального исследования проблем работы этого релиза особенно с PG, то мы собрали силы в кулак и перевели, его на 8.3.19.
И это не самый плохой релиз. Вот к примеру, 8.3.17, пришлось экстренно откатывать обратно (на предыдущую). А так мы делаем очень редко и это после достаточно объемного тестирования и обсуждения с коллегами.
JohnyDeath; +1 Ответить
49. 2tvad 70 31.05.22 20:04 Сейчас в теме
Спасибо, очень интересно. А расскажите о дисковой подсистеме?

Я как то видел работу 1с на "обычном" рейде 10 и на дисках nvme. Разница была очень даже заметна.
50. ivanov660 4332 09.06.22 10:37 Сейчас в теме
Печально, картинки на инфостарте побились, придется поискать и передобваить.
51. user1854844 04.10.22 10:08 Сейчас в теме
А можете подробнее про ботов рассказать? как осуществлялся многопоточный запуск этих сценариев?
52. ivanov660 4332 04.10.22 11:20 Сейчас в теме
(51) В ближайшее время планируем выпустить несколько релизов Фреймворка "Тестирование 3.0" (конец октября, ноябрь), в которые должны войти доработки необходимые для выполнения подобного нагрузочного теста. Планировали выпустить раньше, но в связи с обстоятельствами вынуждены перенести сроки. Порядок будет следующий:
1. Сначала релиз обработки для формирования огромного количества цепочек, документов и т.п.. Это требуется для создания из демонстрационной базы пустышки, нормальной базы для нагрузочного тестирования.
2. Релиз менеджера ИИ в рамках фреймворка. Сделаем вторую обучающую статью. Как запустить на демонстрационной базе.
3. По отзывам пользователей, т.е. на основе обратной связи скорректируем планы.
53. fatman78 17 21.04.23 17:38 Сейчас в теме
Статья отличная!

1) В статье к сожалению ничего не нашел про дисковую подсистему стендов и характеристиках канала связи между серверами 1С и SQL. Можно узнать поподробнее?

2) Есть у вас информация (может быть в других ваших статьях) о степени влиянии на производительность при размещении связки 1С и SQL на одной машине и раздельно?
54. ivanov660 4332 21.04.23 22:27 Сейчас в теме
(53)
1. Сеть в 1Гигабит, диски SSD, под temp в VRAM
2. На одном сервере можете размещать, если народу мало. Для больших только раздельно.
3. Железо только серверное, если облако, то только выделенные сервера.
55. fatman78 17 21.04.23 22:54 Сейчас в теме
(54) Владимир, спасибо за оперативный ответ.
1. temp в VRAM - сервер 1С, верно?
2. "Для больших только раздельно." - применительно к ERP большие базы это сколько в попугаях пользователей всего/из них активных (в среднем)? Например если оперативы 200Gb на сервер.
56. ivanov660 4332 22.04.23 22:36 Сейчас в теме
(55)
1. temp VRAM для СУБД Postgres. Сам Postgres очень любит работать с большим количеством файлов, а 1С любит временные таблицы.
2. Уже большой базой можно считать количество пользователей от 400-500 онлайн, но как заметил Вячеслав, то конечно же зависит на сколько они там активно работают. Есть такой показатель - количество одновременных обращений к сервисам 1С, я про него писал ранее.
3. Критерий среднее количество на мой взгляд не корректно. Вот в рассматриваемой базе, днем пик в 10 часов 1000+, в 2 часа ночи 100. Средняя получается ~500. Но сервер рассчитанный на нагрузку в 500-600 пользователей, просто будет лежать в часы пик.
Оставьте свое сообщение