Проект 403843, вызывается эндпоинт, хотя на вебе его нет

Недавно (пару дней назад) я обновил продакшен, где поменял много разных процессов, и сегодня получил такую обратную связь от пользователей, что в какой-то момент система зависла, перестала работать на время, и, соответственно, не было отклика.

Я узнал, какое это было время, зашел в монитор, в мониторе вижу, что есть довольно большое время ожидания от сервера, и начал примерно в это время смотреть логи по ошибкам, и нашел, что вызывается Endpoint zpo_24, и ошибка из-за того, что парсится нулевое значение.

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

Но, что интересно, что данный блок в БП на вебе я удалил, протестировал, его больше нигде не было.

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

И как вроде бы, как-то пару раз я замечал, что вызывались Endpointы, которых уже не было в бизнес-процессах. Я не зафиксировал это, и сейчас как-то воспроизвести этот кейс не получалось.

Но есть вот такая гипотеза, что возможна такая ошибка, которая приводит к таким последствиям.

@Daniil_Savinyh Удалил ваш первый скриншот с логами: аккуратнее показывайте скриншоты логов, потому что там были авторизационные токены вашего пользователя. Если вы не используете API Protection с хранением сессии через сертификаты, то используя токен можно выполнять от вашего имени запросы.

Насчет вызова БП для которого Server Request блоки были удалены (если я правильно понял что вы удаляли вызовы на фронте)
Возможны две причины:

  • У пользователей закэшированная версия веб приложений в браузерах (самая вероятная версия). Если это происходит часто, возможно нам нужно пересмотреть настройки Cloudflare в части кэширования, хотя сейчас мы кэшируем только JS, CSS и статические ассеты.
  • Маловероятно: генерация веб приложения падает и используется старая версия в деплое. Это легко проверить добавив новые элементы или изменив что-то что можно увидеть.

По поводу производительности
Для запросов к БД на выбор данных все что больше 10-20мс это плохо. И тут может быть несколько причин:

  • Слишком много записей забирается из БД
  • Происходит полное/последовательное сканирование всей таблицы без использование индексов
  • Запрос слишком сложный для выполнения

Для отладки можно использовать EXPLAIN запросы в редакторе БД, результат вставлять в GPT и спрашивать был ли запрос выполнен оптимально или требуется накинуть индексы. И всегда нужно стараться минимизировать количество отдаваемых БД данных: меньше полей, лучше. Аналогично если вы используете SQL Exec и у вас есть вычисляемые поля, то лучше их сразу на уровне БД использовать.

Судя по скриншоту с логами, у вас есть кастомный запрос через SQL Exec который начинается с WITH free_lessons AS. Хорошо бы проверить, что он выполняется эффективно и не использует полное сканирование таблиц без индексов.

Про возможные причины зависания
Я вижу 3 возможные причины:

  • Мы в зависимости от подписки выдаем ограниченное количество подключений к СУБД. Для вашего плана это 5 коннектов к БД на приложение. Если запросы к БД выполняются быстро, то этот пул соединений работает без проблем для большого количества запросов. Однако, пока соединение занято долгим запросом или транзакцей оно не может быть использовано для других запросов. В теории если попадается 5 долгих запросов и свободных соединений не остается, то следующие запросы станут в очередь приводя к зависанию приложения. Вызов любого авторизованного эндпоинта начинается с проверки авторизации через БД и если нет доступных соединений к БД запрос просто зависает.
  • Большое количество нагрузки на CPU приложения. Случается очень редко, но плохо построенная логика может привести к большой нагрузке. У контейнера приложения ограничены ресурсы, как правило от 10% до 50% от одного ядра CPU в зависимости от подписки. Проверить в этом ли причина можно по графикам CPU в мониторинге. Дополнительно мы тоже можем заглянуть в собранную статистику по потреблению CPU.
  • Приложение зависает при достижении лимита по оперативной памяти. Это самый неприятный кейс, потому что точного решения у нас пока нет. Если приложение резко запрашивает больше оперативной памяти, чем доступно в контейнере то docker автоматически перезапустит контейнер. Запрос упадет, но все последующие будут работать корректно. Проблемы начинаются когда память почти полностью заполнена и запрос на выделение памяти не очень большой: встроенный в Go сборщик мусора пытается выкинуть все лишнее из оперативной памяти приложения чтобы разместить новые данные в память и не справляется уходя в бесконечный цикл. Основной симптом: память контейнера на 95%+ занята, CPU полностью занят. Мы делали несколько фиксов и такое стало происходить намного реже, но возможно все еще встречается.

Чтобы точно найти проблему нужно больше данных и наблюдений.

Хорошо, понял, спасибо

Да, все верно, удалял вызовы на фронте

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

После публикую повторно и изменения успешно вносятся

Для этого даже стал специально у себя в меню текстом писать версию приложения и при публикациях ее меняю и по этому как раз проверяю успешно обновилось или нет, но в привычку пока не вошло, не очень удобно особенно когда часто публикуешь изменения)

Недавно для себя открыл EXPLAIN и EXPLAIN ANALYZE стараюсь по ним проверять запросы

Сейчас как раз с учетом новых лимитов по блокам в БП активно все БП переделываю и перепроверяю

Спасибо за обратную связь, буду побольше наблюдать за периодом после обновления

Обычно тестирую на деве, все работает и публикую, мелкие правки всегда появляются и все проходит успешно, но похоже что под нагрузкой на продакшене с внедрением sql exec нужно поактивнее следить за монитором первый день-два за графиками)

Сейчас проект переопубликовал, лишние эндпоинты удалил, ошибок в мониторе больше не вижу, только с неавторизацией есть сообщения Message: “unauthorized”