И ещё вопрос из разряда "надежды на ответ мало, но

я все же спрошу"
Кто-нибудь использовал mORMot с Лазарусом под Линухом.
Справляется ли этот "Сурок" в Лазаре под Линухом с хорошей нагрузкой? Особенно с большими потоками бинарных данных?

Ну и вообще из разряда "таких не бывает".
А не сравнивал ли кто этого Cурка с gRPC, если ваять сразу на альтернативном .NET Core ?

ПО первому пункту - была информация прям здесь. Типа на 2-3 месте среди ВСЕХ движков по производительности получился.

Автор mORMot создал новый менеджер памяти под fpc, под x64. Почти такой же шустрый как FastMM4, в разы лучше чем стандартный в fpc. Думаю, должно все летать.

Стикер

Да, спасибо за инфу. Будем посмотреть... Стоит задача в создании сервера приложений в новом проекте. Но теперь он должен быть кроссплатформенный и по хорошему пройти будущую проверку на включение в ЕР ПО Собственно пока вижу два пути: Lazarus + mORMot либо .NET Core + gRPC И Delphi/FPC или C# знаем на очень хорошем уровне. Поэтому выбор с языком и средой тут не проблема. И там и там есть свои + и - Но хрен угадаешь на начальном этапе, кто потянет, а кто больше геморроя потом доставит 😉 по всем вопросам.

Мы переписывали сервер с Delphi на C#, потому что Delphi сервер не мог загрузить все ядра\потоки, которые ему давали.

А на Delphi при этом что использовалось в качестве серверных библиотек? Или все самописное поверх винсокетов?

RemObjects

Remoting SDK ?

Да. это https://www.remobjects.com И для Delphi и для C#

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

Я пару месяцев назад пытался разобраться с mORMot. Сложилось ощущение, что ещё не дорос. Вспоминается, как мы работаем с fgx-native. Постоянно приходится Ярослава дёргать, т.к. нихрена ничего не понятно (хотя по видосам все очень красиво). Так и с mORMot видимо люди работают. Вроде и документация есть, а что с нею делать - непонятно.

А с тестовой нагрузкой справляется? Или у вас задача максимально прогревать железо? Я это к тому, что не везде нужно паралелить и грузить ядра по максимуму, особенно в бизнес-задачах. Это скорее наоборот, признак плохого дизайна.

угу. в результате сишарпы загрузили проц бесполезной нагрузкой 😂

Нам нужно была полная утилизация мощности.

Delphi конечно же может легко загрузить и 24 ядра, по опыту. главное что бы было во-первых чем, во-вторых что бы нагрузка была реально полезная, а не лишь бы работало

Я не про пустую нагрузку, а про количество одновременно обрабатываемых подключений и количества запросов в секунду на них.

Значит мы нубы были, если не смогли.

.... неважно чем 😂

Я про эту проблему достаточно подробно писать в статье https://github.com/loginov-dmitry/multithread/blob/master/multithread_net_programming.md

Я уде написал ниже.

Да, признаться, та же фигня. Простыня там просто колоссальная. Еще мне не очень понравилось, что они явно склоняют к своим объектам на variant-ах НО все бы можно потерпеть, если это реально хороший вариант

Загрузить все процы можно на чём угодно. А вот сделать эффективно не факт. Многопоточное программирование очень сложная тема

это да, это да

Статеечку подкинуть, где тестировали? Или сами погуглите, про DataSnap и прочих. Короткий вывод: DataSnap он же ClientDataset он же Midas писался так, чтобы людям с опытом dBase/Paradox было удобно и мозг не напрягать. Многопоточность как могли сделали. Получилось так себе. Тот же node.js сделанный вообще на основе Google Chrome сервер на основе datasnap заруливает на хрен. Кстати, он по памяти и шарпастый сервер тоже зарулил, хотя и не с разгромным счётом. Потом взяли либу mORMot, которая наоборот писалась от основ под максимум скорости и не пытаясь быть похожей на примеры из стопиццот учебников и FAQ, и после того как написало уже наоборот, дельфа всех размазала. Так что как и везде, вопрос так ли уж если на вам нужна скорость, или удобство поддержки. И если нужна - то нужно использовать соотв. структуры программы и библиотек.

Напрасно вы. Даже по синтетическим тестам .NET Core как минимум не медленее дельфёвого кода. (ох, боюсь, что сейчас начнётся - как попы запылают) 😀😂 Но факт есть факт. Сам был в шоке еще лет 5 тому назад. Так что это во многом уже дело вкусовщины

Не понял про что, но претензии были не к прослойки БД.

Так даже JS не медленнее. Давно известно, что 80% скорости - это "алгоритмы и структуры данных" и только потом начинаются уже ассемблерные вставки и прочее. Половину программ БД на Дельфи можно раза в два ускорить тупо проходя по всем цикла и убирая из них fieldByName и аналоги.

Тогда читать стоило про Omni Thread Library (в привязке к дельфе) и про Erlang и вообще Actors Model Суть в том, что потоков должно быть ровно по числу ядер, а не числу запросов. Хотя типовый примеры с TThread предполагают обратное

Еще если тупо const для string-овых параметров в часто используемых процедурках проставить, то +/-10% к производительности запросто получить можно

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

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

Очень давно пользовался им. Он же вроде только под VCL ?

Нет. Там и для C# и для Java и ещё для чего то.

Эти синтетические тесты (Scimark) одинаковы для Delphi и C# и адаптированы даже с учетом языка. Я даже помнится правил integer на nativeint в Дельфях, чтобы чуть быстрее тесты работали. Попугаев оба современный Delphi и .NET Core набирают почти одинаковых. А вот С++ уделывает обоих с разгромным счётом.

Причем тут си и джава? Я про дельфи говорю. Что там было только vcl - нет fmx

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

Тут наверное ответили уже в чате, но на буржуйском чате писали: многие использовали. И тут вроде. Но, я к примеру, юзаю Brookframework и Brook4FreePascal. С нагрузкой справляется. Сейчас на одном виртуальном сервере крутятся уже более 20 тысяч сайтов/доменов. Открываются быстро, админка работает тоже достаточно быстро. В сравнении с несколькими PHP сайтами просто даже не сравнить. Максимум на 5-10% загружает процессор этот менеджер.

Не, товарищ, ни разу не работавший с WEB, REST, серверами приложений, стартанул успешно. Я ему на выбор несколько фреймворков давал. Сейчас уже порядка 5+ сервисов.

Стикер

Ну, да. Там особенности есть. Непривычно. CustomVariant, Record, везде свои типы. + маниакальная помешанность Арнауда на производительности.

Мне MARS понравился, но он без встроенного ОРМ

Есть прямые и понятные фреймворки. Вот прям вообще как 2 байта. Но это точно не про mORMot.

Попы не пылают, пылают еретики! Извинити.

Очень точная характеристика.

Daraya написана "в лоб" Плюс еще дофига. https://t.me/Delphi_Lazarus/243296

Попробуй потестить МАРС. там действительно удобно, если разобраться немного. Была б дока - было бы ещё лучше

Я много чего смотрел. 😊

Есть ссылка на этот МАРС?

https://github.com/andrea-magni/MARS

https://t.me/Delphi_Lazarus/238150

Там если что есть две версии продукта: работающий только в FreePascal - это соответственно Brook4FreePascal. Не использует внешних библиотек. Все сам, как говорится. И есть новый форк, которые работает микроHTTP сервере с помощью sagui (библиотека также автором этих библиотек, но на C++) - это BrooFramework - работает и на Delphi и на FreePascal и можно использовать из BrookFreePascal в легаси режиме

С базами он тоже прекрасно работает. FireDAC подключает сам и контекстно его инжектирует в роут. Удобно шо капец

Hemul GM
Рекомендую вот эту Демку

Угу. Гляну

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

Короче, под свой фреймворк буду собственный лисапед придумывать 🙈😂

для сети он какую библиотеку использует?

Инди для HTTP или DCS (там вроде веб сокеты)

Странная причина :) Мы вот переписали на C# потомуша там ASP.NET и тупо вебморду удобно делать, а с потоками в дельфе небыло никогда проблем :)

А потом мучительно вспоминать, что же за поле скрывается под именем Field[101]? 😁

Это когда вместо того чтобы подумать, просто взял выхлоп иды и скомпилировал его?)))

можно делать хитрее. предварительно один раз присваивать временные, локальные поля с помощью FildByName, и потом их юзать. у меня местами так и работает

ЕМНИП, там фишка в том, что значение по FieldByName получается медленнее, чем по номеру поля в датасете. Т.о., ты ничего не выигрываешь таким способом. :)

Док, конечно по номеру быстрей. Но если бежишь по большой выборке, разница небольшая, зато если поменяешь запрос, то не будет ошибки

MyField:=Tb.Fields[1]; и MyField:=Tb.FieldByName['Id'];

Ну...ты можешь заюзать чёт типа rtti, в смысле - хранить в поле класса нужный номер поля, а поле класса называется осмысленно же)

И дальше использую MyField, разница будет?

Да, второе не странслируется)

я про доступ к полям в циклах (не только, но в основном) вместо while not Eof .... if FieldByName('test').AsString = '+' then .... можно написать: Field := FieldByName('test') while not Eof .... if Field.AsString = '+' then ....

enum

А я думал, что оба в одно место ссылается...

а поподробнее можно? а то меня помнится тоже за это критиковали

type FInx = ( f_ServerID, f_ID, f_DeviceID, f_DevLogID, f_SpdDT, f_TAS, f_Num, f_TCode, f_UCode, f_ECode, f_ValSize, f_Val );

так это ж надо четко знать порядок расположения полей для такого подхода, верно?

угу. потом завтра внезапно поменялся запрос и....

это же твои запросы, не? в чём проблема

Так и не понял: MyField в обоих случаях указывает на один объект или на разные?

А что делать, если в двух таблицах одинаковое название колонок?

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

Мне не надо, меня от FieldByName не трясет.

Меня вот кстати тоже) Никогда не парился насчет этого

ну вот когда затронет оптимизация - тогда затрясёт

Ностальгия... В одной строке - 18 FieldByName. В цикле второй вложенности. Во времена D3-D2005, когда сама по себе FieldByName это O(2). Еще и .Value. Переписал. Ускорение в 48 раз.

может и есть места где критично. в 'обычном коде' - чаще нет, максимум - циклы, и то...

вот циклы - да

я тут больше могу сказать. вполне возможно что если это всё утащить на строну бд в хп, то ускорение было бы и еще раз в 2-10 😂 по опыту, так сказать. но, понятно, бывают варианты

Это тоже функция, этого в больших циклах тоже не надо. Var F1, F2,... F101: tField; и все сразу понятно :)