Привет, Хабр! Меня зовут Максим Вишняков, я ведущий разработчик в Axenix. За время работы я накопил обширные знания в части оптимизации, развития и поддержки различных решений на платформе 1С:Предприятие. В этой статье хотел бы рассказать об опыте оптимизации работы ERP-системы для лидера алкогольного рынка, который отгружает продукцию в режиме 24/7 и осуществляет огромный объем операций.
Вводные: базовый мониторинг как точка старта
Наша команда реализовала проект для одного из крупнейших производителей алкогольной продукции в России. Подробнее об этом рассказывали в предыдущем материале, посвященном оптимизации решения «1С:ERP.УХ + ПАП».
В рамках проекта была выстроена базовая система сопровождения, включающая как линии поддержки, так и инструменты мониторинга. При этом учитывалось, что на этапе внедрения невозможно заранее определить полный перечень метрик и аналитики, которые действительно понадобятся в работе. Поэтому изначально мониторинг был реализован в базовом, упрощенном виде, как страховочный механизм, позволяющий фиксировать ключевые показатели без значительных затрат на разработку и сопровождение.
Такой подход оказался оправдан. Только в процессе реальной эксплуатации, когда система начала работать под нагрузкой, стало понятно, какие именно аспекты требуют более глубокого анализа и развития инструментов мониторинга.
Хотя создание собственных инструментов мониторинга или обработки данных в ряде случаев может быть оправдано, наш подход заключался в том, чтобы максимально использовать встроенные возможности типового решения. Это позволило сократить затраты на разработку и сопровождение, а также обеспечить более предсказуемую и устойчивую работу системы. В БСП (Библиотеке стандартных подсистем) «1С» уже есть подсистема «Оценка производительности», которую мы и использовали.
Что это такое и как работает?
«Оценка производительности» — набор инструментов мониторинга: справочники для создания правил ведения замеров, регистр, или журнал для этих замеров, программная обертка для добавления мониторинга операций в коде, а также средства загрузки/выгрузки журнала и отчет для его просмотра. В качестве основного подхода к оценке производительности при этом используется методика APDEX.
Работает ли это? Вполне, но с оговорками.
APDEX сама по себе имеет ряд недостатков, что несколько ограничивает применение этой методики, а вместе с этим и всей подсистемы целиком. Однако она может быть использована без настройки целевого времени, оперируя исключительно абсолютными замерами. В таком случае «Оценку производительности» можно рассмотреть еще и как хороший базис для дальнейшего развития с учетом специфики вашего проекта.
Далее – иллюстрация того, как мы провели доработку инструментов мониторинга на проекте.
Развитие типового мониторинга производительности
По прошествии года с момента перехода на «1С:ERP», наша команда поддержки, сопровождавшая клиента, начала сталкиваться с жалобами со стороны пользователей: долгий запуск системы, медленный отклик интерфейса, длительное проведение документов – «все сломалось, сделайте что-нибудь и прямо сейчас».
Картину дополняло то, что группы поддержки и разработки не испытывали абсолютно никаких проблем с производительностью. Наоборот, возникало ощущение, что система работает даже быстрее обычного.
Как это часто бывает, внешне парадоксальная ситуация имела очень простое объяснение. Бизнес-пользователи подключались к базе через веб-сервер, в то время как технические специалисты – напрямую. Поэтому возникшая перегрузка веб-сервера, приводившая к замедлению для клиентов, оставалась незамеченной.
В таком контексте абсолютно не удивительно, что замеры времени, которые были реализованы для серверных операций, не показывали проблем. Здесь будет полезно уточнить, что замеры по времени запуска системы не относятся к исключительно серверным замерам и вполне могут косвенно указать на то, что клиент-серверное взаимодействие затруднено.
Кейс многому нас научил, и, помимо всего прочего, подсветил существенный недостаток замеров по «Оценке производительности», а именно - отсутствие источника подключения сеанса. Что мы с этим сделали? Добавили в наши отчеты по производительности немного сетевого контекста с помощью утилиты rac.
Эта утилита, в числе прочего, позволяет получить информацию о текущих сеансах информационной базы. Общий вид команды представлен ниже. В качестве результата возвращается таблица с достаточно большим количеством данных, но нас в первую очередь интересовали лишь несколько: номер сеанса, хост и ip-адрес подключения.
Что можно сделать с этой информацией? Вполне очевидную вещь – сопоставить сеансовые данные из rac с нашими замерами времени и тем самым дополнить их сетевым контекстом. Техническая реализация здесь может быть самой разной, самый простой вариант – периодически сохранять сеансовые данные из rac в регистр и далее сопоставлять с замерами времени на этапе формирования отчета.
В итоге оценка производительности системы становится более прозрачной. Также система в целом обогащается данными об источниках подключения к информационной базе. Ниже представлен пример отчета, который может быть сформирован в результате описанной доработки.
Старт с простых, встроенных средств мониторинга позволяет быстро получить рабочую основу без избыточных затрат. Дальнейшее развитие (добавление контекста, расширение аналитики, учет инфраструктурных факторов) происходит по мере накопления реального опыта.
В результате мониторинг становится не просто инструментом диагностики, а полноценной частью архитектуры решения, обеспечивающей его устойчивость и масштабируемость в условиях круглосуточной нагрузки.
