у тебя много инстансов приложения или они часто дохнут?

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

я вангую привычка из питона или пхп

я вангую привычка из питона или пхп

тогда sync.Map

у тебя много инстансов приложения или они часто дохнут?

Есть такая штука с исходниками: https://habr.com/ru/post/359078/

А что делать если много инстансов?

если на хх ру резюме посмотрели, но не ответили

почему я должен сидеть и обновлять пейдж в надежде, что они ответят)))

Иногда (редко) бывает, что рекрутер не может принять решение сам, отбирает подходящие по ключевым словам, показывает кому-то ещё, потом уже отвечает

но я и вправду не понимаю в чем проблема просто ответить)))

по пивку и спать

Либо стыдно, либо нет желания и времени. Никто никогда не извиняется перед раздавленным муравьём. (очень грубо)

Энергетики и кофеин из аптеки

только кофе или чай

нет опыта работы(год)

Добрый вечер. Пытаюсь разобраться в следующем поведении: есть http handler, он читает тело запроса, стартует goroutine(не дожидается ее завершения) и возвращает 200. И вот тут начинается следующее поведение: чем больше работы делает горутина (зависит от объема тела запроса), тем меньше RPS держит сервер. В случае небольшого тела запроса - 5к rps, в случае с большим телом запроса - 400 rps. При этом нагрузка на цп выше при большем RPS при малых запросах. По какой причине горутины оказывают такое влияние на RPS? (мое предположение заключается в том более долгая работа горутин дольше держит контекст без переключения, тем самым блокируя возможности на прием новых соединений, однако это не помогает понять как эту ситуацию решить чтобы получить похожую производительность в обоих кейсах)

что делают горутины? математику считают? если все-таки есть ввод вывод, каналы, то переключение контекста происходит

там в основе математика.

есть какая-то штука вроде "дай время другой горутине"

я бы лучше разнес такое: система очередей (да хоть в СУБД обычной) и воркеры отдельными процессам/и

https://pkg.go.dev/net/http/pprof

https://go.dev/pkg/runtime/?m=old#Gosched

Gosched я пробовал) Но это выглядит как-то совсем костылем. да и не дало хорошего эффекта.

вообще непонятно выглядит: если оно не успевает принимать из-за того, что проца не хватает, то значит он должен быть забит процессингом. а процессингом он не забит. хэндлер пишет в базу? процессинг пишет в базу?

Добрый вечер. Пытаюсь разобраться в следующем поведении: есть http handler, он читает тело запроса, стартует goroutine(не дожидается ее завершения) и возвращает 200. И вот тут начинается следующее поведение: чем больше работы делает горутина (зависит от объема тела запроса), тем меньше RPS держит сервер. В случае небольшого тела запроса - 5к rps, в случае с большим телом запроса - 400 rps. При этом нагрузка на цп выше при большем RPS при малых запросах. По какой причине горутины оказывают такое влияние на RPS? (мое предположение заключается в том более долгая работа горутин дольше держит контекст без переключения, тем самым блокируя возможности на прием новых соединений, однако это не помогает понять как эту ситуацию решить чтобы получить похожую производительность в обоих кейсах)

чем кстати бомбишь?

ну или проще: много мелких 90% проца, мало больших 85% проца

с какого компа обстрел происходит

а сколько в секунду передается примерно данных в случае больших боди?