🧠 Как 3 вечера анализа и оптимизаций дали минус 1 CPU и +40% к скорости ответов API

👀 Всё началось с того, что я случайно (ну как случайно, проблема была всегда, просто я первый задался вопросом - "почему?") заметил, что один Python-сервис на staging потребляет до 2.5 CPU.
Для сравнения — весь namespace потребляет около 6 CPU. То есть один сервис ест почти половину ресурсов. И это при том, что это не какой-то нагруженные сервис, это синхронный API-сервис, да еще и без нагрузки, это же staging.

Стало интересно — а что там внутри вообще так жрёт?

📦 Запустил профайлинг CPU через Pyroscope и… понеслось.

UI у Pyroscope меня не устроил — флеймграфы красивые, но неудобные для глубокого анализа.
📥 Поэтому я выгрузил дамп как pprof файл и открыл его через go tool pprof.
Так мне удобнее, быстрее и информативнее.

📊 Профилирование показало несколько важных узких мест:

🧱 Проблема №1: конвертация данных из MySQL

Самое "жирное" место — conversion.py → MySQLConverter.row_to_python.
Это код, который конвертирует строки из БД в Python-объекты на каждый запрос.

Наиболее затратные конвертации:
- _DECIMAL_to_python
- _INT_to_python
- _JSON_to_python
- _DATETIME_to_python
- _STRING_to_python

✅ Решение:

📌 Использовал C extension у mysql-connector-python
Официальная документация: https://dev.mysql.com/doc/connector-python/en/connector-python-cext.html

📉 Результат:
- Минус 1 CPU
- До +40% ускорение некоторых endpoint’ов

🧠 Проблема №2: неэффективный Python-код

Пример: функция change_type, которая:
- делает кучу проверок в логике
- использует неэффективные структуры данных, например, list для поиска вместо set / dict
- обрабатывает сразу множество возможных вариантов логики, в зависимости от входных данных

✅ Решение:

📌 Переписал участок без изменения бизнес-логики:
- заменил структуры данных
- добавил ранние выходы
- убрал дублирующиеся проверки

📌 Cognitive complexity снизилась, временная сложность — тоже. Производительность выросла.

⚠️ Проблема №3: код, который не нужен, но работает

Профайлинг показал, что куча ресурсов уходит на код, который вообще не должен уже как год использоваться. Но код активно выполняется. WTF!?

🤷‍♂️ Функции вызываются, результат — пустой, но код исполняется. Причём часто и тяжело.

✅ Решение:

📌 Удалил мёртвый код, обновил импорты, подчистил зависимости.
📌 Поднял вопрос о полной деактивации этого кода и мы таки это сделали — ресурсы можно использовать лучше.

🐘 Проблема №4: Импорты. Много. Дорого.

Во время анализа я наткнулся на ещё одну тихую, но дорогую проблему — огромные ресурсы уходят на фазу импорта модулей в Python.

Конкретно — на _find_and_load, часть механизма импорта, который занимается поиском, загрузкой и инициализацией модулей.

📌 Почему это важно?
- Импорты выполняются на каждый старт сервиса.
- Чем жирнее и зависимее ваши модули, тем дольше и тяжелее проходит импорт.
- Это не всегда очевидно, но можно видеть в профайлинге: _find_and_load, _find_and_load_unlocked, _load_unlocked – вот это всё.

📊 У нас в сервисе модулей реально много.
Многое из них – просто "свалены в кучу", где-то грузятся тяжёлые зависимости. Да и сложная структура проекта вынуждает иметь большое количество импортов.
И, как итог, CPU тратится на то, что можно было бы стремиться избежать.

✅ Что с этим делать:
- Разделять модули по функциональности.
- Отложенные импорты (lazy import) – практика может применяться (но есть нюансы), если модуль нужен только в конкретной функции.
- Минимизировать зависимости и импорт только того, что действительно нужно.
- Следить за импортами в __init__.py — именно они могут тянуть за собой пол кодовой базы.

Следующий шаг: memory профайлинг. Pyroscope в нашей инфрастуктуре такое не умеет и нужно приседать, но надеюсь дойдут руки и до RAM.

Принесла вам чудесную серию рисунков — Franciszka Themerson, Science and Technology:

1. radio-astronomy
2. distillery
3. high voltage
и, внезапно
4. the tea break (британские ученые такие британские, даже если они польские художницы, перебравшиеся в Лондон в сороковом)