Netpoll: пишем сервера, которые не умирают от нагрузки
https://habr.com/ru/companies/otus/articles/859964/
Небольшой обзор библиотеки Netpoll и гайд по использованию. Сразу отмечу, что статья хороша именно как обзор, а не как серьезный технический текст, т.к. автор статьи будто бы пытается нам её продать, делая громкие заявления, вроде таких:
Это заявление весьма преувеличено — "низкоуровневый доступ к системе" через epoll/kqueue здесь подаётся как уникальное преимущество Netpoll, хотя стандартный runtime Go тоже использует netpoller с epoll/kqueue для эффективной работы с сетевыми соединениями, да и горутины в Go достаточно легковесны (~2KB), чтобы обрабатывать множество соединений при достаточной памяти. В общем, тысяча соединений - совсем не тот порог, где net начинает "задыхаться"
Но при этом сама библиотека Netpoll и правда интересна, пусть и для каких-то особых кейсов. Она предоставляет событийно-ориентированную альтернативу стандартному подходу Go с горутинами для сетевых соединений.
Ключевые особенности:
- Не создаёт горутину на соединение — ключевое, на мой взгляд
- Напрямую работает с epoll/kqueue
- Предоставляет zero-copy API для работы с данными — т.е. позволяет работать с памятью напрямую, избегая лишнего копирования
Реальные преимущества могут быть в специфических сценариях с очень большим числом соединений и строгими требованиями к latency. Но нужны конкретные бенчмарки - в статье их, к сожалению, нет.
Для большинства задач стандартная библиотека net + встроенный netpoller будут отлично работать, вопреки драматичным заявлениям в статье о проблемах после "тысячи соединений". Хотя, автор от части тоже это признаёт, вопрос лишь в границе этого разделения:
Сама статья скорее практическая — автор показывает, как настроить Listener и EventLoop, работать с nocopy API, создать клиент и настроить мониторинг через Prometheus.
————
В любом случае, автору статьи спасибо, что подсветил эту библиотеку и передал основную суть, а также за примеры использования. Раньше я с ней не сталкивался, так что было интересно ознакомиться❤️
Буду рад, если кто-то поделится своими бенчмарками или опытом использования Netpoll в реальных проектах.
#networking #performance #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
Please open Telegram to view this post
VIEW IN TELEGRAM
Хабр
Netpoll: пишем сервера, которые не умирают от нагрузки
Вы знаете, что обычные сетевые библиотеки Go начинают « тяжело дышать », если их нагрузить десятками тысяч соединений? Неважно, делали вы HTTP API или свой TCP сервер — дефолтные инструменты вроде net...
👍26
Golang Дайджест
Netpoll: пишем сервера, которые не умирают от нагрузки https://habr.com/ru/companies/otus/articles/859964/ Небольшой обзор библиотеки Netpoll и гайд по использованию. Сразу отмечу, что статья хороша именно как обзор, а не как серьезный технический текст…
Интересное из комментов
Как пишет nuklearlord, это не первая попытка создать event-driven сетевую библиотеку для Go, предлагая альтернативу стандартному подходу "One Conn One Goroutine":
- evio first commit - Jul 4, 2017
- gnet first commit - Sep 7, 2019
- cloudwego/netpoll first commit - Feb 25, 2021
И интересный комментарий от Алексея Акуловича:
————
Также если вам интересна эта тема, стоит обратить внимание на доклад Алексея Акуловича на GopherCon Russia 2018 про ускорение TCP путём избавления от слоёв абстракций в stdlib Go. Там не было готовой либы, только примеры в репе, но объяснялось где и на чем теряем, и какие альтернативы.
#networking #performance #netpoll
Как пишет nuklearlord, это не первая попытка создать event-driven сетевую библиотеку для Go, предлагая альтернативу стандартному подходу "One Conn One Goroutine":
- evio first commit - Jul 4, 2017
- gnet first commit - Sep 7, 2019
- cloudwego/netpoll first commit - Feb 25, 2021
nuklearlord:
Между тем ключевой вопрос - как прикрутить TLS, не могут решить годами (в том числе потому, что стек TLS в Go нужно переписывать под асинхрон):
https://github.com/tidwall/evio/issues/28 "TLS support ?" - Nov 13, 2018
https://github.com/panjf2000/gnet/issues/16 "TLS support ?" - Sep 24, 2019
И без вот этого TLS не получится написать высокопроизводительные аналоги nginx или unbound... И про "focus on scenarios like Redis, HAProxy" тоже самое, TLS там же тоже не нужен...
И интересный комментарий от Алексея Акуловича:
AterCattus:
У меня тоже в 2017 была первая попытка (весьма успешная) самописной оберки поверх epool, ибо встренное ну никуда не годилось. Потом еще несколько реинкарнаций.
Но в наше время как раз таки сменился фокус на grpc, ибо по работе примерно все общение сервисов на нем, а реализация в google.golang.org/grpc отвратительна по эффективности (на GoFunc рассказывал подробности и что можно сделать).
P.S. У Go несколько лет назад (сейчас, емнип, уже исправили) при работе http2 на каждое соединение уходило по три горутины. Весело было, когда нужно хотя бы 100к коннектов держать.
————
Также если вам интересна эта тема, стоит обратить внимание на доклад Алексея Акуловича на GopherCon Russia 2018 про ускорение TCP путём избавления от слоёв абстракций в stdlib Go. Там не было готовой либы, только примеры в репе, но объяснялось где и на чем теряем, и какие альтернативы.
#networking #performance #netpoll
👍19🔥8❤4