Нормально сделй - нормально будет. Горизонтальное масштабирование не панацея, а подход к скалированию при невозможности скалирования вертикального(привет синхронный питон)

ну, питон не настолько синхронный все-таки. Вот с параллельностью проблемы, да, но процессов можно и много наколбасить

ну, питон не настолько синхронный все-таки. Вот с параллельностью проблемы, да, но процессов можно и много наколбасить

а между процессами ты как общаться будешь?

ну, питон не настолько синхронный все-таки. Вот с параллельностью проблемы, да, но процессов можно и много наколбасить

Кучи процессов это тоже горизонтальное масштабирование, хехе

я выше писал про event loop и его внутреннюю кухню.

не очень понял, какое отношение внутренняя кухня эвентлупа имеет к тому, что горизонтальное масштабирование работает

Кучи процессов это тоже горизонтальное масштабирование, хехе

именно

а между процессами ты как общаться будешь?

в базу писать, например

в базу писать, например

в какую?

не вижу проблемы

в какую?

в любую, зависит от нагрузки

Вот только наличие большого числа процессов/тредов, на каждый реквест - огромный оверхед. Корутины же позволяют избавиться от него(привет гоу, нода)

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

есть много вариантов, и они уже решаются на стороне базы, го тебе тут никак все равно не поможет

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

если такой большой игровой мир - я его разделю на зоны и буду хранить в разных базах на разных серверах

в любую, зависит от нагрузки

можно упросить задачу: обычный чат

как, собственно, и делает blizzard, например

Вот только наличие большого числа процессов/тредов, на каждый реквест - огромный оверхед. Корутины же позволяют избавиться от него(привет гоу, нода)

в питоне тоже есть корутины, если что

+1)

в питоне тоже есть корутины, если что

Да, я даже их пощупал

Но в гоу это однопоточные корутины

Тьфу. в питоне

можно упросить задачу: обычный чат

в одной комнате столько человек не будет все равно, поэтому можно скейлить по комнатам, например

в одной комнате столько человек не будет все равно, поэтому можно скейлить по комнатам, например

а если будет?

Тьфу. в питоне

ну да, ну и что? асинхронность-то есть

Как и в ноде. К слову, коллега забыл await написать на ноде как-то, в результате потеряли тысяч 300 долларов

а если будет?

ну, во-первых, не будет. Писать не будет, это тупо невозможно. Во-вторых, в случае чата можно спокойно писать в несколько баз, ибо нет связей между сущностями

ну да, ну и что? асинхронность-то есть

Это к тому, что всё-равно придётся иметь пару воркеров на бэкап-план. С гоу такой фигни не будет

Как и в ноде. К слову, коллега забыл await написать на ноде как-то, в результате потеряли тысяч 300 долларов

в ноде потоков вообще нет

ну, во-первых, не будет. Писать не будет, это тупо невозможно. Во-вторых, в случае чата можно спокойно писать в несколько баз, ибо нет связей между сущностями

речь не про людей :)

Запись в базу для чата это дорого

Если писать туда всё

А не батчами

Это к тому, что всё-равно придётся иметь пару воркеров на бэкап-план. С гоу такой фигни не будет

не пару воркеров на бэкап, а скейлить их число в зависимости от нагрузки автоматом

ну, во-первых, не будет. Писать не будет, это тупо невозможно. Во-вторых, в случае чата можно спокойно писать в несколько баз, ибо нет связей между сущностями

речь про mq

в ноде потоков вообще нет

Ну как, в libuv есть. По сути можно считать что один

речь про mq

ок, тогда прокидывать весь поток говна в кафку и разгребать на топики отдельно

Ну как, в libuv есть. По сути можно считать что один

ну, они там захардкожены. Формально ты тупо не можешь взять - и создать поток

ок, тогда прокидывать весь поток говна в кафку и разгребать на топики отдельно

и с каким latency это будет работать?

и с каким latency это будет работать?

зависит от того, что нужно

не пару воркеров на бэкап, а скейлить их число в зависимости от нагрузки автоматом

Вот только проблема в том, что боттлнеком у тебя может стать простая арифметическая функция, из-за чего с небольшим числом трафика ты сразу полетишь скейлиться, не особо понимая зачем

ты не абстрактный пример придумывай, давай ближе к жизни

ну, они там захардкожены. Формально ты тупо не можешь взять - и создать поток

В гоу то то же самое

Вот только проблема в том, что боттлнеком у тебя может стать простая арифметическая функция, из-за чего с небольшим числом трафика ты сразу полетишь скейлиться, не особо понимая зачем

ну так это при нагрузочном тестировании должно еще выясниться же

Это пахнет вбивание в голову гвоздя ради инструмента

Либо го, либо тащить кафку

Это странно

:()

в гоу тоже тащить придётся

В гоу то то же самое

ну, не совсем так. Если у тебя есть два ядра и ты делаешь две горутины с i/o - можно быть почти уверенным, что го создаст поток

Либо го, либо тащить кафку

Будь я хейтером гоу, я бы притащил гоу

Либо го, либо тащить кафку

ненене, ты не поняла

го не решает этих проблем точно так же, как не решает их питон

просто гошных воркеров нужно будет меньше

ты не абстрактный пример придумывай, давай ближе к жизни

ну ок. фиг с этими игрушками, пусть будет днс-сервер вроде 8.8.8.8

ну, не совсем так. Если у тебя есть два ядра и ты делаешь две горутины с i/o - можно быть почти уверенным, что го создаст поток

нет.

ну ок. фиг с этими игрушками, пусть будет днс-сервер вроде 8.8.8.8

DNS - это распределенная база данных, если что. Да, там все это уже искаропки работает.

нет.

если есть i/o - то да

там есть тонкости, да, но в целом можно иногда явно предсказать поведение

Гоу всегда имеет запущеный пул потоков, равный числу ядер(регулируется через энв), а планировщик кидает задачи куда удобно в зависимости от занятости

DNS - это распределенная база данных, если что. Да, там все это уже искаропки работает.

ну если с первым я согласен, то второе какое имеет отношение к вопросу?

Гоу всегда имеет запущеный пул потоков, равный числу ядер(регулируется через энв), а планировщик кидает задачи куда удобно в зависимости от занятости

не числу ядер, строго говоря, а GO_MAXPROC, если я не путаю

ну если с первым я согласен, то второе какое имеет отношение к вопросу?

ну, ты знаешь, как работает DNS?

не числу ядер, строго говоря, а GO_MAXPROC, если я не путаю

Да, ну я и сказал что через энв регулируется. Раньше по дефолту было = 1, а сейчас - числу ядер

там нет проблемы, что данные будут на нодах чуточку рассинхронизированы, поэтому горизонтально масштабировать можно сколько угодно

ну, ты знаешь, как работает DNS?

да. и?

там нет проблемы, что данные будут на нодах чуточку рассинхронизированы, поэтому горизонтально масштабировать можно сколько угодно

ты просил конкретную задачу.

да. и?

и - твой пример про 8.8.8.8 невалиден немного

это вообще eventual consistency.

ERROR: S client not available

ты просил конкретную задачу.

ну, конкретная задача твоя решается тупо установкой кучи кэширующих dns-серверов

причем тут го - непонятно

и - твой пример про 8.8.8.8 невалиден немного

нет-нет. мой пример про 8.8.8.8 - это про нагрузку.

причем тут го - непонятно

речь про dns-сервер на го :)

речь про dns-сервер на го :)

да хоть на баше

dns масштабируется шикарно

надо всего лишь быстро уметь данные из локального кэша отдавать

dns масштабируется шикарно

это понятно. но сколько тебе понадобится железа в случае с python?

чуть больше чем с go)

это понятно. но сколько тебе понадобится железа в случае с python?

немногим больше, на самом деле, особенно если кода на самом питоне там будет минимум

а что?

немногим больше, на самом деле, особенно если кода на самом питоне там будет минимум

минимум? это сколько? ноль? )

минимум? это сколько? ноль? )

нет, просто минимум для склейки сишных библиотек

это я ненавязчиво намекаю на japronto или что-то подобное

это я ненавязчиво намекаю на japronto или что-то подобное

нет такого для udp & dns :)

Мне кажется вы потеряли саму суть вопроса выбора инструмента. По сути, для бизнеса, вполне можно написать DNS сервер и на питоне так, что бюджет не будет ОООЧЕНЬ больше, чем на гоу. Вопрос в том, что на питоне будет оверхед, при разработке на питоне вы НЕ ПОЛУЧИТЕ выгоды от экосистемы питона. А на гоу вы получите лучшее качество, за счёт типизации, обработки ошибок, скорости.

нет такого для udp & dns :)

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

https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=go&lang2=python3 бгг

если что, мой поинт в том что хорошо масштабироваться когда можно просто шардить юзеров.

Мне кажется вы потеряли саму суть вопроса выбора инструмента. По сути, для бизнеса, вполне можно написать DNS сервер и на питоне так, что бюджет не будет ОООЧЕНЬ больше, чем на гоу. Вопрос в том, что на питоне будет оверхед, при разработке на питоне вы НЕ ПОЛУЧИТЕ выгоды от экосистемы питона. А на гоу вы получите лучшее качество, за счёт типизации, обработки ошибок, скорости.

ну да, если загнать в такие рамки, то у го будет преимущество, потому что бизнес-логики тут особой не надо

Смешные цифры

и плохо, когда ты это делать не можешь и заперт в рамках одного процесса

https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=go&lang2=python3 бгг

да ну бредовый бенчмарк, на самом деле :)

и плохо, когда ты это делать не можешь и заперт в рамках одного процесса

не вижу проблемы. Запусти еще процессов, ничего не развалится

в итоге выйдет немного дороже, да

но зато гибче

и из быстрых механизмов ipc есть только shared memory, но она требует синхронизации

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

ты хоть раз пробовал это делать?

ты хоть раз пробовал это делать?

конечно

и из быстрых механизмов ipc есть только shared memory, но она требует синхронизации

далеко не всегда нужен ipc

далеко не всегда нужен ipc

а если нужен?

а если нужен?

потому что ты так сказал?