ok

чуваки, есть ли какой-то best practice по тому, сколько рекомендуется плодить горутин для одного запроса. такой пример: у меня есть 100 сервисов, в которые нужно асинхронно сходить, однако на мою ручку может лечь 1к рпс. следовательно одновременно будет около, 100к горутин, что не есть хорошо. в таких случая рекомендуюется использовать пул из воркеров. вопрос в том, сколько воркеров делать?

почему не хорошо?

Вопрос в другом должен быть, мешают ли тебе 100к воркеров?

И если ответ да, тогда используй пул

да, так как хочется чтобы не только одна ручка грела кристал, а еще какая-то работа выполнялась

я не понял сообщения )

работа будет выполняться

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

если тебе их нужно контролировать или ресурсы поджимают

Не то что бы best practice, но есть принцип YAGNI.
Если его прикрутить к вашему вопросу, то будет звучать примерно так: напишите программу, чтоб она работала, а вот когда реально упрётесь в количество горутин, тогда приходите с этим вопросом.

Пока что звучит странно.
Вы говорите, что сходить надо асинхронно, но при этом 100 сервисов для 1к запросов у вас порождают 100к горутин?
Так это не асинхронно. Асинхронно — это когда вы запрос приняли, отложили куда-то таску, потом пришёл какой-то воркер и таску, в которой надо в 100 сервисов сходить, выполнил.

Если же вы под асинхронностью понимаете одновременный обход этих 100 сервисов, то опять-таки возникает вопрос: результат надо отдать как и когда? Синхронно или асинхронно?
От этого и нужно начинать плясать.

Но для начала всё-таки рекомендую начать с первого абзаца.
Вероятней всего вы занимаетесь преждевременной оптимизацией, которая bad practice.

подбирать можно империческим путем

самый простой вариант - количество ядер = количество рутин в пуле

:) это если лень смотреть/считать/вычислять

Ну это ж вообще весь смысл горутин теряется)
Если б там математика какая-нибудь была, то ладно ещё, а так ведь абсолютно неблокирующие операции (запросы к этим 100 сервисам) — было бы на чём экономить)

понял, благодарю

Ну человеку нужно было число )

Ну блин))))

да меня не только число интересовал, а сам подход, как обосновать тот и иной выбор. необходимо ли вообще что-то ограничивать

Смотрите, всё ведь просто.
Если у вас ожидается 1к запросов в секунду, и на каждый запрос вам надо ходить в 100 сервисов, то вы пулом ни количество запросов, ни количество сервисов не уменьшите.

То есть, порождая 100 горутин на запрос, вы получите максимально быстрое выполнение и, если железо выдержит, то проблем вам это не доставит.
Если же железо не будет держать эту нагрузку, то ограничивая количество горутин пулом, вы будете увеличивать время обработки каждого запроса, то есть начнёте создавать очередь, соответственно и не сможете держать 1к рпс.

Если резюмировать, то мы придём к тому что пул вам ничего не даст: потому что если вам в секунду нужно тысячу раз сходить в 100 сервисов, то что бы вы не делали, задача не изменится — вам всё равно нужно будет сходить тысячу раз в секунду в 100 сервисов.

Вы говорили выше что-то про кристалл, но процессор тут не причём, единственное, что вы действительно сможете сэкономить, используя пул, — это память.
Но, опять же, если у вас стоит задача ходить тысячу раз в секунду в 100 сервисов, то вам в любом случае нужно соответствующее задаче железо.

Отталкивайтесь всегда от задачи.