Особенности нагрузочного тестирования 1С: Предприятие

Особенности нагрузочного тестирования 1С: Предприятие

Недавно мне подкинули интересную задачку: провести нагрузочное тестирование 1С: Предприятие. Раньше с таким не сталкивался, но что-то подсказывает, что со временем таких запросов будет всё больше. Импортозамещение шагает по стране, 1С всё глубже укореняется в бизнес-процессах, а значит, вопросы “почему всё тормозит?” будут звучать всё чаще.

Переход на решения 1C в связи с импортозамещением, определение пределов мощностей имеющегося оборудования и поиск «узких мест», которые можно оптимизировать – всё это непосредственные поводы для проведения нагрузочного тестирования. А если учесть, что медленная 1С — это почти традиция, то тестирование можно считать народным промыслом. Поэтому хотелось на этом примере разобраться со всеми тонкостями процесса.

Клиенты 1С: Предприятие

У 1С есть три клиента: толстый клиент, тонкий клиент и веб-клиент. Толстый клиент работает напрямую с кластером серверов 1С. Веб-клиент работает через веб-сервер, а тонкий может работать и так, и так. В этом посте расскажу про особенности, выявленные при попытке нагрузки веб-клиента и тонкого клиента.

Выбор инструмента тестирования

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

Так как и тонкий и веб-клиенты работают через веб-сервер, для их тестирования не обязательно использовать Тест-Центр, а можно воспользоваться более универсальными инструментами. Поэтому в этом проекте было решено не усложнять себе жизнь и использовать привычный Apache JMeter.

Авторизация

Первая проблема, с которой я столкнулся при создании нагрузочных скриптов, – авторизация пользователей. В ERP 1С Предприятие логин и пароль отправляются в зашифрованном виде. Какое именно используется шифрование учетных данных? Хороший вопрос… Ответ я так и не нашел. Соответственно, не получалось организовать авторизацию виртуальных пользователей. Поэтому для тестирования авторизацию пришлось отключить вообще. Добрые люди в комментариях, поделитесь, пожалуйста, вашим опытом решения этих проблем, если таковой есть! Возможно, ваш лайфхак спасёт не одну нервную систему.

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

Костыль? Да. Работает? Тоже да. Способ не самый элегантный, но иного на горизонте пока не видно. 

Особенности трафика или воплощение хаоса

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

Все действия в системе, как известно, осуществляются запросами POST. Трафик веб-клиента полностью состоит из JSONов, а вот трафик тонкого клиента по умолчанию сжимается в LZ4. С проблемой сжатого трафика тонкого клиента вроде как удалось справиться с помощью изменения настроек. После отключения сжатия трафик тонкого клиента становится таким же, как у веб-клиента, однако вместо JSON используются XML.

Помимо этого, каждый полученный ответ системы начинается с символа-спойлера "uFEFF". Это знак порядка байтов (BOM, byte order mark), стандартный для некоторых кодировок. Однако из-за этого символа в дальнейшем возникают проблемы при использовании экстракторов в JMeter. Поэтому все ответы нужно предварительно прочесать постпроцессорами, удаляя этот символ.

Корреляция

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

В трафике много GUID-параметров. Очень много. При этом одни и те же значения могут встречаться в разных местах в разных регистрах, поэтому, при их извлечении и последующем использовании нужно сохранять регистр.

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

Ну а вишенка на торте — это дата. Штатный тип данных «дата» в 1С, в отличие от таймстемпа, является количеством секунд, прошедших с начала нашей эры.

Выводы

Как видите, далеко не все проблемы получилось решить. А те решения, которые я нашёл, возможно не самые оптимальные. Так, хотелось бы найти способ авторизации виртуальных пользователей вместо отключения авторизации. И очень хочется как-то упростить и ускорить процесс корреляции запросов.

Расскажите, был ли у вас опыт нагрузочного тестирования 1С через JMeter? Как вы решали описанные проблемы?