Netpoll: пишем сервера, которые не умирают от нагрузки

https://habr.com/ru/companies/otus/articles/859964/

Небольшой обзор библиотеки Netpoll и гайд по использованию. Сразу отмечу, что статья хороша именно как обзор, а не как серьезный технический текст, т.к. автор статьи будто бы пытается нам её продать, делая громкие заявления, вроде таких:

Если вы уже успели поиграться со стандартной библиотекой net, то знаете: она классная... до поры до времени. Как только подключений становится больше тысячи, начинается боль: блокировки, миллионы горутин и изматывающее профилирование.

А вот Netpoll решает всё это за счёт асинхронности и низкоуровневого доступа к системе. Она использует epoll на Linux и kqueue на macOS

Это заявление весьма преувеличено — "низкоуровневый доступ к системе" через epoll/kqueue здесь подаётся как уникальное преимущество Netpoll, хотя стандартный runtime Go тоже использует netpoller с epoll/kqueue для эффективной работы с сетевыми соединениями, да и горутины в Go достаточно легковесны (~2KB), чтобы обрабатывать множество соединений при достаточной памяти. В общем, тысяча соединений - совсем не тот порог, где net начинает "задыхаться"

Но при этом сама библиотека Netpoll и правда интересна, пусть и для каких-то особых кейсов. Она предоставляет событийно-ориентированную альтернативу стандартному подходу Go с горутинами для сетевых соединений.
Ключевые особенности:

- Не создаёт горутину на соединение — ключевое, на мой взгляд
- Напрямую работает с epoll/kqueue
- Предоставляет zero-copy API для работы с данными — т.е. позволяет работать с памятью напрямую, избегая лишнего копирования

Реальные преимущества могут быть в специфических сценариях с очень большим числом соединений и строгими требованиями к latency. Но нужны конкретные бенчмарки - в статье их, к сожалению, нет.

Для большинства задач стандартная библиотека net + встроенный netpoller будут отлично работать, вопреки драматичным заявлениям в статье о проблемах после "тысячи соединений". Хотя, автор от части тоже это признаёт, вопрос лишь в границе этого разделения:

Но не всё так идеально. Если вы пишете простой REST API, Netpoll вам вряд ли нужен. Зато если у вас чаты, игровые серверы, вебсокеты или TCP-прокси — это для вас.

Сама статья скорее практическая — автор показывает, как настроить Listener и EventLoop, работать с nocopy API, создать клиент и настроить мониторинг через Prometheus.

————

В любом случае, автору статьи спасибо, что подсветил эту библиотеку и передал основную суть, а также за примеры использования. Раньше я с ней не сталкивался, так что было интересно ознакомиться ❤️

Буду рад, если кто-то поделится своими бенчмарками или опытом использования Netpoll в реальных проектах.

#networking #performance #netpoll

Готовим слайсы в Go: подробно о динамических массивах, строчках и ускорении

https://habr.com/ru/companies/yadro/articles/874480/

Ещё одна неплохая и очень подробная статья про слайсы с глубоким погружением.

Что разобрано:

- Внутреннее устройство слайсов и как растёт их capacity. Также затронут интересный момент про округление вместимости из-за особенностей хранения объектов в хипе, про который редко пишут

- Разные способы создания слайсов и когда какой вариант лучше (пустой слайс, make(len), make(0, cap) и т.д.).

- Передача слайсов в функции: по значению vs по указателю

- Работа со строками, конкатенация и оптимизации компилятора

- Подробный разбор bytes.Buffer vs strings.Builder и их особенностей

- Тонкости копирования при []byte → string и обратно

- Использование sync.Pool для переиспользования памяти — как не забыть "вернуть" объект в пул и почему со strings.Builder это не работает

- Сравнение разных способов конкатенации строк на больших и маленьких объёмах данных

И много ещё интересного.

Особенно порадовали бенчмарки в конце с неожиданными результатами — strings.Join() может работать эффективнее чем bytes.Buffer.

В общем, рекомендую к прочтению 👾

#performance #slices #strings #article

Как ускорить свой код с помощью системы непрерывного профилирования Perforator

https://habr.com/ru/companies/yandex/articles/875070

Perforator — это система непрерывного профилирования, которую разработали в Яндексе и недавно выложили в опенсорс. Да, проект написан на C++, а не на Go, но тут интересен сам инструмент, а не его исходный код.

Что интересного рассказывают в статье:

– Как работает Perforator и как его использовать
– Как интерпретировать результаты профилирования
– Как оптимизировать код на основе данных профилирования

А чем интересен сам Perforator:

- Система умеет профилировать как компилируемые языки (C++, Go, Rust), так и интерпретируемые (Python 3.12+)

- Поддерживает FDO (Feedback-driven optimization) — можно автоматически использовать профили для оптимизации новых сборок. По бенчмаркам даёт до 10% прироста производительности

- Интересная фича — профилирование по срезам для A/B-тестов через thread-local теги

- Можно использовать как распределённо (в K8s), так и локально вместо perf record

Из ограничений:

- Нужен root (CAP_SYS_ADMIN)
- Только Linux 5.4+ на x86-64
- ARM пока в разработке
- На больших хостах может съедать несколько GB RAM

————

Зачем мне это, если у нас в Go есть pprof?

Очень полезно смотреть, какие ещё бывают решения, хотя бы в образовательных целях, и не зацикливаться на чём-то одном.

А здесь можно глянуть визуализацию работы сервиса ✨

#profiling #performance #ebpf #opensource

Go планирует улучшить производительность в контейнерах (proposal)

GOMAXPROCS - это настройка в Go, которая определяет максимальное количество CPU-ядер, используемых для выполнения горутин параллельно.

В Go 1.25 разработчики предлагают встроить умный GOMAXPROCS, который будет учитывать ограничения контейнера (cgroup).

Сейчас Go автоматически устанавливает GOMAXPROCS равным всем логическим ядрам на машине, что создаёт проблемы в контейнерах, где доступно меньше ресурсов. Это приводит к неэффективной работе, проблемам с производительностью и троттлингу приложения.

Проблема актуальна для всех, кто запускает Go-приложения в контейнерах (Docker, Kubernetes), и остро стоит в окружениях, где на одной машине запускается много контейнеров с ограниченными ресурсами.

Сейчас разработчики решают эту проблему ручной настройкой через переменные окружения или используя библиотеку от убера. Новое предложение добавляет в сам Go автоматическое определение ограничений CPU из cgroups и динамическое обновление GOMAXPROCS при изменении этих ограничений.

🫥 Cross Join
⠀
#golang #performance #kubernetes #docker