Claude Code для оптимизации производительности: как просить анализировать логи и профили, находить узкие места и делать безопасные правки без оверинжиниринга.
Оптимизация начинается с простого вопроса: что именно стало «дорогим» - время ответа, загрузка CPU, память, запросы к базе или ожидание сети. Пока вы не назвали метрику, вы лечите ощущение, а не проблему.
Ощущения почти всегда обманывают. «Страница медленная» может быть медленной только на одном типе устройства, только при холодном кэше или только в момент, когда база занята бэкапом. Поэтому сначала фиксируйте факт замером: что было, где, при какой нагрузке и в какое время.
Пользователь видит симптомы, а не причину: долгую загрузку, подвисания, ошибки 502/504, «крутилку» после нажатия кнопки. В мониторинге это обычно выглядит как рост p95/p99 времени ответа, всплеск ошибок, очередь задач, рост числа медленных SQL, увеличение потребления памяти или CPU.
Перед тем как просить Claude Code разобрать производительность, соберите минимум:
Иногда оптимизация не нужна. Если сервис упирается в лимиты, быстрее и дешевле поднять ресурсы, выставить таймауты и лимиты на запросы, включить кэш на чтение или добавить пагинацию. Хороший старт - убрать «дешевые» причины: лишние запросы, отсутствие индексов, N+1, слишком большие ответы и отсутствие кэширования там, где данные редко меняются.
Чтобы Claude Code нашел узкое место, ему нужны факты: что именно замедляется, как часто это происходит и где тратится время. Чем точнее входные данные, тем меньше риск получить советы в стиле «перепишите все».
Начните с логов, но таких, где видно время и контекст. Полезны строки с длительностью операций (обработка запроса, запрос к БД, внешний вызов), плюс идентификаторы, по которым можно склеить события. Если есть корреляция (request_id, trace_id, user_session_id) - добавьте ее, иначе картина будет рваной. Ошибки и предупреждения тоже важны: они помогают отделить «тормозит» от деградации из-за сбоев.
Дальше - метрики. Они показывают, единичный это случай или системная проблема. Для производительности важнее хвосты, а не среднее.
Обычно достаточно прислать одним блоком:
Если метрики говорят «болит», профили отвечают «почему». Для серверов чаще всего хватает CPU и heap профиля, иногда нужен профиль блокировок и ожиданий (lock, mutex). Для клиентской части полезны замеры долгих задач, рендеров и сетевых запросов. Для базы - план выполнения и статистика по самым тяжелым запросам.
Собирайте данные коротко и безопасно. Уберите персональные данные и секреты: токены, ключи, куки, номера карт, телефоны, email. SQL и payload лучше давать как шаблоны («WHERE user_id = ?») и сжатые примеры.
Рабочий формат: 20-50 строк логов вокруг проблемы, 5-10 метрик за тот же интервал и 1-2 профиля, снятых при нагрузке.
Пример: «в 14:05-14:15 p99 вырос с 400 мс до 2,8 с, RPS тот же, ошибок мало; в логах видно, что 80% времени уходит в запрос order_list; CPU-профиль показывает горячую точку в сериализации ответа». С таким пакетом Claude Code обычно предлагает точечные, проверяемые правки, а не оверинжиниринг.
Самый частый провал - попросить «ускорить» без рамок. Один и тот же симптом («долго отвечает») может быть проблемой БД, блокировкой в коде, нехваткой CPU или сетью.
Сначала задайте контекст:
Дальше опишите сценарий воспроизведения так, чтобы его можно было проверить: шаги, точка входа (эндпоинт, экран, фоновая джоба) и что считается нормой. Например: «ожидаю p95 < 300 мс, сейчас p95 1.2 с». Если проявляется не всегда - укажите частоту.
Артефакты давайте дозированно: небольшой фрагмент логов вокруг медленного запроса, один скриншот профиля или короткий текстовый экспорт, точечный кусок кода (10-40 строк), релевантный конфиг. Лучше 2-3 маленьких фрагмента, чем один огромный дамп.
Чтобы ответ был прикладным, попросите конкретный формат: 3-5 гипотез, какие сигналы в данных их подтверждают, и безопасные правки с минимальным риском.
Пример запроса:
Ты - помощник по производительности.
Контекст: Go + PostgreSQL, сервис в проде, 2 CPU/4 GB RAM, нагрузка 80 rps.
Симптом: эндпоинт POST /checkout, p95 вырос с 250 мс до 1.1 с.
Шаги: 1) добавить товар 2) открыть checkout 3) подтвердить оплату.
Ограничения: нельзя менять API и схему БД, релиз через 2 дня, риск минимальный.
Данные: ниже 30 строк логов вокруг медленного запроса + фрагмент профиля.
Задача: найди 3 вероятных узких места, покажи, какие строки/метрики на это указывают,
и предложи 2-3 точечных правки (с оценкой риска и как проверить эффект).
Перед тем как вставлять логи или профили, добавьте несколько строк контекста: что именно медленно (endpoint, экран, джоба) и какой порог вы хотите, окружение и примерный объем данных, что можно менять и что нельзя, какие риски недопустимы.
Ты - помощник по производительности. Проанализируй фрагмент логов ниже.
Задача: найти топ-5 операций/участков по (1) суммарному времени и (2) частоте.
Дай ответ строго в формате для каждого пункта:
Гипотеза -> Как проверить (конкретный замер) -> Точечная правка -> Риск/побочный эффект.
Уточни, если данных не хватает, но сначала сделай максимум из того, что есть.
Контекст:
- Сценарий: <описание>
- Цель: p95 <...>
Логи:
<вставь 200-500 строк, включая тайминги/trace_id/request_id>
Проанализируй CPU-профиль (flat/cumulative) ниже.
Найди 3-5 самых горячих функций и предложи вероятные причины (алгоритм, аллокации, блокировки, лишние преобразования).
Формат ответа на каждую функцию:
Гипотеза -> Проверка (какой профайл/счетчик/эксперимент) -> Правка (минимальная) -> Риск.
Профиль:
<вставь вывод профайлера>
Проанализируй медленные SQL-запросы и планы выполнения.
Цель: ускорить без изменения бизнес-логики и результата запроса.
Нужно:
1) определить, что именно дорого (seq scan, sort, join, фильтрация)
2) предложить безопасные индексы или переписывание запроса без изменения смысла
3) указать риск: рост записи, блокировки, регрессии на других запросах
Дай ответ: Гипотеза -> Проверка -> Правка -> Риск.
SQL + EXPLAIN (ANALYZE, BUFFERS):
<вставь сюда>
Если вы собираете приложение в TakProsto (типичный стек там - Go + PostgreSQL), укажите версии и вставьте профили или EXPLAIN как есть. Тогда советы будут ближе к реальным ограничениям и без лишних перестроек.
Чтобы не гадать, сначала определите класс проблемы. Узкие места почти всегда в одном из четырех мест: код, база данных, инфраструктура (сеть, диски, CPU, память) или сами данные (слишком большие объекты, неожиданный рост объема).
Дальше двигайтесь от симптома к проверяемой гипотезе. «Медленно только на некоторых пользователях» часто означает особые данные или редкий тяжелый путь в коде. «Медленно всегда и у всех» чаще указывает на неэффективный запрос, сериализацию, блокировки или перегруз.
Простой порядок:
Не просите «ускорить все». Лучше: «Вот 20 строк логов с таймингами и один профиль. Дай 3 гипотезы по слоям и для каждой - проверку на 15 минут (логирование, один SQL EXPLAIN, маленький эксперимент с кэшем)».
Если в логах время в БД прыгает, а CPU приложения низкий - начинайте с запросов и блокировок. Если время в приложении растет вместе с размером ответа - ищите большие JSON, лишние поля и повторную сериализацию. Если все «ровно», но бывают огромные пики - ищите редкий тяжелый путь и входные данные, которые его запускают.
Записывайте: метрика до, метрика после, что изменили, какой риск у правки. Так проще выбирать безопасные улучшения и откатываться, если что-то пошло не так.
Оптимизация чаще всего ломается на первом шаге: начинают менять код до того, как договорились, что именно считается «быстрее». Выберите одну базовую метрику и измеряйте ее в одном и том же месте. Обычно это p95 времени ответа, CPU на узле, длительность конкретного SQL или время рендера страницы.
Дальше нужна повторяемость: один сценарий, одинаковая нагрузка, те же настройки логирования и профайлера. Если сегодня тестируете «по ощущениям», а завтра по синтетике - сравнения не будет.
Процесс можно держать простым:
Мини-пример: p95 вырос с 220 мс до 900 мс на выдаче каталога. Профиль показывает время в сериализации JSON, а логи - рост размера ответа. Самая безопасная правка часто не «переписать все», а вернуть пагинацию, убрать лишние поля, ограничить глубину вложенности и проверить, что это реально снизило размер и время.
Правило простое: одна правка - одно измерение - один вывод.
Когда нужна скорость, начинайте с изменений, которые почти не меняют поведение. Так меньше риск багов и проще проверить гипотезу. В запросе к Claude Code полезно прямо просить маленькие изменения с понятными рисками, а не большую переделку.
Чаще всего выигрыш дает уменьшение лишней работы:
Параллельность тоже может помочь, но только когда нет зависимости от порядка. Если порядок важен, параллельные задачи легко дают редкие и неприятные ошибки.
Если узкое место в базе, самый безопасный шаг - уменьшить объем работы. Индекс часто помогает, но может замедлить записи и увеличить размер базы. Поэтому просите проверять: какие запросы выигрывают, что будет с INSERT/UPDATE, как изменится план.
Хорошая привычка в работе с Claude Code - требовать минимальный дифф и список побочных эффектов. Например: «Покажи патч только на 10-20 строк, объясни, что поменяется по памяти, по порядку выполнения и по нагрузке на БД, и как откатить».
Главная ошибка - чинить скорость «на глаз». Без baseline и контроля p95/p99 легко улучшить среднее время, но ухудшить хвосты. Перед правкой фиксируйте: что меряем, где меряем, сколько повторов и какие входные данные.
Вторая ошибка - начинать с переписывания архитектуры. Часто причина намного проще: лишний запрос в БД, неудачный индекс, сериализация большого JSON, повторная загрузка данных. Сначала ищите самый дешевый фикс, который можно откатить.
Третья ловушка - кэш «просто чтобы было быстрее». Без стратегии инвалидации и лимитов кэш быстро превращается в источник багов и утечек памяти. Если кэшируете, сразу ответьте: когда протухает и что происходит при переполнении.
Четвертая проблема - ускорить один участок ценой общей нагрузки. Можно уменьшить latency одного эндпоинта и при этом увеличить число запросов к БД или расход памяти так, что система просядет под пиком. Проверяйте не только latency, но и CPU, память, RPS к БД, количество аллокаций, размер ответов.
И еще: одному профилю верить нельзя. Профили зависят от прогрева, кэшей, фоновых задач и шума. Делайте несколько прогонов, сравнивайте, фиксируйте версию кода и конфиг.
Короткий анти-чеклист:
Не выпускайте «кажется, стало быстрее». Зафиксируйте цифры до и после: p50/p95, время рендера, длительность фоновой задачи, число запросов к БД, размер ответа. Цель должна быть простой: «p95 для /api/orders не больше 400 мс при 50 RPS».
Сравнивайте только одинаковые условия: та же инфраструктура, тот же профиль данных, та же нагрузка. Если «до» мерили на стейдже, а «после» на локалке - выводы почти всегда неверные.
Одна идея - один релиз. Держите план отката: фича-флаг, быстрый возврат предыдущей версии или понятный коммит, который легко отменить. Если вы разрабатываете в TakProsto, заранее сохраните снапшот и проверьте, что откат действительно возвращает поведение.
Оптимизация часто ломается не на «среднем» запросе, а на редких ситуациях. Проверьте большие входные данные, пустые значения, неожиданно длинные строки, а также параллельные запросы (пики, ретраи, одновременные клики).
Ускорение не должно приходить ценой роста ошибок или перегруза БД:
После роста пользователей страница «Заказы» в веб-приложении стала открываться за 6-8 секунд. Жалобы разные: у одних «белый экран», у других «список появляется, но без деталей». Сначала разделите проблему: фронтенд долго рисует, бэкенд долго отвечает или база не успевает.
Соберите данные хотя бы за 20-30 минут нагрузки (или за несколько минут в пике):
Дальше попросите разложить цепочку по шагам: «сеть», «API», «БД», «рендер». Обычно находится один явный пик. Пример: API отвечает 4.5 секунды, из них 3.9 секунды в БД, и выполняются 120 похожих запросов по одному заказу - это похоже на N+1. Или запрос один, но тяжелый JOIN и сортировка. Или профиль показывает много времени на сериализацию большого JSON.
Две маленькие правки, которые часто безопаснее больших переделок:
Убрать N+1: предзагрузка связей или один запрос с IN по списку id, чтобы сократить число запросов с 120 до 3-5.
Снизить вес ответа: вернуть только нужные поля для списка, добавить пагинацию (например, 50 строк), а детали догружать отдельно.
После правок повторите замер на тех же условиях и сравните цифры:
Зафиксируйте итог одной фразой: «p95 упал с 7.2 с до 1.6 с за счет устранения N+1 и уменьшения payload». Это помогает понимать, что именно сработало, и не уходить в оверинжиниринг.
Оптимизация перестает быть «героикой», когда у команды есть единый шаблон запроса и понятные артефакты. Тогда любые перф-фиксы становятся проверяемыми, воспроизводимыми и безопасными.
Минимальный набор для каждой задачи:
Дальше заведите привычку: любая правка производительности идет вместе с замером и коротким отчетом на 5-10 строк. Там достаточно указать, что мерили, что изменили, что стало лучше, какой риск остался и как откатиться.
Перед тем как кодить, просите режим планирования: разложить гипотезы по вероятности и стоимости и отдельно выделить «безопасные шаги» (уменьшение лишних запросов, ранний выход, батчинг, аккуратное кэширование) и рискованные (архитектурные переделки, миграции, смена хранилища).
Если вы делаете продукт через чат-разработку, TakProsto (takprosto.ai) удобно использовать для быстрых проверок гипотез: собрать небольшой эксперимент, зафиксировать состояние снапшотом и при необходимости откатиться через snapshots/rollback. Когда решение созрело, можно выгрузить исходники и продолжить работу в привычном процессе.
Начните с одной метрики и одного сценария. Самый практичный минимум: какой эндпоинт/экран тормозит, сколько секунд сейчас, какую цель хотите (например, p95 < 300 мс), когда началось и как воспроизвести.
Пока это не зафиксировано, вы оптимизируете «ощущение», а не конкретную проблему.
В большинстве случаев берите p95 (и добавьте p99 для контроля хвостов). Среднее время легко «красивое», даже если часть пользователей регулярно ловит длинные ответы.
Если проблема про стабильность — дополните долей таймаутов/5xx. Если про ресурс — добавьте CPU/RAM и очередь/коннекты к БД.
Дайте небольшой, но «склеиваемый» фрагмент: 20–50 строк вокруг медленного запроса/операции, где есть:
Без времени и корреляции логи превращаются в шум.
Минимальный набор на один проблемный интервал:
Этого обычно хватает, чтобы отделить «единичный случай» от системной деградации.
Профиль нужен, когда метрики уже показали «болит», и вы хотите понять почему.
Практичный выбор:
Снимайте при нагрузке и по возможности в несколько прогонов.
Дайте Claude Code рамки, чтобы он не уходил в переписывание всего:
И попросите формат: 3–5 гипотез → как проверить → минимальная правка → риск.
По умолчанию просите безопасные и обратимые улучшения:
Каждую правку связывайте с измерением «до/после».
Сначала проверьте, что именно «дорого» в плане выполнения:
Дальше — безопасный путь: EXPLAIN (ANALYZE, BUFFERS) → гипотеза → индекс/переписывание запроса без смены смысла → повторный замер.
Не забудьте риск индекса: рост времени записи и размера БД.
Кэш имеет смысл, когда данные читаются часто и меняются редко, и вы готовы принять небольшую несвежесть.
Чтобы не получить баги:
Если этих ответов нет — лучше начать с уменьшения payload и числа запросов.
Держите правило: одна правка — одно измерение — один вывод.
Перед релизом проверьте:
Если вы разрабатываете в TakProsto, удобно заранее сделать снапшот и проверить, что rollback реально возвращает прежнее поведение.