Пробвай и с netcat/nc.

То на мен всъщност ми трябва да е по http - заради cloud, rest & friends
Иначе максимума на етернета го измерих с iperf3 - 950мбита ...

Точно натъманявам веб клиента с който ще се управлява цялото чудо и ще си го изтествам през него.

въпросче:
има ли fork() някакви "подводни камъни"

тук форка е за system() искам да я пусна( system ) в "нов процес" без да я чакам

тва парче си бачка с чакане и без чакане...
ето три бенача с чакане на завършек между curl, node и python - и трите правят едно и също - HTTP POST data


[SRV] SCRIPT curl -d '{"PROTO":"MQTT-ESP","CLIENT":"client","STATE":1"}' -X POST http://192.168.0.100/
{"PROTO":"MQTT-ESP","CLIENT":"client","STATE":1"}{"DONE":0}
[SRV] ELAPSED ( 25 ms )

[SRV] SCRIPT nodejs ./wiz_node/test.js client 1
[NODE-RES] {"PROTO":"MQTT-ESP","CLIENT":"client","STATE":1}{"DONE":0}
[SRV] ELAPSED ( 462 ms )

[SRV] SCRIPT python ./wiz_python/test.py client 2
[PYTHON-RES] {"PROTO":"MQTT-ESP","CLIENT":"client","STATE":2"}{"DONE":0}
[SRV] ELAPSED ( 109 ms )

Направи ми впечатление, че node захапва бавно в началото - според колко ти е бърза системата на която пускаш може да отнеме от няколко стотин милисекунди до няколко секунди. Та логично ще получиш различни резултати ако пускаш непрекъснато нови процеси в сравнение с един постоянно работещ процес който да обработва входящите заявки. Т.е. в тези резултати които си измерил ноде и питон са по бавни заради бавният им старт а не, че кой знае колко по бавно обработват мрежовите заявки.

забележка: линукса ми е на виртуалка, реалните времена са делено на 2 и повече, а локал хоста на линукса е форварднат към виндоуса, така че горе времената са завишени

правя го тоя плъгин за да премахна други "слушащи" процеси освен apache, mosquitto и database....
за да не усложнявам "облака" <---- една машинка за 100...200 клиента, повече не ми трябва
реално са под 100 клиента с темп на логване на данни през една минута, демек имам запас една секунда да бавя москитото
форка() ако работи добре, значи ще бавя брокера с почти нищо (филтриране не топици, това да това не)

нода, питона... са само за тест на възможности за изпълнение на външни скриптове
иначе си имам дефол С HTTP POST вътре в плъгина, по локал хоста до апача ми е под мили секунда

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

поите 5 стинки:
- пусни си нейтив лайнукс
- намери машинка с повече ядра (скоро си купих за 900лв 24)
- пусни си толкова тредове, колкото ядра имаш. после не ги гасиш, само ги храниш с данни

ахам, ама да завърша сорса

на виртуалката убунту десктоп с 4 гиги рам - 200 форка в секунда работи "чудесно"
при натив http post с libcurl е най-бързо и лапа най малко рам образно казано почти нищо
обаче пусна ли да форка външни скриптове 8 меги на таск и средно 10 пъти по бавно(за срипта)
иначе бави брокера с под мили секунда за филтриран топик с пост навън

за мойте цели тва са и езцепка с 200 поста в секунда... товаря да вида какво става
мен ми трябват 2 в секунда денонощно
сигурно ще работи и на малинка или с оная платка ( горе в поста ) с външно SDD за база-данни

утре може да натоваря една малинка да видя ко става там, ама тряя да напиша някъв "флудер" да я товари

ДедоБоре да няма грешка - 24 ядрения EPYC е на поне двойна цена. Или не става въпрос за x86... в такъв случай кой е чипа?

2 х X5650 , т.е. 2 х 6 х 2.
за тредове става

ебавки с малината

Ясно, зачудих се понеже QCOM и още няколко се бяха заканили преди време да пускат 24 ядрени АРМ чипове с Линукс поддръжка, но от тогава не съм чул нищо. А би било интересно като "cloud at the edge" решение.

аднах му и секюрити чек към http post

sytem("външен скрип") го направих по избор за филтър-топик
виндоус/линукс
0 чака да свърши
1 thread не чака
... само линукс
2 fork() чака
3 fork() не чака

Ей, лесна е твоята - аз каква греда ударих днес ... пуснах 150 RPi-та да буутват едновременно по мрежата и всичко умря. На предварителните тестове 10-15 малинки си буутват без проблем но като пуснах да тествам на макс и просто се гътна. Някакъв DoS ли нацелих, какво ли, нямам идея - ни съобщение за грешка, ни работи ... уж последно оптимизирах power cycle да става в паралел на всички портове и вместо подобрение то стана назадък.

иначе нативна машина ( win7 / 4 cores ) латенцията на плъгина към нативно HTTP POST над 1000 заявки в секунда
което си е супер за "малки" проекти

То от една страна е ОК ... от друга е трагично ... машина дето уж прави по 3-4 милиарда инструкции на ядро, да и се кефим, че е успяла да направи 1000 простички транзакции в секунда ... едит: при това с 4 ядра ...