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

Введение

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

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

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

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

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

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

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

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

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

1. Роль «Регистрация интереса по новому клиенту».

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

2. Роль «Регистрация интереса по найденному клиенту».

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

3. Роль «Написание ответа клиенту».

• Открывается входящее электронное письмо.
• На его основании создается и записывается ответ.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Значения APDEX:

Итоги

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

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

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

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

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