680 миллисекунд.
Именно столько времени когда-то выполнялся один из запросов в базе на моем проекте.Для пользователя это казалось вечностью, а для сервера - огромной нагрузкой. Я разобрал план выполнения запроса, нашел узкие места, переписал логику, добавил нужные индексы и подключил кэширование в Redis.
Результат: 140 миллисекунд. Время отклика упало почти в 5 раз, а нагрузка на CPU серверов снизилась на 50%. Это лишь один из примеров моей работы за последние 4 года в коммерческой разработке. Я люблю именно такие задачи - когда нужно разобраться в сложной системе и сделать ее быстрее, стабильнее и надежнее.
Сейчас я нахожусь в поиске нового проекта. Мой стек: Python (FastAPI), TypeScript, PostgreSQL, Docker. Отдельное место занимает работа с AI: я строю RAG-пайплайны, настраиваю интеграции с LLM (OpenAI, LangChain) и довожу точность ответов моделей до 94%. Ежедневно использую AI-ассистенты для ускорения рутины, но никогда не доверяю им архитектурные решения.
Что ищу: Роль Backend или AI Engineer (Middle+ / Senior). Полностью удаленный формат. Команду, где ценят инженерное мышление и дают возможность влиять на продукт, а не просто "закрывать тикеты.
· вчера
Разбор плана выполнения часто показывает, что тормозит один запрос, а не вся база. Падение нагрузки на CPU на 50% хороший бонус.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён
· вчера
В точку, Максим. В 90% случаев проблема кроется в полном сканировании таблицы (full table scan) или N+1 запросах, спрятанных внутри ORM. Устранение этого «узкого места» меняет работу всей системы. Снижение нагрузки на процессор стало отличным бонусом!
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён