s
Size: a a a
2020 June 12
p
Хз на сколько это реально, но может проблемы из-за кэшируемых (можно ли так назвать?) tcp соединений.
Можно попробовать настроить http.Transport с низким idle таймаутом и одновременными подключениями. Http.transport выставляется внутри http client
Можно попробовать настроить http.Transport с низким idle таймаутом и одновременными подключениями. Http.transport выставляется внутри http client
Кешируемых tcp? Это как?
ЗА
ща
p
а аллокации в принципе вещь не дешёвая
Я когда-то видел доклад вида "top performance killers"
ЗА
Кешируемых tcp? Это как?
ЗА
я как раз про то, что может из-за этого и происходит переполнение, обычно всегда в транспорте какие-то ограничения ставят, а-ля
tr := &http.Transport{
MaxIdleConns: 10,
IdleConnTimeout: 30 * time.Second,p
Так это про keep-alive
RS
Я когда-то видел доклад вида "top performance killers"
..ии?)
p
..ии?)
Там аллокация, копирование, поштучный процессинг
RS
Там аллокация, копирование, поштучный процессинг
+ syscalls
p
+ syscalls
Ну в них сложно упереться.
RS
Ну в них сложно упереться.
на винде упирался как-то с вебсокетами, возможно уже пофиксили, возможно в самой винде проблема
ЗА
Так это про keep-alive
так он же может не знакрыться после close запроса. мы же имеем выделенный дескриптор на руках
s
я как раз про то, что может из-за этого и происходит переполнение, обычно всегда в транспорте какие-то ограничения ставят, а-ля
tr := &http.Transport{
MaxIdleConns: 10,
IdleConnTimeout: 30 * time.Second,Тут не поможет. Потому что на каждое соединение создаётся 1 новый client с 1 idleconn. И оно будет закрыто только когда придёт gc и прибъёт сокет открытый
RS
runtime плодил столько syscall’ов что наплодил в итоге 10k потоков и система повисла