Нагрузочное тестирование 1С:CRM
Нагрузочное тестирование 1С:CRM

Нагрузочное тестирование 1С:CRM

21.02.2023
22 мин
1410

Введение

В этой статье мы делимся опытом проведения и результатами нагрузочного тестирования программного решения 1С:CRM. Нагрузочное тестирование производится для гарантии технологического качества системы. И мы, с учетом сегодняшних реалий, задались целью подтвердить качественную работу 1C:CRM с серверной частью на ОС Linux и СУБД Postgres.

В соответствии с методикой, технологическое качество это:

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

Мы изучим производительность как показатель, вызывающий вопросы в первую очередь. Были поставлены следующие задачи:

  1. На виртуальном «железе» под управлением ОС Linux и на СУБД Postgres проверить возможность одновременной комфортной работы в решении 1С:CRM 500 менеджеров по продажам.
  2. Выявить общие требования к аппаратной части и конфигурации серверов.
  3. Подготовить решение к нагрузочному тестированию на 5000 пользователей.

Подготовка тестовой среды

Составление сценария

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

Наш сценарий будет воспроизводить повседневную работу менеджера по продажам, включающую регистрацию клиентов и сделок, ведение переписки. Название сценария: «Работа с клиентской базой». Проработав вопрос с методистами, мы получили следующие роли (здесь и далее роли — это единицы работ сценария):

  1. Роль «Регистрация интереса по новому клиенту».
  • В мастере регистрации обращения создается новый клиент, заполняются основные поля «портрета», контактная информация.
  • Клиенту создается два контактных лица. Первый контакт делается основным для клиента.
  • По клиенту регистрируется сделка (документ «Интерес»).
  • На основании созданного интереса создается личная задача на текущего пользователя.
  1. Роль «Регистрация интереса по найденному клиенту».
  • В мастере регистрации обращения производится поиск клиента по наименованию.
  • На найденного клиента регистрируется сделка (документ «Интерес»).
  • В рамках созданного интереса планируется три взаимодействия с клиентом случайного вида (встречи, телефонные звонки и т. п.).
  1. Роль «Написание ответа клиенту».
  • Открывается входящее электронное письмо.
  • На его основании создается и записывается ответ.

Частота выполнения этих ролей была подсказана методистами и в среднем оказалась следующей:

Роль

Выполнений в час

Регистрация интереса по новому клиенту

2

Регистрация интереса по найденному клиенту

4

Переписка с клиентами

3

Роли содержат самые необходимые действия менеджера по продажам в 1C:CRM. Нам предстояло проверить, насколько окажется производительна система, если эти действия будут выполнять параллельно 500 пользователей с заданной частотой.

Встраивание Тест-центра

После определения сценария создаются средства для его исполнения в программе. Для этого необходим Тест-центр(v8.1c.ru/tekhnologii/tekhnologii-krupnykh-vnedreniy/korporativnyy-instrumentalnyy-paket/test-tsentr/) из комплекта «1С:Корпоративный инструментальный пакет». Он способен запустить сценарий на нужном количестве пользователей, проконтролировать его выполнение, собрать результаты и показать отчет. Сценарии тестирования создаются в нем с помощью тестовых обработок, где разработчик прописывает необходимые для нагрузки действия. Тест-центр можно встроить в тестируемую конфигурацию либо подключить к ней как расширение. Мы выбрали второй вариант из соображений удобства.

Сценарии тестирования в тест-центре 1C:CRM

Интерфейс подсистемы Тест-центра

Написание тестовых обработок

Программную логику необходимых действий мы описали в тестовых обработках. Как следует из логики ролей сценария, нам требовалось в процессе тестирования открывать формы различных объектов и заполнять их. Чтобы это реализовать, мы слегка изменили формы этих объектов, и теперь необходимые команды и обработчики стало возможно вызывать извне — из форм тестовых обработок. Мы внесли необходимые правки прямо в подключенное расширение Тест-центра. Дополнительно к этому, по логике теста требовалось производить поиск клиента и создавать ответ на письмо. Для этого мы сгенерировали в базе наполнение из 100 000 клиентов и 50 000 входящих писем.

Окно с тестовой обработкой в расширении Тест-центра

Тестовые обработки в расширении Тест-центра

После всех этих действий окончательно определился список ключевых операций теста:

Ключевая операция

Целевое время

Мастер регистрации обращения: Открытие формы

1,5 сек

Мастер регистрации обращения: Поиск клиента

1,5 сек

Мастер регистрации обращения: Создание интереса

1 сек

Мастер регистрации обращения: Создание клиента и контакта

3 сек

Мастер регистрации обращения: Создание контакта

2 сек

Клиент: Открытие формы

2 сек

Клиент: Запись в форме

1,5 сек

Интерес: Открытие формы

3 сек

Задача: Создание из интереса

1 сек

Взаимодействие: Создание из интереса

1 сек

Входящее письмо: Открытие формы

2 сек

Исходящее письмо: Открытие формы

2 сек

Исходящее письмо: Запись в форме

1,5 сек

Целевое время — это ожидаемое время выполнения операции, исходя из удобства и требований бизнес-процессов заказчика. Оно было подобрано с учетом мнения методистов о комфортном для пользователей времени выполнения операций. Эти значения понадобятся для объективного контроля производительности системы по методике APDEX(its.1c.ru/db/metod8dev/content/5807/hdoc).

Настройка тестового стенда

Мы сразу решили организовать тестирование на виртуальном «железе». Для достижения цели тестирования нужно, чтобы мы могли менять характеристики виртуальной машины по требованию. Мы выбрали российский сервис Yandex Compute Cloud(cloud.yandex.ru/services/compute), ориентированный в том числе на нагрузочное тестирование. Нам потребовались в облаке виртуальные машины следующих видов:

Машина

Описание

Сервер 1С

Компьютер с ОС Centos 7 и установленным сервером 1С:Предприятие 8.3.20.1710 с серверной лицензией ПРОФ

Сервер СУБД

Компьютер с ОС Centos 7 и установленной Postgres Pro Standart 14

Сервер лицензирования

Компьютер минимальной конфигурации для раздачи клиентских лицензий

Сервер мониторинга

Компьютер минимальной конфигурации с установленным сервером Zabbix для сбора и хранения логов загрузки оборудования

Управляющий компьютер

Компьютер для запуска и контроля тестирования, хранения дистрибутивов, вспомогательных и служебных данных

Нагрузчик

Компьютер с ОС WIndows и тонким клиентом 1С:Предприятие

Окно с виртуальными машинами в консоли Яндекс

Виртуальные машины в консоли Яндекс

Для начала мы настроили серверное «железо» для 500 пользователей в соответствии с рекомендациями(its.1c.ru/db/metod8dev#content:5810:hdoc) фирмы 1С:


Вид сервера

Процессор

Память

Диск

Сервер 1С

4 ядра

24 Гб

200 Гб

Сервер СУБД

12 ядер

64 Гб

1000 Гб

Эти параметры были определены в качестве отправной точки, поскольку реальные требования к оборудованию существенным образом зависят от логики, заложенной в конкретном решении 1С, и от характера нагрузки. Согласно правилам 1С(1c.ru/news/info.jsp?id=25491), 500 пользовательских сеансов и 12 процессорных ядер — это предел для лицензий ПРОФ, и за это ограничение мы не выходили.

В сервисах Яндекса скорость дискового накопителя зависит от его размера. Для SSD 1000 ГБ это будет 450 МБ/с, а для SSD 200 Гб — только 105 МБ/с. Что касается процессорных ядер, то мы выбрали Intel Ice Lake из доступных на сервисе платформ, это соответствует процессору Intel Xeon Gold 6338.

Окно с узлами сети Zabbix

Узлы сети Zabbix

Параметры кластера серверов 1С были оставлены по умолчанию, а сервера СУБД настраивались при каждом изменении параметров виртуальной машины согласно рекомендациям 1С(its.1c.ru/db/metod8dev/content/5866/hdoc). Также для тестируемой информационной базы был установлен запрет на запуск регламентных заданий, поскольку во время теста в системе должна присутствовать только исследуемая нагрузка.

Тестирование

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

Состояние теста по сценарию Работа с клиентской базой

Запущенный сценарий тестирования

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

Окно с равномерной загрузкой на процессор сервера 1С

Ровная нагрузка на процессор сервера 1С

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

  • процент загруженности процессора — не более 70%;
  • средняя длина очереди к диску — не более 2;
  • объем занятой оперативной памяти — не более 90%.

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

В-третьих, в ходе этих запусков предполагалось выявить и исправить ошибки в коде и архитектуре программы, приводящие к избыточным блокировкам, таймаутам и взаимоблокировкам. Для этого мы собирали технологический журнал 1С с событиями TLOCK, TDEADLOCK, TTIMEOUT. Также мы искали длительные вызовы сервера (событие CALL), длительные запросы и транзакции (DBPOSTGRS и SDBL). Но в итоге проблем параллельности на этом сценарии не обнаружилось. Пользователи работали, практически не создавая друг для друга ожиданий на блокировках. Также отсутствовали и необоснованно длительные события.

К финальному запуску теста мы подошли со следующей конфигурацией оборудования серверов:

Вид сервера

Процессор

Память

Диск

Сервер 1С

12 ядер

48 Гб

500 Гб

Сервер СУБД

12 ядер

24 Гб

500 Гб


Значения APDEX:

Ключевая операция

APDEX

Мастер регистрации обращения: Открытие формы

0,99

Мастер регистрации обращения: Поиск клиента

1,00

Мастер регистрации обращения: Создание интереса

1,00

Мастер регистрации обращения: Создание клиента и контакта

0,99

Мастер регистрации обращения: Создание контакта

1,00

Клиент: Открытие формы

1,00

Клиент: Запись в форме

0,99

Интерес: Открытие формы

0,98

Задача: Создание из интереса

1,00

Взаимодействие: Создание из интереса

1,00

Входящее письмо: Открытие формы

0,99

Исходящее письмо: Открытие формы

0,99

Исходящее письмо: Запись в форме

1,00

Итоги

Мы подтвердили возможность одновременной работы в 1С:CRM 500 менеджеров по продажам. Работа происходила по сценарию, включающему поиск и создание клиентов и контактов, регистрацию и запуск в работу сделок, переписку с клиентами. Итоговый показатель APDEX оказался близок к 1, что соответствует отличной производительности по шкале APDEX (значения от 0,94 до 1).

Также мы определили требования к оборудованию для программы 1С:CRM, необходимые для выполнения данного сценария на 500 пользователей. Реальные требования будут выше, поскольку на стенде не запускались регламентные задания и отсутствовала нагрузка от других возможных сценариев. Но необходимый минимум был выяснен.

Тем самым мы подготовили базу к следующему этапу — тестированию под нагрузкой 5000 пользователей. Оно выполнялось на следующем стенде оборудования:

Вид сервера

Количество

Процессор

Память

Центральный сервер 1С

1

40 ядер

512 Гб

Рабочий сервер 1С

2

10 ядер

32 Гб

Рабочий сервер 1С

4

16 ядер

64 Гб

Сервер СУБД

1

40 ядер

512 Гб

Нагрузчик

160

1 ядро

4 Гб

Нагрузчик

280

1 ядро

7 Гб

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

Ключевая операция

Целевое время

Среднее время

Мастер регистрации обращения: Создание интереса

1 сек

2,7 сек

Задача: Создание из интереса

1 сек

2,2 сек

Взаимодействие: Создание из интереса

1 сек

2,5 сек

Входящее письмо: Открытие формы

2 сек

3,8 сек

Исходящее письмо: Открытие формы

2 сек

3,4 сек

Исходящее письмо: Запись в форме

1,5 сек

3,9 сек

Но даже по лучшим результатам APDEX не выходит на оценку «хорошо» и «отлично». В настоящее время мы используем полученные результаты и продолжаем улучшать продукт для достижения целевых значений по основным ключевым операциям пользователей.

Есть вопросы по статье? Задайте их нам!

Рассылка «Новости компании»: узнавайте о новых продуктах, услугах и спецпредложениях

Посмотреть все рассылки «1С‑Рарус»

Поле не должно быть пустым
Электронная почта указывается только латиницей, обязательно должен присутствовать знак @, доменное имя не может быть короче двух символов

Посмотреть все рассылки «1С-Рарус»

Иконка «Предупреждение» Отправляя эту форму, Вы соглашаетесь с Политикой конфидециальности и даете согласие на обработку персональных данных компанией «1С-Рарус»

Заинтересованы в сотрудничестве?
Нужна консультация?
Свяжитесь с нами!