Нагрузочное тестирование 1С на 10000 клиентов

Цели тестирования — проведение 10000 документов разовых начислений по 10000 подразделений, по одному на клиента. Тестирование являлось обязательным условием участия в конкурсе одной крупной организации. Для проведения теста был предоставлен стенд, доступ к которому делился между несколькими участниками посуточно, поэтому часть решений обкатывалось в 10 и более раз меньшем масштабе на отдельностоящем сервере.

Целью был как запуск в целом и демонстрация возможности систему работать с 10000 клиентов одновременно, так и выполнение операций проведения за приемлемое время.

Файлы проекта доступны в репозитории https://git.1oss.ru/roox/ps1ctest.git

Стенд

Для проведения теста заказчик предоставил блейд-систему, включающую в себя 6 хостов, со следующими общими характеристиками:

• 264 CPU, 553 GHz
• 3.18 Tb RAM

Хосты содержали по 44 ядра и немного различное количество оперативной памяти.

На изображении конфигурация одного из 6 лезвий блейд системы.

Виртуальные машины

Для виртуализации был применен кластер VMWare. В общей сложности удачной комбинацией оказалось 14 узлов РДП под клиентскую нагрузку, 2 сервера 1С, 1 сервер MSSQL, 1 сервер лицензирования и 1 управляющая машина. Вычислительные мощности и память были более-менее равномерно распределены между хостами с клиентской нагрузкой, за исключением серверов 1С и СУБД — они были мощнее остальных.

На SQL сервер было выделено 32 CPU и 650 Gb RAM памяти, на сервера 1С по 32CPU/320RAM и 44CPU/512RAM соответственно.

На изображении пример конфигурации одного из РДП-серверов нагрузки.

Непосредственно для запуска нагрузки было использовано 3 сеанса ОС, в каждом сеансе запускалось по 250 сеансов 1С (целевое количество подняли для себя до 10500)

Лицензирование 1С

Для проведения такого крупного нагрузочного теста требуются лицензии уровня КОРП, так как ПРОФ не дает возможности запускать более 500 сеансов к одной базе, а также была необходимость в увеличении числа соединений на рабочий процесс, которая тоже отсутствует у ПРОФ лицензий. Временные лицензии в количестве 11000 пользовательских и 2 серверных были предоставлены фирмой 1С для проведения теста и размещены в системе на выделенном сервере лицензирования.

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

Средства и инструменты

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

Проводить данный нагрузочный тест средствами Тестцентра было решено отказаться из-за некоторой неповоротливости и зависимости от самого сервера 1С. Соответственно, требовалась инфраструктура для нагрузки и инфраструктура для ТЦ, иначе при пиковых нагрузках точно были бы проблемы. К тому же из 1С недоступен ряд системных инструментов, которые необходимо применить. Было принято решение разработать и применить собственную систему, которая способна:

• Управлять клиентскими процессами в сеансе ОС, контролируя их состояние
• Централизованно сохранять сводные результаты тестирования, а также подтверждения проведенного теста
• Позволит применять любые системные средства управления процессами для распределения нагрузки

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

Start kill nice user! — концепция и структура

Такое название скрипта получилось со временем, за несколько итераций — 1) start-kill, 2) start-kill-nice 3) start-kill-nice-user

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

Концепция данного решения в простоте и применении базовых возможностей ОС для работы с процессами. Для простоты было решено использовать сохранение информации о ходе тестирования и дополнительной информации в файлы. Для размещения был выбран сервер, оставленный для управления, на нем была создана директория с ярким и говорящим названием C:\log и в ней размещены основные файлы и директории системы. Рабочая структура каталога выглядит следующим образом:

• full — в этот каталог раз в 5 минут сгружались снимки списков процессов ОС с каждого хоста под соответствующим именем. Эта информация могла потребоваться для выяснения деталей хода тестирования и набора нагрузки, но не потребовалась
• pids — содержит html страницы для каждого пользователя каждого узла со списком PID запущенных клиентов 1С
• raw — появилось немного позже и дублирует папку state по сути, по содержит немного другие файлы, используемые в построении простой таблицы из indextab.php, в которой виден общий ход теста по всей системе.
• state — каждый сеанс каждого узла писал краткую информацию о своей нагрузке в соответствующие файлы. Они содержат такую структуру:

"Time": "05/11/2021 00:07:26"
"Name": "rnd-srv-07_daemon1"
"Total memory used by 1cv8c": "22773564 Kb"
"Current active 1cv8c processes": "250"
"Average memory per 1cv8c process": "91094.256 Kb"
"Average execution time": "125.64 s"
"Maximum execution time": "97 s"
"Working process ratio": "0.976"
"PID error file count": "0"

• target — в этот каталог попадал такой же файл, как и в full, но единственный раз, в момент набора целевой нагрузки, перед запуском теста.
• Файл indextab.php — очень простая таблица, отображающая совокупное состояние тестов по каждому сеансу ОС (из файлов в каталоге raw) на одной странице

Запись в каталоги главного сервера экземплярами скрипта велась с помощью обращений по UNC именам к общей папке.

Также на каждом узле с нагрузкой присутствовал каталог C:\%HOSTNAME%\%USERNAME% для локальных данных времени набора нагрузки и выполнения. В него попадали сведения о текущих запущенных процессах сеанса, а также времени выполнения при тестировании и времени задержки перед стартом.

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

Способ набора нагрузки

При наборе нагрузки скрипт следовал определенному алгоритму. Процессы запускались по 3 штуки, скрипт ждал появления ПИД файла в локальном каталоге C:\%HOSTNAME%\%USERNAME%, это считалось знаком, что клиент запустился и стартовал следующий, то есть не более 3 запускающихся процессов в сеансе. После появления ПИД файла процессу назначался наименьший приоритет, а также выставлялось соответствие только самому последнему ядру процессора (в конце набора нагрузки, перед запуском теста, на сервере оказывалось 750 клиентов 1С, с наименьшим приоритетом, привязанных к единственному ядру). Это позволяло компьютеру не загибаться от нагрузки, создаваемой клиентами, а продолжать запуски новых и набрать всю требуемую нагрузку за приемлемое время, между 1,5-2,5 часами (пробный запуск 1000 клиентов на хосте без игры приоритетами длился более суток и ни к чему не привел).

Запуск набора нагрузки

Сжатые сроки сильно повлияли на автоматизацию управления тестированием — она отсутствовала. На каждом из РДП серверов размещался локальный файл скрипта, открывалось 3 рдп сеанса и в каждом стартовал powershell. Все вручную.

Но, при необходимости, управление тестом может быть автоматизировано с помощью ansible, другого скрипта или веб-страницы.

Запуск тестирования

Запуск нагрузки 1С происходил путем размещения пустого файла-флага C:\%hostname%\starttest. После того, как скрипт обнаруживал файл, он начинал изменять приоритет на нормальный и соответствие всем ядрам компьютера для тех клиентов, у которых задержка проведения завершится быстрее всего. После того, как такие «ранние» клиенты завершили работу, они вновь отправлялись скриптом на крайнее ядро системы с понижением приоритета, а следующие в очереди, с ближайшими задержками, получали приоритет и ядра. Таким образом создавалось своеобразное окно ресурсов, которое велось по запущенным процессам, упорядоченным в зависимости от величины задержки.

После появления файлов starttest на узле, клиент 1С переходит в активную фазу ожидания выполнения. Оно длится в течение задержки, которая была сгенерирована при старте и записана в файл. По истечении лага выполняется проведение документа, заполненнного на основании переданного 1С параметра запуска через командную строку. 11000 параметров соответствуют записям в регистре с параметрами документа, из которого заполняются реквизиты при создании документа и он проводится. После его проведения клиент 1С считается отработавшим.

Сразу после старта на странице indextab.php можно наблюдать ход набора клиентов:

Выполнение

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

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

Сводные результаты работы размещались на основном сервере, адрес которого был указан в путях, в скрипте. На этом сервере был установлен веб-сервер Apache и php, а также размещена простая страница, которая на основании файлов из папки с данными для веб генерировала таблицу с количеством сеансов, выработкой на узле (коэффициент от 0 до 1, отражающий долю успешно отработавших клиентов), а также максимальным и средним временем операции:

Доработки в конфигурации

В конфигурацию был добавлен модуль, дающий возможность проводить тест. Была добавлена подсистема, в которой осуществлялась выгрузка параметров из регистра с тестовыми данными, настраивались тайминги, а также присутствовала обработка контроля результатов теста. Ответ на вопрос как получить PID 1С из 1С не был найден, была взята из интернета и доработана под собственные нужды простая программа на С, выполняющая эту задачу. ПИД процесса 1С сообщался запущенным из 1С внешним процессом, это оказалось наиболее приемлемым способом решения задачи. При запуске клиент 1С генерировал себе задержку перед проведением, узнавал и сообщал свой ПИД и ждал появления файла-флага starttest, чтобы начать отсчет задержки, обновлять свой ПИД файл и провести документ, заполненный данными из регистра, которые получены с помощью параметра, переданного командной строке при запуске.

Итоговый запуск

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

Запуск клиентов, набор нужного количества. Запуск начинается очень бодро, но по мере набора нагрузки скорость набора клиентов уменьшается. При финальном проведении теста набор нагрузки произошел примерно за 2 с половиной часа.

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

Итог. Финальный тест занял примерно 35 минут, за это время было проведено требуемое количество документов, около 10500. За это время выполнились все клиенты, зависла и перезапустилась ничтожно малая их часть.

Доработки методики

При необходимости применить систему вновь, в ней с большой вероятностью будут произведены доработки. Помимо очевидных, наибольшее внимание будет уделено методике набора нагрузки и тестирования. Есть обоснованные предположения, что 3*250 клиентов на хост не лучшее соотношение, необходимо пробовать запускать больше сеансов ОС. Также время лага для разброса нагрузки при старте следует сократить вообще до 3-5 минут — из-за того, что машины оказываются очень нагружены, все происходит достаточно медленно и 3-5 минут на клиента по факту превратятся в 15-20. Эти предположения необходимо проверять. Также требуется тонкий тюнинг работы с окном приоритетов, в котором оказываются процессы, ожидающие выполнения в ближайшее время.