N>Вы, мысля масштаба WhatsApp и Facebook, не понимаете, что при маленькой команде (а она никогда не выходила за 10 человек, из которых собственно проблемы транспорта понимали максимум 3, а ведь есть и другие задачи)
Вы, вероятно, не поверите, но в масштабе WhatsApp "проблемами транспорта" занимается 1.5 человека. Эти же 1.5 занимаются еще и системой сборки, и багами в BEAM'е, и еще много чем кроме.
N> И общей проблемой, наверно, 99% взаимодействий является то, что если сообщение потеряно, то его надо перепосылать. Множественные "трубы" тут ничего не дадут.
Возвращемся к exactly once delivery, а также множественным реализациям tcp over tcp. Ох сколько их я видел
N>Ага, то есть хорошо было бы ещё и в binary их перепаковывать, причём размера не меньше сколько-то (с какого размера там включается оптимизация)? И это на внутреннем взаимодействии (внутри одной ноды)? Вам не кажется, что это слишком большие требования для простой задачи?
По условию задачи, вы пользуетесь gen_tcp:send(). Он на вход принимает binary(). То есть вы совершенно точно уже пакуете ваши структуры в binary(). Именно это (и только это) я и предлагаю делать в отдельном процессе, задача которого — заниматься сериализацией, и ничем более.
Вы можете честно признаться, что такое решение не пробовали?
Добавлю, что такие решения начинают появляться только после осознания аналогии между экземпляром класса в С++ и процессом в Эрланге. Равно как класс "труба" не занимается сериализацией, так и в эрланге, процесс "труба" занимается только трубой.
N>Я посмотрел, спасибо. Великолепный английский как для родного русского — завидую...
Спасибо. К сожалению, цена — некоторая потеря умения писать и говорить по-русски.
N> остаётся определить, с чего именно начинать измерения и проверки, а это получается только с опытом в теме.
И об этом я тоже говорю. Начинать надо с вопросов "зачем" (почему). До тех пор, пока не достигнем корня проблемы. К сожалению, подобные выступления всегда очень ограничены по времени, поэтому я лишь очень вскользь прошелся по critical thinking (думаю, упоминал critical thinking cards, fallacies и т.п.). Конечно, опыт важен, но еще важнее умение думать. Зрить в корень.
N>Дададад. "Отвечал". То есть шло бы обратно сообщение, которое вставало бы в конец очереди. Вы это серьёзно?
Я же говорю, что видел и более странные side channel, — не значит, что они работали как ожидалось авторами. Но, однако, из-за selective receive optimisation, — иногда и работало.
N>И вы тут то ли намеренно ёрничаете, то ли явно не в курсе про volatile в многонитевом окружении?
Я же даже поставил большой зеленый смайл. Возможно, стоило вставить смайл с "сарказмом".
N>Перескажите словами, что происходит, если хотите понимания.
Классика жанра, которую так же легко воспроизвести для вашего случая (один процесс накапливает binary buffer, второй шлет данные). Там сделана оптимизация, что процесс "трубы" перед тем как отправить данные в трубу спрашивает у сериализующего процесса "а не пришли ли еще данные". Когда данные идут непрерывно, получается бесконечный цикл, рано или поздно выедающий всю память.
N>Как вы через супервизоры будете снимать набор количественных показателей работы приложения (текущие уровни, счётчики, и всё такое)? Или вы под словом "мониторинг" тут понимаете только
См. выше, про "зрить в корень". Уровни, счетчики, "все такое" — каким это образом используется? Какие решения принимаются?
N>Или опять ETS, который вы хотели бы устранить?
Для простых счетчиков ETS уже не модно. Современные реализации обычно что-то вроде ecount, или вовсе telemetry (open telemetry)
N>Я думаю, последние 20 лет вопрос "какие действия принимаются..." на основе счётчиков событий (банально, полученных/посланных сообщений по выбранной классификации, и всё такое) — просто не должен озвучиваться. Вопрос должен быть — делаются ли эти действия вообще и правильные ли они.
Не соглашусь. Это как раз самый что ни на есть важный вопрос — "как мы используем собираемые данные". Понимаю, что дальше будет вопрос "а что нам это стоит" и "с таким ценником, а стоит ли".
N>1) Речь идёт об управлении конкретным процессом и его контроле через единственный, по вашим же правилам, разрешённый интерфейс в виде асинхронно поступающих сообщений. Канал через ETS не разрешаем. N>2) Надо управлять этим процессом, включая регулирование параметров (оперативное! ждать секунды, пока он прочтёт сообщение, нельзя). N>3) Увы, gen_call иногда (а может, и всегда) нужен из-за того, что на нём работает некоторый интерфейс, который мы менять не можем.
Здесь я не могу привести ничего другого, кроме как притчи:
Мастера боевых искусств спросили, как он поступит, если переходя узкий подвесной мост над пропастью, заметит засаду спереди и сзади? Мастер несколько раз сказал, что он не понимает заданного вопроса. В конце концов ученики потеряли терпение:
— Что тут непонятного? Ты на мосту, ты не можешь идти вперед, ты не можешь вернуться, ты не можешь убежать, ты не сможешь справиться с таким большим числом врагов!
— Я не понимаю, как я смогу оказаться в таком положении? — был ответ.
Вы можете снова обвинить меня в философствовании, и в том, что не отвечаю на очень конкретно поставленный вопрос. Но попробуйте еще раз перечитать притчу.
N>И снова от вас никакой конкретики, только "стройная модель" (стройность которой на самом деле ничуть не испортит введение нескольких очередей) и ссылка на какие-то посторонние случаи, про которые ничего не известно.
Потому что ваш вопрос не является вопросом, а явлется тем самым "спереди вражеские воины, и сзади, а вы на подвесном мосту". Вы сами ставите такие условия, а потом запрещаете ровно то, о чем я так давно уже говорю — "challenge your assumptions".
N>А почти все задачи начинаются с "быстрее сделать", построить MVP или какой там будет его аналог. И вот тут становится критичным, что люди, которые не разбираются во всех тонкостях, должны поднять и сопровождать проект на начальной стадии.
Вернулись к "учиться работать с экскаватором некогда, потому что нужно копать". Не вижу смысла заходить на третий круг. Понимаю ваши рассуждения о том, что для освоения радикально новых концепций требуется больше времени, чем просто перейти с очередного С+ на С++ и на С+++.
Еще раз сетую на недостатки существующей системы образования. Это заколдованный круг, когда кто-то уже научившийся императивному программированию с идиомой "call" думает, что так легче научить других. Нет, не потому, что так легче, а потому что он уже так научился. Это для него, кто уже с детства был так научен. И что он делает дальше, просто продолжает делать то, чему его научили. Тот самый fixed mindset. Который так мешает многим.
N>То есть пробовать не хотите? Спасибо, Ч.Т.Д.
Мне не нужно пробовать. Я уже объяснил, что знаю, как оно устроено и как работает. Это ключевые умения разработчиков — не просто "пробовать" и говорить "что-то где-то как-то не так", а разбираться в том, *ПОЧЕМУ* оно так.
N>А для практического применения я буду выбирать средства с максимально пологой кривой обучения (будем уже держаться в рамках этого термина), потому что полученные продукты будут выживать даже при полной смене команды.
Вероятно, risk/reward у вас сдвинут в сторону меньшего риска.
Это может быть как сознательный выбор, так и боязнь неудачи, или вовсе возрастной признак.
Могу лишь отметить, — кто не рискует, тот не пьет шампанское
Здравствуйте, SkyDance, Вы писали:
SD>— Я не понимаю, как я смогу оказаться в таком положении? — был ответ.
SD>Вы можете снова обвинить меня в философствовании, и в том, что не отвечаю на очень конкретно поставленный вопрос. Но попробуйте еще раз перечитать притчу.
Да, роскошная притча. И она показывает, что, так как вопрос "попасть в засаду с обеих сторон" это всего лишь вопрос затрат и качества сил, организованных против такого мастера, то есть по сути только один вариант положительного решения: просто не допускать ситуации, когда это возможно. В переложении на нашу обстановку — не пытаться решать задачи, которые данным средством не решаются, перекладывая их на другие средства. А как именно не допускать (не ходить самому в места, где могут быть такие засады; иметь возможность убежать; успокоить всех врагов) — уже по обстановке.
Ну вот это и совпадает с моим выводом из личного опыта, а также с тем, что говорили упомянутые в прошлых сообщениях коллеги: что Erlang не подходил изначально под эти задачи. Мне только слегка обидно, что для того, чтобы он подошёл, требовалось совсем немного изменить, но в корне... значит, не судьба.
Не вижу смысла тратиться на остаток сообщения, я его сохраню себе на память, но отвечать было бы очередным перепевом уже сказанного, так что закруглюсь. Хотя если у кого-то будут конкретные вопросы по отдельным аспектам — отвечу по мере сил и настроения.
SD>Вероятно, risk/reward у вас сдвинут в сторону меньшего риска. SD>Это может быть как сознательный выбор, так и боязнь неудачи, или вовсе возрастной признак. SD>Могу лишь отметить, — кто не рискует, тот не пьет шампанское
Здравствуйте, Mystic Artifact, Вы писали:
N>>Слово "синидиотически" не находится. Опечатка или что? MA> Там одна большая опечатка... и не только в орфографии но и по смыслу. MA> Имелось ввиду, что больше нравятся языки и платформы общего назначения, на которых строятся конкретные решения (аля библиотеки). Не вижу плохого в других подходах (а иногда вижу и плюсы), но узколобая душонка их не любит и требует сделки с дьяволом.
Ну да, этот подход вообще больше распространён сразу по нескольким причинам — единый язык, универсальность поддержки и отладки (не нужно строить бутербродов, для диагностики в которых требуются супер-скиллы) и прочая и прочая... И вот что характерно — именно набравшись разнообразного опыта и дойдя до высот профессии, начинаешь понимать, насколько ценна экономия умственных усилий даже в достаточно простых вещах. Так что это не "сделка с дьяволом", это как раз достижение разумного оптимума. Всякие штуки типа облегчения работы с персоналом (банально, меньше потребность в суперспецах) это уже приятное следствие. А работы всё равно хватит на всех
N>Ну вот это и совпадает с моим выводом из личного опыта, а также с тем, что говорили упомянутые в прошлых сообщениях коллеги: что Erlang не подходил изначально под эти задачи. Мне только слегка обидно, что для того, чтобы он подошёл, требовалось совсем немного изменить, но в корне... значит, не судьба.
Erlang-то подходил отлично. Просто у вас не было знаний о том, как его использовать. Простейшее решение с binary buffer, пишется за 3 часа (из которых 2 на написание автотестов, и 0.5 на документацию). Как вариант, за пару дней (но тогда уже с серьезным тестированием через property-based testing).
Поскольку нужной квалификации в 2010 у вас не было, вы приняли правильное решение делать так, как умеете.
И по нашему разговору не совсем ясно, изменилось ли что-то с 2010. Вероятно, вы остались в плену парадигм 90х.
Здравствуйте, SkyDance, Вы писали:
NB>>стало понятно, почему эрланг не выстрелил.
SD>Для тех, кому не стало понятно, хотелось бы узнать, почему. Кроме очевидного "за 3 дня мы не научились, а больше времени не было".
потому что людям нужно решать реальные задачи, а не бороться с языком из-за того что твоя задача не вписывается в стандартные шаблоны.
Здравствуйте, SkyDance, Вы писали:
SD>Erlang-то подходил отлично. Просто у вас не было знаний о том, как его использовать. Простейшее решение с binary buffer, пишется за 3 часа (из которых 2 на написание автотестов, и 0.5 на документацию). Как вариант, за пару дней (но тогда уже с серьезным тестированием через property-based testing).
Это не "простейшее". Это костыли на обход заведомых недостатков рантайма. Те самые сложные решения, о уходе от которых вы так красиво тут расписываете.
(Блин, собирался же закрыть тему... ладно, ещё немного попрыгаем.)
SD>Поскольку нужной квалификации в 2010 у вас не было, вы приняли правильное решение делать так, как умеете.
Спасибо на этом.
SD>И по нашему разговору не совсем ясно, изменилось ли что-то с 2010. Вероятно, вы остались в плену парадигм 90х.
Здравствуйте, SkyDance, Вы писали:
NB>>потому что людям нужно решать реальные задачи, а не бороться с языком из-за того что твоя задача не вписывается в стандартные шаблоны.
SD>А, стало быть, опять "трясти надо" (С) анекдот.
не, тут бы еще какая-нибудь притча лучше подошла...
SD>Вот пока вы "решаете реальные задачи", другие пишут WhatsApp.
смотри, как бы не пришлось в один прекрасный день писать WhatsApp в одно лицо.
Здравствуйте, Sharov, Вы писали:
S>Подождем Skydance'а. Он как раз performance engineer в wa.
А какое отношение имеет максимальное количество сокетов к соединениям? Если что, сейчас
в моде (и это больше 5 лет точно как мода) держать на одном сокете до хрена соединений. У каждого запроса свой UUID. каждый сокет работает как event loop, там нет никаких синхронных операций, он отдает ответ мгновенно (почти, там из ресурсоемкого только зачастую поиск в хеш мапе). Да, сами обработчики могут занимать значительное время, причем на один запрос могут тратиться даже не минуты, а часы и даже дни. Но за счет асинхронного API время работы обработчика по существу пофиг, его состояние нужно только держать в памяти, зачастую персистентной, чтоб если ноде киржык другая нода подняла и ничего снаружи не было бы заметно.
Здравствуйте, elmal, Вы писали:
E> в моде (и это больше 5 лет точно как мода) держать на одном сокете до хрена соединений.
И как это возможно на одном сокете логически демультипликсировать запросы разных пользователей? Сколько запросов, столько сокетов.
И каким образом API сокета знает про UUID? Т.е. речь идет об http, и как сокет будет собирать для каждого отельного http-запроса пакеты?
Т.е. этот пакет для UUID такого, этот для такого... Как это возможно с одним сокетом?
Здравствуйте, elmal, Вы писали:
E>А какое отношение имеет максимальное количество сокетов к соединениям? Если что, сейчас E> в моде (и это больше 5 лет точно как мода) держать на одном сокете до хрена соединений. У каждого запроса свой UUID. каждый сокет работает как event loop, там нет никаких синхронных операций,
Это уже вы что-то очень странное пишете. Начнём с того, что термин "соединение" (connection) применяется к TCP, но не к UDP, где принято "ассоциация" (association). Но на TCP, со стандартным BSD sockets API (которое повторено в Linux, в Windows с поправкой на WSA*, и пр.), для установленного соединения вам насильно выдадут отдельный сокет. Объединять несколько соединений в одном сокете там невозможно. А другого API пока что не завезли (а если вспоминать считаем вымерший XTI, то и там было по endpointʼу на соединение).
Для UDP, да, похоже на то, что вы описываете. Но и ограничения от этого соответствующие: например, вы не можете, не поменяв порт (и соответственно сокет) со своей стороны, распределить нагрузку между несколькими слушателями без хитрых примочек уже уровня ОС по тому, на какой сокет (одного порта) пойдут запросы от конкретного IP. Это проблема, например, с QUIC.
И "свой UUID у каждого запроса" это специфика небольшого количества особых протоколов. Например, DNS, SIP, с поправкой на то, что такое UUID для конкретного случая. Уже QUIC сюда слабо подходит.
E>он отдает ответ мгновенно (почти, там из ресурсоемкого только зачастую поиск в хеш мапе). Да, сами обработчики могут занимать значительное время, причем на один запрос могут тратиться даже не минуты, а часы и даже дни. Но за счет асинхронного API время работы обработчика по существу пофиг, его состояние нужно только держать в памяти, зачастую персистентной, чтоб если ноде киржык другая нода подняла и ничего снаружи не было бы заметно.
И это тоже какая-то очень странная специфика, которая не повторяется практически нигде. Если вы не в курсе, то сейчас >95% (если не >99%, не помню точно цифры) это потоки медии и HTTP всех видов, как веб напрямую, так и API+RPC поверх HTTP транспорта. А там запросы длительностью в часы и дни тупо нереальны.
В общем, немного интересно, где вы нашли такую дикую комбинацию свойств местности, но это никак даже не третий по типичности вариант
Здравствуйте, netch80, Вы писали:
N>В общем, немного интересно, где вы нашли такую дикую комбинацию свойств местности, но это никак даже не третий по типичности вариант
Ну, относительно соединений — в геймдеве соединение как минимум иногда считается так, как я сказал. Как минимум для мобильных или браузерных гриндилок, для танчиков там другой механизм. Никакой сокет не блокируется, игрок быстренько отдал данные, быстро получил. Все API stateless. В запросе передается UUID игрока, ну и дополнителько контрольная сумма пакета по хитрому ключу, на сервере, чтоб игроки не читили, если контрольная сумма не совпадает, игрок автоматом отправляется в бан.
Здравствуйте, elmal, Вы писали:
E>Здравствуйте, netch80, Вы писали:
N>>В общем, немного интересно, где вы нашли такую дикую комбинацию свойств местности, но это никак даже не третий по типичности вариант E>Ну, относительно соединений — в геймдеве соединение как минимум иногда считается так, как я сказал. Как минимум для мобильных или браузерных гриндилок, для танчиков там другой механизм. Никакой сокет не блокируется, игрок быстренько отдал данные, быстро получил. Все API stateless.
Тогда это, скорее всего, UDP.
E> В запросе передается UUID игрока, ну и дополнителько контрольная сумма пакета по хитрому ключу, на сервере, чтоб игроки не читили, если контрольная сумма не совпадает, игрок автоматом отправляется в бан.
Здравствуйте, netch80, Вы писали:
N>Ну там точно нет многосуточных запросов
Там могут быть тяжелые фоновые задачи вроде полного пересчета статистики. При этом запрос на получение статистики отрабатывает мгновенно, только не возвращает локальную статистику, а результат полного пересчета будет виден сильно позднее, там будет возвращаться предыдущее значение.
