Производительность Fasthttp

Начнём почти дословно с того, чем закончили: «двадцать четвёртый урок — производительность Fasthttp: почему Fiber быстр, zero allocation и границы применимости. Логика прямая: сегодня мы поставили приложение на боевой сервер, завтра заглянем под капот движка, который этот сервер кормит — и поймём, за счёт чего fiber и выигрывает те самые бенчмарки, и на каких нагрузках быстрые пути fasthttp перестают помогать». Обещание исполняется в четыре захода. Первый — механика: что именно fasthttp переиспользует и почему на горячем пути не возникает аллокаций, которых не было бы у net/http. Второй — цена: значения, которые вы вытаскиваете из fiber.Ctx, живут ровно до возврата хендлера, и это следствие той же механики, а не каприз документации. Третий — измерение: fiber benchmark, который вы соберёте сами, и pprof, который покажет, куда уходит время и память вашего кода, а не движка. Четвёртый — границы: CRUD с походом в базу, стриминг больших тел и HTTP/2 — случаи, где смена движка не сдвинет ни миллисекунду. Канон курса остаётся при нас: инстанс на :8080, маршрут /api/tasks, конверт items, хендлер с c.JSON — теперь мы измерим и его тоже.

Прочитаем шапку fasthttp так, как её написал автор, дословно: «Fast HTTP package for Go. Tuned for high performance. Zero memory allocations in hot paths. Up to 10x faster than net/http». Три обещания, и первое — technical, а не рекламное: zero memory allocations in hot paths. Горячий путь — это код, который выполняется на каждом запросе: распарсить заголовки, найти маршрут, подготовить контекст, собрать ответ. У стандартного net/http каждый такой запрос рождает новые объекты: http.Request, http.ResponseWriter, буферы чтения — сборщик мусора честно прибирает всё это, но тратит на прибирание процессорное время. Fasthttp пошёл другим путём: объекты контекста, буферы заголовков и тел не создаются на запрос, а берутся из пула и после ответа моются и возвращаются туда же. Десяток раз быстрее — это на синтетике с мелкими ответами и keep-alive-соединениями, и к честности цифр мы вернёмся в блоке про fiber benchmark; важно другое: выигрыш рождается не из магии, а из отказа создавать то, что можно переиспользовать. У всякой сделки есть цена, и здесь она видна в названии пакета: fasthttp — это не net/http. Типы несовместимы, готовые http.Handler-middleware не подключаются напрямую, а HTTP/2 движок не поддерживает вовсе. За скорость платят экосистемой, и умный выбор требует понимать обе стороны весов — этому посвящён блок fiber vs gin.

Теперь цена zero allocation, и она записана в исходниках fiber v3.5.0 прямо. При старте приложения поле toString получает значение utils.UnsafeString — это конверсия байтов в строку без копии, через unsafe: строка, которую вам вернул метод контекста, не владеет своей памятью, она указывает в буфер соединения, который движок потом использует заново. Док-комментарий метода Params в req.go формулирует контракт дословно: «Returned value is only valid within the handler. Do not store any references. Make copies or use the Immutable setting to use the value outside the Handler» — значение живёт только внутри хендлера, ссылок не хранить, нужен хранить — копируйте или включайте Immutable. Комментарий к методу, возвращающему метод запроса, объясняет, что бывает с нарушителями: «an unsafe alias into the request buffer would be silently corrupted on connection reuse» — алиас в буфер соединения тихо портится при переиспользовании соединения. Тихо — ключевое слово: не паника, не гонка с детектором, а мусорные байты в чужом ответе, который вы будете ловить по дням. Отсюда и выход из сделки — поле fiber.Config.Immutable: его док-комментарий признаётся, что при true фреймворк «relinquishes the 0-allocation promise» — отказывается от обещания нуля аллокаций в отдельных случаях, — зато все значения контекста становятся честными копиями и переживают возврат из хендлера. fiber аллокации — это не враг, а параметр сделки: по умолчанию вы получаете скорость и отвечаете за дисциплину; Immutable — скорость чуть ниже, спокойный сон выше.

Первый урок курса положил сравнение на стол — теперь, под занавес, у нас достаточно словаря, чтобы сравнить по-взрослому, потому что выбор между движками — это fiber производительность против совместимости, и никак иначе. Gin стоит на net/http, а значит бесплатно получает всё, что стандартная библиотека накопила за пятнадцать лет: HTTP/2 и HTTPS из коробки, огромный парк готовых middleware в стиле http.Handler, httptest и httputil, профилировщик net/http/pprof одной строкой импорта, совместимость с прокси и service mesh, которые говорят по-настоящему современному HTTP. Fiber стоит на fasthttp: HTTP/2 движок не поддерживает, http.Handler-middleware не подключается напрямую — только через adaptor, и каждый мост между мирами стоит аллокаций, ровно тех, от которых мы уходили. В прикладном CRUD-сервисе разницы в скорости вы не увидите: узкое место — база и сериализация, о чём первый урок уже честно предупреждал. Правило выбора из практики: legacy-проект с http.Handler-наследством, потребность в gRPC-gateway, HTTP/2 или командной привычке к net/http — gin, и это не поражение fiber, а трезвый расчёт; новый JSON-API с высокой частотой мелких запросов, где профиль показал, что накладные расходы фреймворка реальны, — fiber оправдан. Синтетические бенчмарки, в которых fasthttp уходит вперёд в разы, описывают плечо «plaintext, крошечный ответ, keep-alive» — убедитесь, что ваше плечо именно такое, прежде чем делать вывод.

Синтетику вроде TechEmpower, где fasthttp-стеки штурмуют верх plaintext-таблицы, принимайте как описание верхнего потолка, а не вашего сервиса: там нет базы, нет бизнес-логики, а тело ответа — несколько байт. Ваш fiber benchmark должен мерить ваш хендлер на вашей машине, и у Go для этого есть штатный инструмент — тесты с b.N: тестовый урок двадцать первый подарил нам app.Test, который гоняет запрос через полный стек без сети, — идеально для замера, потому что убирает TCP-шум и оставляет ровно то, что вы хотите сравнить. Команда запуска — go test -bench=. -benchmem -benchtime=2s ./internal/handlers/: флаг -benchmem добавит колонки памяти, -benchtime удлинит прогон, чтобы цифры устоялись. Сравнение версий делает benchstat: он берёт два файла вывода, считает разброс и честно говорит, значима ли разница, — без него «стало быстрее на пять процентов» почти всегда шум. И последнее правило гигиены замера: гоняйте бенчмарки без соседей по CPU — контейнер с лимитами из деплой-урока двадцать третьего на перегруженном хосте даст разброс, при котором вы оптимизируете погоду.

Бенчмарк отвечает «сколько», pprof — «куда». Каноническая пара — CPU-профиль и профиль памяти, и в Go оба собирает пакет runtime/pprof, а готовые эндпоинты для них регистрирует net/http/pprof на DefaultServeMux. Здесь таится первая ловушка fiber-мира: ваш процесс — не net/http-сервер, и /debug/pprof сам по себе на :8080 не появится. Решение каноническое и признанное: поднять рядом крошечный net/http-сервер на отдельном локальном порту, где DefaultServeMux отдаст профили. Это не костыль, а гигиена: профилировщик не должен светиться наружу и грузить боевой стек — localhost:6060 слушает только свои, за nginx из деплой-урока его не выносят. Дальше — два рабочих приёма. CPU-профиль под реальной нагрузкой: go tool pprof собирает тридцать секунд выборки и показывает top, где flat — время собственной функции, cum — её же плюс вызванные. Профиль аллокаций: -sample_index=alloc_objects считает количество объектов, alloc_space — байты; первый находит «много мелких», второй — «мало жирных». flame graph (команда web или web в интерактивном pprof) покажет ширину стеков наглядно. И важная дисциплина: профилируйте под нагрузкой, похожей на боевую — профиль на пустом сервере честно покажет, что простаивание бесплатно.

Аллокации не бесплатны даже при нуле кадров: чем чаще выделение, тем чаще сборщик мусора выходит на работу, а его смены видны как хвосты задержек. Диагностика начинается с честного счётчика: runtime.ReadMemStats отдаёт NumGC, PauseTotalNs и HeapAlloc — нарисуйте их на графике рядом с RPS, и картина сборки станет видимой; GODEBUG=gctrace=1 печатает в stderr каждую сборку с её цифрами. Регулировок две, и они не равнозначны. GOGC задаёт, во сколько раз куча должна вырасти от последней сборки до следующей: дефолт 100 — сборка при удвоении; поднять — реже собирать и больше есть памяти, опустить — чаще и прожорливее по CPU. GOMEMLIMIT из Go 1.19 — мягкий потолок памяти процесса: GC старается не выходить за лимит, и это спасает контейнер с жёстким лимитом из деплой-урока от смерти по OOM; GOMEMLIMIT=GOGC, GOMEMLIMIT не заменяет, а ограничивает. У fiber есть и собственная ручка — поле ReduceMemoryUsage в конфиге, и его док-комментарий честен: «Aggressively reduces memory usage at the cost of higher CPU usage» — снижает память агрессивно, платя процессором, — и рекомендует включать, только когда сервер ест память на массе простаивающих keep-alive-соединений. Общее правило всех этих ручек одно: сначала уберите аллокации, которые профилирование назвало лишними, — крутить GC вместо исправления кода это поливать огонь бензином с соседнего ведра.

Честный финал разбора — карта мест, где fasthttp не даст обещанного. Первая граница — профиль нагрузки: если время запроса — это база и внешний API, накладные расходы фреймворка — проценты от общего, и никакой движок их не спасёт; fiber производительность выигрывает там, где плечо — мелкие ответы и много keep-alive-соединений: health-чеки, plaintext, метрики, лёгкий JSON-конверт. Вторая граница — большие тела: по умолчанию движок буферизует весь запрос в памяти, BodyLimit по умолчанию 4 MiB, а при больших загрузках это и память, и задержка; поле StreamRequestBody в fiber.Config включает стриминг — док-комментарий говорит, что хендлер вызывается раньше, когда тело больше текущего лимита, — но стриминг вынуждает вас самим следить за тем, что вы читаете. Соседняя ручка DisablePreParseMultipartForm: движок по умолчанию сам парсит multipart-форму — для огромных файлов это лишняя работа, и её выключают, чтобы разбирать форму вручную и лениво, как делал одиннадцатый урок с загрузками. Третья граница — протоколы: HTTP/2 не поддерживается, а значит webpush-приложения за современным CDN и gRPC-овер-HTTP/2 мимо; WebSocket живёт через hijack, как в шестнадцатом уроке, — это решено, но это исключение, а не правило. Четвёртая — экосистема: каждый http.Handler-мост через adaptor съедает часть выигрыша. Ни одна из границ не приговор — это параметры сделки; плохо только не знать о них до выбора.

Соберём урок в одну формулу. fasthttp производительность — это переиспользование: пулы контекстов и буферов, UnsafeString-конверсии, ноль аллокаций на горячем пути — и в обмен на это совместимость с net/http, HTTP/2 и ваша дисциплина не хранить ссылки на значения контекста. fiber vs gin — это не таблица бенчмарков, а выбор фундамента: экосистема и протоколы против скорости на узком плече. fiber benchmark — это ваш хендлер, app.Test, -benchmem и benchstat; pprof — это отдельный localhost-порт, тридцатисекундная CPU-выборка и колонка flat во главе решений; GC-ручки — GOGC, GOMEMLIMIT, ReduceMemoryUsage — последнее средство после чистки кода. Границы применимости переписали маркетинг: база и сериализация съедают выигрыш, большие тела требуют стриминга, HTTP/2 мимо. Честное слово про песочницу: ни fasthttp, ни fiber в браузерном интерпретаторе сайта не живут — runner-ов в уроках Fiber нет с первого урока, а интерактивы здесь quiz, predict, fill, order и флешкарты; бенчмарки и профили требуют локального тулчейна и нагрузки, похожей на боевую. Полный маршрут — на странице курса Fiber.

Следующий, двадцать пятый урок — финальный: итоговый проект «REST API заметок на Fiber»: CRUD, валидация, JWT, лимиты — готовое мини-приложение. Логика прямая: сегодня мы научились измерять и понимать движок, завтра соберём из двадцати четырёх уроков один проект, где слои, тесты, аутентификация и деплой-артефакты встретятся в одном main.go — и прогоним его от go mod init до curl через nginx.