Оптимизация производительности

Первое правило оптимизации — не оптимизировать вслепую. Интуиция про «тяжёлые» места работает в разы хуже, чем тридцать секунд профиля: в реальных сервисах половина CPU уходит в сериализацию JSON и шифрование TLS, четверть — в базу, и только остаток делится между вашим кодом и роутером. Поэтому цикл всегда один: воспроизводим нагрузку, снимаем профиль, находим топ-функцию, правим одну гипотезу, сравниваем бенчмарки, фиксируем или откатываем. В Go этот цикл короткий, потому что инструментарий встроен: net/http/pprof вешается на порт двумя строками, go tool pprof читает профили, testing.B бенчмаркует функцию с счётчиком аллокаций -benchmem, а benchstat считает, значим ли выигрыш. Отдельно про цели: цифра RPS без указания профиля трафика и железа — не метрика, а хвастовство; реальные цели формулируются как «p99 меньше 200 мс на 5000 rps с долей ошибок 0.1%». И ещё: оптимизируйте на Release-режиме — debug-режим gin с цветными логами и подсказками искажает картину, а лишние логи на горячем пути делают хвост латентности длиннее, чем весь ваш хендлер.

У gin три режима: debug по умолчанию, release и test. В debug на старте пишется реклама фреймворка, дамп всех маршрутов и предупреждения вроде «set GIN_MODE=release in production»; в release всё это уходит, остаются только те логи, которые вы поставили сами. Переключение — gin.SetMode(gin.ReleaseMode) до создания движка или переменная окружения GIN_MODE=release: второй путь удобнее для продакшена, потому что один и тот же бинарник ведёт себя по окружению. Дальше логи. gin.DefaultWriter — туда пишет доступ-лог звена gin.Logger и дампы роутера; gin.DefaultErrorWriter — туда падают паники Recovery. На высоконагруженном сервисе access-лог в stdout на каждый запрос — это и CPU на форматирование, и диск, и конкуренция за мьютекс писателя: если логи собирает nginx или ingress, gin-лог можно отключить совсем — gin.DefaultWriter = io.Discard — и собирать метрики вместо текста. Третий пункт — Recovery и цвет: в release логи без ANSI-кодов, что радует любой централизованной системе сбора. Проверка режима — gin.Mode() возвращает текущую строку; на нём удобно ветвить отладочные звенья: в debug — подробный лог, в release — выборочная выборка. Помните предупреждение на старте — это тоже фича: если вы увидели его в проде, значит Release так и не включили.

Каждая аллокация — это работа сборщика мусора, а GC в горячем пути означает паузы и лишний CPU. Типовые дыры хендлера gin. Первая — map[string]any под видом gin.H: на каждый ответ строится хеш-таблица, каждая строка и число упаковываются в interface{} с боксингом на куче; готовая структура с json-тегами из урока про ответы сериализуется быстрее и проверяется компилятором. Вторая — fmt.Sprintf в горячем пути: для склейки строки из числа в десятки раз дешевле strconv.Itoa и конкатенация; Sprintf тянет парсер формата и рефлексию. Третья — слайсы без ёмкости: make([]T, 0) под цикл на десять тысяч элементов даёт десятки реаллокаций и копирований; заранее известный размер — make([]T, 0, n). Четвёртая — строки в цикле через += вместо strings.Builder. Пятая — замыкания и вызовы, которые вы не заметили: time.After в цикле аллоцирует таймер на итерацию, defer в узком цикле копит записи. Прицел на всё это — профиль кучи с опцией alloc_objects: он показывает не «сколько памяти лежит», а «сколько объектов родилось», и родившиеся — это и есть нагрузка на GC. Помните масштаб: пять аллокаций на запрос при 100 rps — мелочь, которую никто не заметит; пятьсот аллокаций на запрос при 5000 rps — уже гигабайты мусора в минуту.

Когда объекты дорогие и короткоживущие — буферы для рендера, энкодеры, временные слайсы — их можно не выбрасывать, а возвращать в пул. sync.Pool хранит набор объектов: Get отдаёт произвольный (возможно, свежесозданный через New), Put возвращает после использования. Выигрыш двойной: меньше аллокаций — меньше работы GC, и дорогая инициализация не повторяется. Три правила, без которых пул стреляет по ногам. Первое: буфер перед Put обязательно Reset — пул не чистит объекты, и следующий Get получит ваши старые байты вместе с новыми. Второе: пул не хранилище — сборщик мусора в любой момент может выкинуть содержимое, поэтому контракт «одолжил — вернул», а не «положил на потом»; данные нельзя терять при удалении из пула. Третье: возврат в defer, но после того, как данные скопированы клиенту: если вернёте буфер, пока io ещё читает срез — получите перезапись на лету. В самом gin пулы уже работают: внутренние буферы записи и парсинг multipart живут в пулах стандартной библиотеки, звенья вроде gzip-мидлвари держат пул своих энкодеров. Вашим кандидатам на пул — та же квалификация: горячий путь, дорогой объект, короткая жизнь. Пул на редкий путь — усложнение без выигрыша, а Reset-грабли добавятся всегда.

После аллокаций второй источник латентности — то, что выполняется на каждый запрос до и после хендлера. Роутер gin — radix-дерево из httprouter: матчинг быстрый, но статические маршруты дешевле параметров, а wildcard — дороже всего; на сотнях маршрутов разница всё ещё микросекунды, так что переписывать пути ради скорости не стоит. А вот цепочка звеньев — честные такты на каждый запрос: каждое звено вызывает c.Next, держит свои замыкания, пишет логи. Звено из урока про кастомные middleware, которое на каждый запрос лезет в базу за тарифом пользователя, стоит на порядке дороже самого роутера — кэшируйте или переносите в хендлер. Логирование из урока 08 на горячем пути — форматирование строк в никуда; в release его заменяет сэмплирование или метрики. Gzip — классический обмен: минус трафик, плюс CPU на сжатие каждого ответа; для JSON в несколько байт сжатие дороже доставки, для больших текстов — наоборот, и уровень компрессии подбирается замером. И не забывайте выборочность: звено rate limiting нужно на публичной группе, но не на внутренних health-чеках. Итог прост: производительность gin на практике — это аудит цепочки, а не замена фреймворка.

Инструментарий Go — главный аргумент против гаданий. CPU-профиль: go tool pprof снимает 30 секунд сэмплов с /debug/pprof/profile и показывает top — топ функций по времени, list — раскраску строк конкретной функции, web — граф вызовов; flamegraph с -http=:8081 интерактивнее списков. Профиль кучы: /debug/pprof/heap даёт две картины — inuse_space (кто держит память сейчас, для утечек) и alloc_objects (кто рождает объекты, для GC-нагрузки); их путать нельзя. Горутины: /debug/pprof/goroutine покажет, где они копятся — классическая утечка без ctx.Done из потоковых хендлеров. Mutex-профиль найдёт драку за лок, если под нагрузкой горутины стоят в очереди. Бенчмарки: testing.B гоняет функцию N раз, флаг -benchmem печатает аллокации на операцию; compare с benchstat отличает реальный выигрыш от шума — минимум десять прогонов. Нагрузка извне: hey или wrk дают честный RPS и распределение латентности, а не самонадеянный curl. Дисциплина та же, что у врачей: один профиль — одна гипотеза — одна правка — один повторный замер. «Оптимизировал сразу пять мест» — это значит, что вы не знаете, которое сработало.

Грабль первый — оптимизация без профиля: «кажется, map медленный» превращается в час переписывания рабочего кода, а узким местом был медленный SQL-запрос без индекса. Правило Knuth-а никто не отменял: premature optimization — корень зла, а профессиональная оптимизация — это профиль, а не вкусовщина. Второй — оптимизация не того слоя: переписывать роутер, когда 90% времени уходит в сериализацию, — классика; смотрите top -cum, он честно покажет, что gin отъедает проценты. Третий — мерить на debug-режиме с логами: цветной вывод на каждый запрос стоит дороже хендлера, и вы будете оптимизировать логгер. Четвёртый — бенчмарк на одной итерации: шум процессора, турборежим и соседние процессы дают разброс в десятки процентов; минимум десять прогонов и benchstat, иначе вы оптимизируете случайность. Пятый — забытый GOMEMLIMIT: контейнер с лимитом памяти без этой переменной ловит OOM-киллы, хотя runtime мог бы договориться сборщиком; поставьте на 85-90% лимита поды. Шестой — микробенчмарки вместо системных: функция стала в три раза быстрее, а RPS не сдвинулся, потому что она вызывалась на 0.1% запросов. Седьмой — оптимизировать то, что уходить должно: иногда честнее выбросить звено из цепочки, чем сделать его быстрее, и урок про статические файлы тут пример: отдачу статики на проде обычно выносят из gin в nginx или CDN, и никакой пул буферов этого не заменит.