Size: a a a

2020 August 13

S

Sergey in Go-go!
тогда чем вас не устраивает по тикеру 30секунд запускать вашу горутину?
источник

s

sexst in Go-go!
Process user
Запускаем приложение, которое в горутине будет делать http реквест, парсить json и записывать данные в структуру. Делать это надо каждые 30 секунд.
Нужно весь код из main оформить в отдельную горутину, сделать ticker на 30с, и просто в select делать запрос и обновлять структуру. Без вызова ещё одной горутины в селекте
источник

s

sexst in Go-go!
И пусть она себе на фоне раз в 30с отрабатывает
источник

Pu

Process user in Go-go!
Sergey
тогда чем вас не устраивает по тикеру 30секунд запускать вашу горутину?
меня не страивало только то, что при старте приложения, сначала срабатывает таймер, а уже потом запуск горутины.
источник

s

sexst in Go-go!
И используйте для обновляемой структуры Rwlock
источник

s

sexst in Go-go!
Process user
меня не страивало только то, что при старте приложения, сначала срабатывает таймер, а уже потом запуск горутины.
Вы, похоже, не очень ещё понимаете как это всё взаимодействует?)
источник

s

sexst in Go-go!
Или вам нужно предварительно инициировать?
источник

s

sexst in Go-go!
А потом по таймеру обновлять?
источник

Pu

Process user in Go-go!
Давайте на примере разберем.
https://play.golang.org/p/oBX8XLXcWGc
источник

s

sexst in Go-go!
Напишите вложенную функцию по обновлению данных в горутине.
Вызовите её при старте, потом запустите таймер и вызывайте по таймеру
источник

Pu

Process user in Go-go!
После запуска, срабатывает тикер, ожидаем 100 секунд, после чего сработает горутина и выполнится fmt.Println("Hello, playground")
источник

Pu

Process user in Go-go!
sexst
Напишите вложенную функцию по обновлению данных в горутине.
Вызовите её при старте, потом запустите таймер и вызывайте по таймеру
как вариант, подумаю как реализовать. Спасибо
источник

E

Exсt in Go-go!
мне кажется вариант с time.Sleep самым лаконичным и правильным. рутина, в ней фор{}, а в нём слип после полезной нагрузки
источник

Pu

Process user in Go-go!
Exсt
мне кажется вариант с time.Sleep самым лаконичным и правильным. рутина, в ней фор{}, а в нём слип после полезной нагрузки
как мне кажется, это самый простой вариант)
источник

E

Exсt in Go-go!
Process user
как мне кажется, это самый простой вариант)
обычно если не знаешь зачем усложнять, то усложнять не надо)
источник

Pu

Process user in Go-go!
Process user
как мне кажется, это самый простой вариант)
согласен, иногда это очень мешает.
источник

s

sexst in Go-go!
Exсt
мне кажется вариант с time.Sleep самым лаконичным и правильным. рутина, в ней фор{}, а в нём слип после полезной нагрузки
Ну если устраивает вариант того, что запросы стали подвисать на условные 20с и в итоге у вас обновления делаются не раз в полминуты, а уже раз в 50 секунд - да, проще. Или можно вычислять время для "досыпания" после запроса так, чтобы интервал равнялся 30 секундам. Но это уже будет и не проще и переписыванием того, для чего делался Ticker вручную по большому счёту.
источник

zl

ziggy lucid in Go-go!
у кого есть опыт использования httputil.ReverseProxy?
почему при увеличении нагрузки он рывком сваливается в штопор на 100% загрузку всех ядер и не выходит оттуда? Использую дефолтный вариант, который httputil.NewSingleHostReverseProxy()
nginx играючись держит эту же нагрузку на той же машине
В сторону чего смотреть вообще?
источник

VM

Vladislav Milenin in Go-go!
ziggy lucid
у кого есть опыт использования httputil.ReverseProxy?
почему при увеличении нагрузки он рывком сваливается в штопор на 100% загрузку всех ядер и не выходит оттуда? Использую дефолтный вариант, который httputil.NewSingleHostReverseProxy()
nginx играючись держит эту же нагрузку на той же машине
В сторону чего смотреть вообще?
pprof
источник

VM

Vladislav Milenin in Go-go!
Скорее всего что-то течет
источник