MaxIdleConnsPerHost в http.Transport
Вопрос
Сервис делает 2000 RPS в один внутренний API, и в системе тысячи соединений в TIME_WAIT. Какой параметр транспорта, скорее всего, виноват?
Попробуйте сами
Выберите вариант, и откроется разбор.
Показать ответ и разбор
Коротко
Варианты ответа
MaxConnsPerHost, по умолчанию 2: лишние запросы ждут в очередиMaxIdleConnsPerHost, по умолчанию 2: лишние соединения закрываютсяправильный ответDisableCompression: без сжатия ответы рвут соединенияTLSHandshakeTimeout: рукопожатие обрывается и соединение закрывается
Разбор
DefaultTransport хранит в пуле не больше 2 простаивающих соединений на хост (DefaultMaxIdleConnsPerHost = 2). При высоком параллелизме остальные после ответа закрываются, а новые запросы открывают новые соединения, отсюда TIME_WAIT и лишние handshake. Лечится своим Transport с MaxIdleConnsPerHost около ожидаемого параллелизма. MaxConnsPerHost по умолчанию 0, то есть без ограничения. Сжатие и TLS-таймаут на это не влияют.
Ответьте сами, а не прочитайте
В тренажёре вопрос попадёт в повторения и вернётся, когда начнёт забываться. Плюс билеты с зачётом: 20 вопросов, не больше 2 ошибок.
Термины по теме
Ещё по теме «net/http и middleware»
- Статистика access-логов: ошибки и p95 на Go
- Разбор сырого HTTP/1.1 запроса на Go
- Разбор query-строки URL с декодированием на Go
- Маршрутизатор с параметрами пути в стиле ServeMux
- Rate limiter на токен-бакете для middleware на Go
- Зачем закрывать resp.Body
- Таймаут http.DefaultClient
- Обработчики net/http и горутины