Pull to refresh

Comments 7

Не могу не вспомнить тут свой доклад с GopherCon Russia 2018 про ускорение TCP, убиранием слоев абстракций в гошной stdlib. Там по факту не было готовой либы, только все примеры в репе, но объяснялось где и на чем теряем, и какие альтернативы.

https://youtu.be/809uWH-wvIo?si=ZtKq0U2vtyMwD08c

Тоже интересно почему эта пуля от всех бед не встроена во все сетевые библиотеки по умолчанию.

Из README.md от https://github.com/cloudwego/netpoll:

RPC is usually heavy on processing logic and therefore cannot handle I/O serially. But Go's standard library net is designed for blocking I/O APIs, so that the RPC framework can only follow the One Conn One Goroutine design. It will waste a lot of cost for context switching, due to a large number of goroutines under high concurrency. Besides, net.Conn has no API to check Alive, so it is difficult to make an efficient connection pool for RPC framework, because there may be a large number of failed connections in the pool.

On the other hand, the open source community currently lacks Go network libraries that focus on RPC scenarios. Similar repositories such as: evio, gnet, etc., are all focus on scenarios like Redis, HAProxy.

Жирным выделен главный фундаментальный недостаток, и почти все поголовно так пишут, например, Caddy или CoreDNS...

https://github.com/tidwall/evio first commit - Jul 4, 2017

https://github.com/panjf2000/gnet first commit - Sep 7, 2019

https://github.com/cloudwego/netpoll first commit - Feb 25, 2021

Традиция уже походу, каждые два года изобретать очередной event based net pool...

Меду тем ключевой вопрос - как прикрутить TLS - не могут допилить годами (в том числе потому, что стек TLS в golang нужно переписывать под асинхрон):

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 там же тоже не нужен...

У меня тоже в 2017 была первая попытка (весьма успешная) самописной оберки поверх epool, ибо встренное ну никуда не годилось. Потом еще несколько реинкарнаций.

Но в наше время как раз таки сменился фокус на grpc, ибо по работе примерно все общение сервисов на нем, а реализация в google.golang.org/grpc отвратительна по эффективности (на GoFunc рассказывал подробности и что можно сделать).

P.S. У Go несколько лет назад (сейчас, емнип, уже исправили) при работе http2 на каждое соединение уходило по три горутины. Весело было, когда нужно хотя бы 100к коннектов держать.

Кто нибудь использует подобное в реальном проекте? Для каких сценариев имеет смысл внедрять?

Например, вот здесь пример реального проекта, https://habr.com/ru/companies/vk/articles/331784/

У меня на проекте такой же подход используется.

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

Sign up to leave a comment.