Henke hat geschrieben: ↑29.09.2023, 15:31
Ich rufe bei meinen Test die Rega über Port 8181 (da extern) auf und habe das Parsen der Rückgabe nach "<xml>" deaktiviert und diese Zeiten nicht mitzuübernehmen. Daher würde ich den Fehler definitiv eher in der Rega vermuten.
Also ich hab mir das nun nochmal angeschaut und mal diesen Skript direkt auf der Zentrale an Port 8183 mit folgendem bash/curl Skript schicken lassen:
Code: Alles auswählen
#!/bin/sh
read -r -d '' VAR <<- EOM
time start = system.Date();
WriteLine("START: " # start);
string out = "";
var ii = 0;
while ( ii < 2000)
{
out = out # '""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""'; ! SLOW
!out = out # "''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''"; ! SLOW
!out = out # ^""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""^; ! SLOW
!out = out # '"device":{"12345":{"title":"0-Außen Beleuchtung","mac":"xxxxxxxxxxxxxsss","iface":"HmIP-RF","type":"HmIP-BSM",'; ! FASTER
!out = out # 'AAAAAA, BBBBBBBBBBBBB, CCCCCCCCCCCCCCCCCC, DDDDDDDDDDDDDDDD, EEEEEEEEEEEEEEE FFFFFFFFFFFFFFFFFFFFFFF EEEEEEEEE'; ! FASTEST
!out = out # 'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA'; ! FASTEST
ii = ii + 1;
}
! Write(out);
!out = ""; ! comment out for speed?!?!
time end = system.Date();
WriteLine("DONE.: " # end);
EOM
time curl -q http://localhost:8183/hm.exe --data-raw "${VAR}" | wc -c
Und was soll ich sagen? Es ist genauso wie ich mir gedacht hatte: Durch diese vielen Anführungszeichen bzw. Sonderzeichen die am Schluss in der Ausgabevariable "out" landen kommt es zu einer massiven vergrößerung der Datenmenge die am Schluss zum Client via HTTP / Netzwerk übertragen werden müssen.
Hier z.B. das Ergebnis des Skriptes so wie es oben gezeigt ist:
Code: Alles auswählen
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 1290k 100 1289k 100 1193 792k 733 0:00:01 0:00:01 --:--:-- 793k
1320251
real 0m 1.63s
user 0m 0.00s
sys 0m 0.00s
Wie man sehen kann werden dort rund 1,3 MB an Daten zurückgeliefert und die müssen halt erst einmal beim Client ankommen. Und auf meiner Test-RM dauert daher die Ausführung des "curl" befehles rund 1,6 Sekunden wie man sehen kann.
Lässt man nun jedoch am schluss die "out" Variable eben wie besagt leeren vor Beendigung des Skriptes kommt das hier raus:
Code: Alles auswählen
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 1443 100 251 100 1192 3478 16521 --:--:-- --:--:-- --:--:-- 20041
251
real 0m 0.08s
user 0m 0.01s
sys 0m 0.01s
Ergo braucht dann das curl kommando lediglich 8 Millisekunden, eben einfach weil der Rückgabedatenstrom dann gerademal 251 bytes sind.
Konkret sehen dann die Rückgabedaten wie folgt aus:
Code: Alles auswählen
<xml><exec>/hm.exe</exec><sessionId></sessionId><httpUserAgent>User-Agent: curl/8.2.1</httpUserAgent><start>16:52:13 29.09.2023</start><out></out><ii>2000</ii><end>16:52:13 29.09.2023</end></xml>
"out" ist also leer. Wohingehend in dem oberen Fall ohne leeren von "out" die Ausgabe eben wie folgt aussieht:
Code: Alles auswählen
<xml><exec>/hm.exe</exec><sessionId></sessionId><httpUserAgent>User-Agent: curl/8.2.1</httpUserAgent><start>16:54:18 29.09.2023</start><out>"""""""""""""""""" [...]</out></out><ii>2000</ii><end>16:54:18 29.09.2023</end></xml>
D.h. es werden also run 1,3MB an """ in der XML Struktur mit zurückgegeben und die müssen wie schon erwähnt ja erst einmal beim Client ankommen. Und wie man an den Werten von <start> und <end> sehen kann liegt es eben nicht an der Verarbeitung von ReGaHss oder ähnliches. Dieser Unterschied wird also einfach eine Konsequenz der Datenmenge sein.
Was man ehrlicherweise aber auch sagen muss ist, das hier der Netzwerkspeed der Auslieferung der Daten selbst via localhost wie oben gezeigt wohl bei ca. 800k/sek. liegt. Es sollte da also in der Tat ggf. noch etwas Luft nach oben gehen was die Aufbereitung und auslieferung der Daten über den ReGaHss Webserver angeht. Auch sehe ich in weiteren Tests wenn ich einfach mal die Datenmenge noch wesentlich erhöhe das dann die CPU Auslastung der ReGaHss ziemlich in die Höhe geht und auch die Memory Auslastung. Der integrierte Webserver der ja in ReGaHss ziemlich rudimentär umgesetzt ist wird also mit solchen Datenmengen ggf. ein Problem haben und vielleicht kann man hier wirklich noch etwas rausholen. Müsste ich mir in der Tat dann mal in Ruhe im Quellcode anschauen.