Чиним проблемы нагрузок в Go с помощью настройки пула HTTP-соединений

[AlexSpaizNet]

Как я понимаю проблема эта может всплыть только когда нужны постоянные соединения. То есть, либо кип элайв, либо http/2 как у вас.

[ivstrelkov]

Конкретно в данном случае использовался HTTP/1.1 с Keep-Alive.

В HTTP/2, насколько я знаю, проблема не стоит так остро, поскольку там используется мультиплексирование соединений. Однако чтобы использовать HTTP/2, нужно заморочиться с настройкой TLS. Полагаю, именно по этой причине в моей ситуации использовался HTTP/1.1

[AlexSpaizNet]

Сколько хочу попробовать кип элайв или http/2 во внутренних коммуникациях между сервисами, но у нас балансировка на уровне DNS. У вас нет такой проблемы автоскелинга и балансировки запросов?

Писать балансировку на клиенте не хочется, а ставить лоад балансер чтобы он держал конекшены и балансил все девопс пока не хочет…

[eyudkin]

Можно поставить sidecar в качестве балансировщика, это прям один из юзкейзов для того же envoy

[AlexSpaizNet]

Спасиб. Ща глянул, он вроде как даже умеет с консулом дружить, где у нас регистрируются сервисы. Надо будет поиграться. Retries, rate limit, circuit breaker. Вкусная штука. Будем обсуждать с девопсами =)

[ivstrelkov]

Прошу извинить за недоразумение. Диаграммы были отрисованы в сервисе WebSequenceDiagrams и стиль «рисования от руки» был выбран намеренно.

Я посчитал, это позволит воспринять статью в более легком стиле.

Буду иметь в виду, что могут быть подобные проблемы при восприятии диаграммы.

[vn_sten]

Насколько я знаю fasthttp от valyala должен решить ваши проблемы описанные в статье, плюс еще много улучшений которые не описаны, рассматривали fasthttp?

[ivstrelkov]

К сожалению, не приходилось использовать эту библиотеку.

Насколько я вижу, в ней есть похожая настройка, однако параметр по умолчанию уже совершенно другой:

const DefaultMaxConnsPerHost = 512

Поэтому, как вы верно заметили, описанная в статье проблема невозможна в случае использования FastHTTP.

[gotz]

HTTP-стек из стандартной библиотеки Golang не рассчитан на полноценное использование в продакшен-средах, а тем более для highload-сервисов. Кажется, как минимум миграция на fasthttp поможет улучшить все показатели взаимодействия микросервисов :)

[ivstrelkov]

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

Правда, я не очень понимаю, почему стандартная библиотека не рассчитана на полноценное использование в продакшне. Увы, я не смог найти мнения о том, что net/http вообще не стоит использовать. Буду рад, если подскажете, почему так не стоит делать)

[vn_sten]

Всё нормально если использовать стандартную net/http, только на highload сервисах надо будет тюнить

[AlexSpaizNet]

Да не очень то и нормально. У дефолтного клиента таймаут бесконечный. Может быть сюрпризом.