Alexey Maslov,

Да Windows держит. И нормальная реализация Job'ов, не тупорылая многопроцессорная херня, а своя vm которая асинхронно всё делает (и еще как-то разделяет, не суть).

Alexey Maslov,

Проблему 10к (которая в современности уже вроде 10kk, но не суть), чисто на эме как решать? Плодить 10k процессов? Городить свою асинхронную очередь? Это рамки которые ограничивают.

Агитируете, вы же говорите - "у нас норм". Интересно в цифрах, сколько джобов работают на сервере одновременно, на сколько логика погружена в этот самый эм (не торчит ли там большой кусок на "яве" (не суть на чём) сбоку), не является ли Ваш код callback-hell, не храните ли вы состояние сессий в глобалях между этими callback. Да и вообще - фронтенд накладывает отпечаток, смотря подо что ваш бэк.

Я не противопоставляю MSM кэше конкретно. Я ж не говорю что каше говно. Я утверждаю что разделение job по процессам ОС - путь к кладбищу для M, т.к. для решения современных задач надо уметь в BigData не только как хранилище, но и как ЯП, а твой наш "BigData" ограничен кол-вом лицензий на сервер, если ты ВСЁ хочешь делать на эме. По моему очевидно. Смысл менять MSM если та же каше или GT.M тебя загоняет в новые рамки, избавив (ли?) от старых. M очень прогрессивный язык, но архитекторы разных реализаций пошли по шаблонному устаревшему пути. Не важно по каким причинам, не сомневаюсь что они были очень вескими.
На мой взгляд пришли к тому что "А смысл развивать выразительность M?" Для программирования в стиле "быстрая замена SQL" его хватает за глаза. Никто ж не будет браться за серьёзный проект держа в голове только M (хорошо, кто-то может будет (удачи ему), я бы точно не стал).
Надеюсь развёрнуто пояснил, может сумбурно - вечер перед выходным настраивает на лирический лад.

ну я,
>Видимо, многопроцессорная -> многопроцессная?
Да, простите.

Alexey Maslov,

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

LittleCat,

Такой интерактив - он не про хранение сессий в глобалях, это просто не удобно и медленно. Надо менять парадигму программирования. А временная информация должна лежать в локальных переменных, персистентная - в глобалях, всё же просто.
Оно конечно можно всё распихивать в глобали, на каждый запрос поднимать и обратно складывать, но это решение от безысходности. Или решение "потому что мы всегда так делали для вэба, у нас же запрос-ответ".

Нет таких M реализаций которые дадут тебе нормальную виртуальную машину (не важно, либо с green threads как в MSM либо a-la asyncio под капотом) которая позволит без стеснения одинаково обрабатывать хоть сотни хоть сотни тысячи запросов коннектов и не заниматься переливаниям порожняка временных сессионных данных туда-сюда, с принудительным дроблением нормальных, понятных бизнес-алгоритмов на "коротенькие" процедурки (так что бы клиент не отвалился по таймауту) или под свои "ой да написать мапсисту очередь раз плюнуть" очереди. Следовательно, смысл что-то менять? Что MSM - кусок старого говна, что альтернативы - такие же, только дата компиляции посвежее. Как-то-так.

Сейчас, что бы стать стильным модным молодёжным - надо уметь в асинхронность. И не такую разноцветную как в тайпскрипте каком-нибудь или питоне, а в нормальную, когда прикладник и не в курсе что он делит процессор с соседями (примерно как в Stackless Python). Казалось бы, идеология M идеально ложится в это - много мелких простых запросов - удобно параллелить, оно прямо просится само. Но нет, доминация подхода "как в SQL" - монстропроцесс-конвеер который будет перемалывать запросы. Еще бы блин на каждый Job - юзера в системе создавали, ну что за люди... (ну что за люди эти банкиры с их безопастниками, я сейчас подумал что и такое может быть).

Хотя вот YottaDB в ту сторону вроде двигается, слежу с замиранием сердца. Как только смогут в асинхронную очередь работать внутри своей .so с прокидкой хвостов наружу (или наоборот - внутрь в своей очереди) - всё, это победа, прикручивай любой современный язык и рви всех в клочья. Их скорее всего стопорит проблема с транзакциями.

Извините за оффтоп, M люблю но от состояния дел в современном эме - боль. Потому что современного эма нет. Во всех смыслах: что в реализациях что в стандарте.

Я когда услышал про 2020 - обрадовался, неужели?.. А оно там как, за последние 25 лет хвосты подчистить, ничего нового никто не предлагает? Ну прям такого что огого, типа итераторы поинтересней по деревьям, или там объектные нотации какие-нибудь? Революция будет, не побоюсь этого слова? Или как обычно - пока сам не сделаешь, никто не сделает?

Зачем хранить временную, никому не нужную кроме как этому конкретному коннекту информацию в кэш? А чё-бы кэш не занимать только той информацией которая нужна всем? Чего бы временной локальной информации не жить в локальных переменных, для этого придуманных? С подходом один процесс как молотилка очереди запросов - локальные перемененные алгоритма который выполнялся бы сверху вниз слишком долго (а это "долго" определяет параметр таймаута HTTP, да не важно кто - ограничение некое сверху) переносят в разряд "сессионных данных", дробя этот алгоритм на последовательность запросов. Понимаете к чему я? А можно жить в своём джобе и вместе с тем пока собираются данные отдавать что-то клиенту по чуть-чуть, держа его в тонусе, и при этом не погружаясь в салатный код из колбэков.
Я Вам говорю что то, что вы называете "сессионные данные" - у Вас не полностью из них состоят. В силу архитектуры монстра-молотилки вы туда еще складываете состояние алгоритма, и делаете потому что по другому никак. Потому что ваш бизнес-алгоритм расхристан стейт-машиной посредством колбэков. И считаете это норм. Потому что по другому на текущих реализациях эма нельзя. А я вот говорю что это нихрена не норм. Слишком много бесполезных (ибо порождены ограничениями реализаций) абстракций и поэтому слишком далеко от железа.

А насчет "делить процессор" разве ОС не занимается этим сама, и вполне успешно ????
Вот разрабы всех современных реализаций видать где-то так же рассуждают. Вы меня читаете но не понимаете. Проблему 10k (которая, повторюсь, уже 10kk) тоже процессами собрались решать? Тут даже в потоках народ упирается, а Вы - процессами.
Как бы там ось не занималась "успешно" - хрень всё это, не поверю что парни из редмонда смогут написать лучше планировщик чем разработчик виртуальной машины под М - ведь именно разработчик знает все особенности языка, особенности работы с разряженным массивами, он точно сделает лучше. Процесс будет управляем, будет доступна приоритезация job'ов. Ну это все прелести зелёных потоков, не буду переписывать интернеты.
Есть и еще небольшой (не особо важный но приятный) бонус - при работе "во враждебной" среде (у конечного пользователя) если твой процесс запустился - аллилуйя, работаем пока не перегрузимся. Да да, не все живут в тепличных серверных условиях. Но это так, мелочь.

Вся прелесть асинхронной обработки в том что ты можешь позволить себе как белый господин программировать сверху вниз, программировать алгоритмы бизнеса ровно так как их тебе напишут люди из бизнеса, а не ломать голову "как бы мне тут раскидать по запросам, тут в очередь закинуть, тут в пул складывать данные, тут из пула отдавать данные". Хотя не сомневаюсь, что после некоторой практики такое само собой решается: салатный код лепится не задумываясь. И даже наверно потом норм читается.
Прелесть асинхронной обработки еще и в том что программировать можно одинаково, используя одни и те же практики и наработки для сервера любого уровня нагрузки - хоть на 10 юзеров хоть на миллион. Вот в этом разрезе Job на процесс - детский сад, меня это и бесит и умиляет одновременно.

Ой ладно вам, я уверен - вы скромничаете. Уж что такое callback-hell вы должны знать. И если программировать под вэб, в рамках "ответить надо быстро иначе клиент отвалится", то понимание должно быть что долгую обработку с интерактивом надо пилить на несколько этапов, если между этапами подразумевается некий интерактив с пользователем. А колбэк - это кусок алгоритма срабатывающий после того как та сторона (пользователь) ответит, и обрабатывает ответ, использует его в дальнейших рассчётах.
Монстр-молотилка - это процесс (в широком понимании) который обрабатывает очередь поступивших запросов.
Я за то что бы небыло запросов, а были свои джобы на каждое соединение которые бы обрабатывали персонально каждый коннект и ЖДАЛИ бы его при необходимости интерактива. Таким образом не надо будет пилить алгоритмы на куски.

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



Я же написал, мы с вами разное подразумеваем под временными данными. Вы, в силу того что привыкли к своей архитектуре распиленных бизнес-алгоритмов, считаете частью сессии то что, по сути, можно было бы к чертям потерять. Например, текущая итерация цикла прерванного для ожидания интерактива. Я так, абстрактно. Потому что у вас часть цикла в одной процедуре, а часть во второй, которая будет вызвана после ответа пользователя. И вот что бы вторая процедура продолжила нормально работу - вы храните состояние первой в сессии, ибо бедный (о чём все мои посты выше) инструментарий заставляет вас высвобождать драгоценные оплаченные деньгами джобы для обработки следующих запросов из очереди. С таким подходом у нас вообще нет выбора где хранить, если говорить только в рамках подхода обработчик очереди запросов. Где ж еще, если надо быстрее кончить и освободить джоб для следующего запроса? Какая разница, ну хотите пишите:
for ^sessions(ID,"x")=1:1:9000 s ^sessions(ID,"y")=^sessions(ID,"y")+1
Если чувство прекрасного вас обделило, хотите пишите поднятие/сохранение промежуточных данных в конце запроса.
О чём спор если по факту выбора-то нет?

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

>Таким образом, ИМХО, в локальных переменных стоит держать только то, что не страшно потерять в любой момент.
Ну тут невозможно и не зачем спорить. Это не ИМХО а прописная истина.
Вот только разрезанные интерактивом бизнес-алгоритмы в подходе "меня спросили - я ответил" вынуждены хранить в глобалях то что можно было бы потерять не парясь.

Но в принципе, абстрагируясь от сессий и всего о чём мы говорим, странная постановка вопроса про кэш. Как это какая разница, ведь одно дело держать в оперативке джоба, на кончиках пальцев, а другое дело - в расшаренном кэше, где помимо хранения и доставания данных будет еще код блокировки из-за того что оно расшарено между джобами? Это же лишний оверхед пока я работаю с моими данными. Моими интимными, больше никому не нужными данными одного конкретного соединения, возвращаясь к нашим баранам.
Это вы ловко ввернули, "при правильной настройке", а если неправильная? Тот подход за который я топлю если и требует отдельной настройки кэша сессионных данных, то этот процесс будет прогнозируем. Т.е. можно заранее прикинуть что вот столько юзеров и столько ТАКИХ-ТО данных, т.е. мы знаем что в нашем кэше сесси сиддят только данные сессии. А с подходом единого джоба-молотилки нам приходится держать в голове тот факт что в любой момент может появится интерактив внутри одного из бизнесс-процесса который заставит выгружать в этот кэш кучу данных по локальному состоянию этого алгоритма, т.к. он будет "разрублен" этим интерактивом. И вы такое не предусмотрите в жисть.


Я к тому что при подходе job=коннект_до_его_смерти программист волен решать и прикидывать - что лучше хранить в глобалях, т.к. оно скорее всего будет большим и неповоротливым если будет сидеть в оперативке, а что держать "горячим" в локалях. А при подходе который я критикую выбора-то и нет, повторюсь.

И еще раз, отскакивая в сторону, и немного мечтая, а неплохо было бы для джоба иметь некое хранилище для временных данных прошитое в стандарт. Что бы что-то крупное хранить на диске а не в оперативке, но без транзакций и шаринга, это должно быть видно только джобу. Вроде в cashe такое есть, специальная глобаль или что-то такое. Вот это точно в стандарт надо тащить. Это хорошая штука для тех данный сессии которые потенциально могут пухнуть.

Алексей, разверните пожалуйста эту мысль, что за обслуживание одного пользователя, кого вы под пользователем подразумеваете?
Вы про проблему что Job'=User, и если один мешок с костями подключается несколькими коннектами то может ими "забить" ядро? И в этом случае честный шедулинг затрудняется? Ну тогда каким боком это у вас "но" применительно к зелёным потокам? Как раз в концепции зелёных Job'ов мы может отдать прикладнику объединение джобов в виртуальные группы и уже эти группы шедулить по чесноку в разрезе процессорного времени и частоте запросов к диску. А вот в тупорылом подходе job=процессОС мы нихера не можем (ну если честно то можем, даже в последних виндах как раз можно группировать процессы, но это.. извращение, будем честны, для наших целей).



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

А Ваш аргумент получился в стиле "ваш самолёт не взлетит потому что у моей машины высокое лобовое сопротивление". Это если я правильно понял две предпосылки для вашего вывода "тупик".
Таки попытаюсь, еще раз: Вам сотрудник из Micronetics сказал что пробовали(сделали?) в натив треды.... И из этого вы сделали офигенный вывод что зелёные потоки "конечно же тупик"? Брр запутался. Т.е. они понимали что, мол, тупик, и сделали на тредах? А вы не в курсе подробностей? А хотите версию? Они понимали что ручной шедулинг джобов и единое адресное пространство - это орудие победы, и что бы ловить профит от нескольких ядер - сделали последний, логичный шаг: вместо одного потока который шедулит зелёные треды сделали по потоку на ядро? Т.е. каждый поток обрабатывает свои джобы. Именно то что я ожидаю от будущей БД мечты. Вот бы связаться с этим сотрудником и узнать.


>Почему она не увидела свет, думаю, объяснять не надо.
Вот хорошо внизу уточнили, а то я уже в конспирологию хотел удариться :-)