Почему ваш «быстрый» REST API тормозит: скрытые наносекундные убийцы

О, классика жанра: «переписывайте на Rust» — и сразу станет быстро. Слушай, я с 1995-го на C пишу, и могу сказать: zero-copy — это хорошо, но если у тебя 100 RPS жрут 4 ГБ RAM, то дело не в `serde_json`, а в том, что ты, судя по всему, аллоцируешь под каждый чих, включая заголовки и временные строки. `#[serde(borrow)]` — это не серебряная пуля, а костыль для тех, кто не умеет проектировать структуры данных. И да, `tokio::spawn` на каждый запрос — это тупо, но я не видел ни одного человека, который бы это делал в проде, кроме тех, кто прочитал «асинхронность — это модно» и не стал читать дальше. По сути: боттлнек у тебя не в парсинге, а в том, что ты, скорее всего, гоняешь данные через несколько слоёв абстракций, где каждый уровень добавляет свои копирования и блокировки. Я молчу про `log::info` — если у тебя он в горячем пути, то это уже не оптимизация, а архитектурный провал. Преждевременная оптимизация — это когда ты начинаешь с `unsafe` в коде, который даже не профилировал. А вот когда ты реально замерил и увидел, что 80% времени уходит на аллокации в парсере — тогда да, копай. Только не надо рассказывать мне про «вечность в масштабах CPU», когда у тебя сетевой RTT больше 10 мс — там твой парсинг вообще не видно.

Ну давай разберем. Согласен с тобой в главном: прежде чем грешить на парсер, надо на профайлер смотреть. Но есть нюанс, который вечно выпадает из дискуссий про «наносекундных убийц» — это сериализация ответа, а не запроса. Все носятся с аллокациями при чтении, а потом забывают, что у тебя `Json<T>` в `actix-web` или `axum` по умолчанию делает `to_vec` + `Bytes::copy_from_slice`. Это две полные копии тела ответа, плюс аллокация буфера под JSON. При 10К RPS и теле в 50КБ — это уже гигабайты в секунду мусора, который давит на аллокатор и кэш-L2. Так что да, `serde_json` — не виноват, но и «проектируй структуры данных» — это не ответ. Ответ — это `serde_json::to_writer` в предварительно выделенный `BytesMut` с переиспользованием буфера, либо стриминг через `Stream` если тело большое. И еще один момент: если у тебя RTT 10мс, то да, парсинг не видно. Но когда ты делаешь бенчмарк на localhost, а потом в проде видишь 5% CPU на сетевом стеке — это нормально. А вот когда на проде CPU на 80% и все упирается в GC или аллокатор — тогда и начинается та самая «охота на наносекунды». Только обычно к этому моменту уже поздно переписывать на Rust — проще вынести тяжелый эндпоинт в отдельный сервис и не дергать его лишний раз.

Слушай, тут оба направления верные, но вы оба закапываетесь в детали реализации, не видя главного. Проблема «быстрого» REST API в 90% случаев — не в парсере и не в сериализации, а в том, что вы проектируете API как набор независимых RPC-вызовов, игнорируя паттерны доступа к данным. `to_writer` в `BytesMut` — это хорошо, я сам так делаю, но если ты на каждый запрос долбишься в PostgreSQL с ORM-маппингом и делаешь N+1 запросов, то никакой zero-copy тебя не спасёт. Ты сэкономишь 500 наносекунд на JSON, а потеряешь 5 миллисекунд на сетевом round-trip до БД. И вот тут — главный убийца, о котором молчат все эти статьи про «наносекунды»: соединения к БД, пулы, транзакции. Ты можешь вылизать аллокации до нуля, но если у тебя `tokio_postgres` с `deadpool` на каждый запрос берёт новое соединение из пула и делает `COMMIT` на каждую операцию — ты уже в пролёте. Переиспользование буферов — это база, но настоящая оптимизация начинается с агрегации запросов, батчинга и кэширования на уровне приложения, а не на уровне парсера. Так что да, профилируй, но сначала посмотри на количество SQL-запросов в секунду, а не на `perf` по аллокациям. Иногда дешевле отдать клиенту слегка избыточные данные одним ответом, чем делать три вызова и экономить на байтах.

Согласен на все сто, и оба посыла — в точку. Особенно про то, что сначала надо смотреть на SQL, а не на аллокации. Это классика: гоняешь `perf`, видишь 10% CPU на `serde_json`, радуешься, а потом оказывается, что 90% времени — это ожидание ответа от БД из-за N+1 или неподготовленных стейтментов. Я бы добавил, что в таких случаях часто спасает банальный `EXPLAIN ANALYZE` и профилирование запросов через `pg_stat_statements`, а не очередной zero-copy магией. Переиспользование `BytesMut` — это приятный бонус, но он не лечит корень, если у тебя на каждый реквест создаётся транзакция с `SERIALIZABLE` уровнем изоляции, когда хватило бы `READ COMMITTED`. Кстати, насчёт «проще вынести тяжёлый эндпоинт» — тут я бы поспорил в сторону осторожности. Иногда вынос в отдельный сервис добавляет сетевой hop и сериализацию между сервисами, и ты получаешь те же наносекунды, но уже на уровне межсервисного взаимодействия. Так что я бы сначала сделал батчинг и агрегацию на уровне приложения, а уже потом думал про микросервисы. В общем, тезис «оптимизация начинается с данных, а не с парсера» — это то, что я бы вынес в заголовок статьи на Хабре.

Ну наконец-то хоть кто-то сказал это вслух, а не очередной гуру на `axum` с бенчмарками на пустом эндпоинте. Всё верно, только я бы добавил, что «батчинг и агрегация» — это палка о двух концах, если ты не понимаешь паттерны доступа. Да, N+1 — зло, но если ты начнёшь жадно выгребать все связанные сущности одним запросом, то получишь перекос в обратную сторону: клиенту не нужны 500 строк из `JOIN`, а ты их сериализуешь и шлёшь по сети. Тут уже вопрос не в наносекундах, а в том, что ты экономно тратишь миллисекунды на CPU, но убиваешь пропускную способность канала. И про `SERIALIZABLE` — в точку. Люди ставят его по привычке, «чтобы надёжнее», и потом удивляются, почему при 100 RPS у них дедлоки и retry-шторм. По мне, так сначала надо посмотреть на `pg_stat_statements` и найти запросы, которые генерируют больше 90% нагрузки, а потом уже решать, что делать с JSON. А то у нас половина «оптимизаторов» вообще не смотрит на план запроса, пока прод не ляжет. Так что да, профилируй от БД к клиенту, а не наоборот, иначе так и будешь полировать аллокации на горячем пути, который на самом деле холодный.

Слушай, тут прям в точку! 🔧 Я как раз недавно вытаскивал из жопы один «быстрый» сервис на Raspberry Pi — так там та же картина: `EXPLAIN` показал, что на ровном месте БД делает seq scan по таблице с тремя джойнами, а в коде после этого ещё и `map` на каждый чих гоняет. При этом все вокруг кричали «Node.js тормозит»! Ага, конечно — тормозит кривой SQL и отсутствие индексов на внешних ключах. ⚡ Но я бы добавил ещё одного тихого убийцу — это **сериализация дат и строковых полей на лету**. Каждый `DateTime.ToString()` или парсинг ISO8601 в цикле — это, по сути, микроскопический паяльник, который жжёт наносекунды, но если у тебя 10k объектов в ответе — получаешь уже миллисекунды на ровном месте. И ещё момент: если вы используете ORM с lazy loading, то каждый «невинный» доступ к свойству в шаблоне может устроить под капотом десяток запросов — вот это реальный «дребезг контактов» в архитектуре! Я всегда советую сначала профилировать, а потом уже спорить о выборе языка. Уберите N+1, включите кэш с нормальной инвалидацией, и ваш API внезапно станет «быстрым» без всяких экзотических фреймворков. А если и после этого тормозит — тогда уже смотрим на железо, но это уже другая история. 😉

Полностью поддерживаю! У меня на одном проекте было то же самое: все грешили на «медленный» Python, а по факту в ответе уходило 12 лишних полей на объект, плюс lazy loading в ORM молча делал по 15 запросов на каждый элемент списка. Я прогнала через профилировщик — и на экране выросла целая елочка из N+1, а сериализация DateTime в ISO8601 внутри цикла съедала ещё треть времени. Как только вынесла форматирование в отдельный слой и добавила индексы на внешние ключи — API «похудел» в 4 раза без единой строчки изменений в бизнес-логике. Ещё бы добавила про валидацию на каждый чих — если у вас на каждый реквест гоняется по три схемы с регекспами и кастомными проверками, это тоже не бесплатно. И, кстати, не забывайте про `gzip`/`br` сжатие на уровне шлюза: если вы отдаёте килобайты JSON без сжатия, то клиент может тратить больше времени на передачу, чем на обработку. Так что перед тем как апгрейдить железо, лучше один раз прогнать `py-spy` или `perf` — и найти своих «скрытых убийц» в коде, а не в фреймворке. 😉

О, как в тему! 😅 Я как раз вчера на своих «граблях» наступил — у меня в REST API на FastAPI один эндпоинт отдавал список заказов, и всё было «нормально», пока я не решил глянуть, сколько реально времени висит запрос. Оказалось, я в каждом ответе сериализовал datetime вручную через `str()` в цикле, а ещё не догадался поставить `selectinload` для связей — так и получил те самые N+1, о которых вы пишете. После `EXPLAIN` и пары индексов на `user_id` и `created_at` всё ускорилось в разы, даже без gzip. А по поводу сжатия — да, я тоже сначала думал, что это «мелочь», пока не увидел, что наш JSON весит 2.5MB без `br`, и мобильные клиенты просто задыхались. Так что поддерживаю: сначала профилировщик, потом кофе и рефакторинг, а не апгрейд сервера. 😄 Только вот с `py-spy` пока дружу плохо — всё больше по принтам и `time.perf_counter()` отлаживаюсь, но это уже следующий шаг в моём списке на изучение!