Диагностика производительности Low-code решения. Как понять, где и что можно улучшить?

Текст выступления на конференции ELMA Day 2023 Алексея Пушкарёва

Зачем нужна диагностика и отладка?

• Поиск (локализация) ошибок при разработке;
  
  
• Проверка гипотез разработки;
  
  
• Тестирование при разработке;
  
  
• Оптимизация интерфейсов;
  
  
• Оптимизация серверных сценариев;
  
  
• Диагностика проблем производительности решения;
  
  
• Поиск ошибок в ходе эксплуатации системы.

Зачем нужна диагностика и отладка в low-code платформе?

Поскольку ELMA система не коробочная, нельзя всё внедрение свести к паре десятков настроек. ELMA — это полноценный инструмент разработки. А если есть разработка, то получается, что есть и ошибки. Значит нужен какой-то инструмент, чтобы мы их могли находить. Чтобы как-то протестировать наше решение, нам требуется проверять какие-то гипотезы. Проверять, наш код работает или не работает. Нужен какой-то инструмент, чтобы запускать код. Иногда мы уже сделали это решение, и оно запускается. Нам нужно посмотреть, насколько оно производительное, как быстро оно работает, а если оно не работает быстро, то понять почему. И здесь тоже нужны дополнительные инструменты. Собственно, для оптимизации и поиска этих проблем нам нужны инструменты отладки и диагностики. Кратко пройдёмся по всем этим инструментам, посмотрим и поймём, для чего они нужны.

Процессы. Отладка сценариев.

Начнём с процессов. И самый простой базовый инструмент, с которым мы столкнёмся, — это отладка функций. Он нужен для того, чтобы написанный нами сценарий можно было проверить на работоспособность. Для этого у нас есть в разделе редактирования кода сценариев Отладка функции.


По нажатию открывается окно, в котором указываем входной контекст, нужную функцию и смотрим, что на выходе.


Когда к функции всё не сводится и нам требуется отладить процесс целиком, мы используем инструмент по кнопке «Отладка» в конструкторе процесса. Рассмотрим его на примере процесса «Командировки». Данный процесс мы будем использовать по всей статье для примера. Суть процесса в том, что есть запрос на командировку, который мы запускаем на согласование. Создаётся задача на руководителя. Если руководитель согласовывает, то приходит один ответ, если нет, то другой ответ.


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


Когда процесс реализован и запущен в работу, мы можем исследовать его при помощи инструмента «Монитор процессов». В мониторе процессов мы можем видеть тоже самое, что мы видели в отладке, кроме исполнения задачи для любого пользователя. Но мы можем найти каждый экземпляр процесса, посмотреть, что с ним происходит, разобраться в ситуации, дать какие-то комментарии. Находится «Монитор процессов» в разделе «Администрирование».


«Монитор ошибок» – инструмент, позволяющий увидеть весь список проблемных ситуаций, прервать процесс, пропустить неудавшийся сценарий, также можем продолжить работу процесса. Продолжать процесс имеет смысл, если мы после определения ошибки в мониторе ошибок, исправим процесс и переопубликуем. Тогда для завершения работы процесса не придётся перезапускать процесс целиком.

Вывод отладочной информации


Каким образом можно выводить отладочную информацию? В самом простом случае мы можем использовать наш контекст. В нём завести строковую переменную и в неё писать некий отладочный лог. На слайде представлен пример.

Есть ещё дополнительные инструменты. Ознакомиться с более подробной информацией по ним можно в этих статьях:

• Использование Source IDE для отладки сценариев
  
• Записать текст/объект в консоль
  
• Поиск объекта категории
  
• Пример использования Storage
  
• Запись и получение данных из хранилищ Storage и cache

Отладка в консоле браузера – при работе клиентских приложений мы можем выводить отладочную информацию непосредственно в консоль браузера.

Отладка в storage или cache – для серверных функций, где нет интерфейса. Kуда мы можем посмотреть? Мы можем писать куда-то в storage или cache.

Отладка при помощи Postman, где мы можем запустить функцию и посмотреть результат.

Отладка интерфейсов.


Самый простой способ, так же как и в процессах, – это кнопка «Отладить». Выглядит он так же, как и отладка функции: нужно указать контекст и интерактивно поработать с формой.

Диагностика интерфейсов


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


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


Инструменты разработчика. Настройка.

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

Когда мы его включаем, появляется жучок в правом нижнем углу.


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

В нашем примере мы видим очень много запросов к серверной части. Обычно это бывает, когда мы делаем какой-нибудь поиск или запрос объекта в серверном скрипте в цикле.



Собственно, эта проблема у нас и появилась. Мы увидели, что сценарий написан плохо. Переписываем хорошо. Получилось сокращение времени на открытие в 30 раз, количество серверных запросов сократилось до 2-х. Это успех.


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

Инструменты разработчика для не разработчика

Логи мы читаем и анализируем.


Если удобнее визуальный интерфейс, то мы также можем эти логи загрузить в инструмент разработчика.

Отчёт о производительности.

Отчёт нужен, чтобы отследить, какие тяжёлые операции происходят в системе.

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

Что из себя представляют логи? Это excel документ со всем списком запросов, сколько раз обращение происходило к серверу и какое время они занимали. Отчёт также содержит информацию о том, как отрабатывают сценарии. Также мы можем посмотреть информацию по SQL-запросам. Средствами excel мы уже можем анализировать отчёт, фильтровать, сортировать, находить самую тяжёлую операцию.

On-premises. Тонкая настройка инфраструктуры.

К инфраструктуре мы относим:

- «Железо», ОС и сети;

- Контейнеризация (это наш Kubernetes);

- Базы данных и хранилища.

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

On-premises. Мониторинг

Мониторинг позволяет нам увидеть, как используются ресурсы. Настраиваем Prometheus и Grafana и работаем с ними. У нас есть замечательные статьи на эту тему.

On-premises. Системные логи

Наша система пишет для Администраторов логи. Это полезная информация для прочтения.

Трассировка.

Трассировка — это инструмент для того, чтобы провалиться в исполнение какой-то функции. Допустим, мы делаем какую-то функцию и в ней какая-то ошибка. Для того чтобы пройти её всю по шагам, существует инструмент трассировки. Он помогает найти узкое место, в которое мы упираемся, или найти какие-то ошибки в логике.

Для трассировки рекомендуем использовать Jaeger. С помощью него можно в первую очередь найти проблемные места. Можно задать критерии фильтрации, где можем указать продолжительность операций, которые мы хотим посмотреть, сервис, к которому мы обращаемся. Как правило, это будет main или processor. В результате, мы получим список интересующих нас операций.

Открыв конкретную операцию, мы видим таймлайн, как происходит выполнение всей функции. Есть возможность провалиться непосредственно в SQL-запросы. Тут нам открывается возможность оптимизации средствами Postgre. Можем добавить какие-то индексы или переписать сценарий, чтобы использовать кэш, чтобы не загружать лишний раз инфраструктуру и таким образом ускорить работу процесса.