Ich entwickle mit XOJO 2022 R 1.1 auf dem Mac mit macOs 12.4 und unter Windows 11.
Der Kunde hat eine Windows 10-Umgebung.
Ich habe 4 Apps die über TCPSocket miteinander kommunizieren.
- Client ist die Optometrie.app
- Server sind die Pentacam.app, die GDT-Navis-Ex.app und die TonorefIII.app
Die Client-App ermittelt über einen URLConnection Daten von einem Windows-Server
in einer MS-SQL-DB und ruft dann die Server Pentacam, GDT-Navis-Ex und TonorefIII
zur Ergänzung der Daten auf.
Die Pentacam.app und die TonorefIII.app liefern Zeichenketten mit weniger als 100 Bytes.
Die GDT-Navis-Ex.app liefert sechs Bilder mit einer Gesamtgröße von ungefähr 1,5 MB.
Wenn jetzt die vier Apps gestartet und über die Client-App Daten von den Servern anfordern,
dann ist die Verarbeitung innerhalb einer Sekunde erledigt.
Wenn jetzt aber auf dem Windows-Rechner mit der Optometrie.app (Client) 1 bis 2 Minuten oder länger nichts passiert, dann benötigt die Antwort 4 bis 7 Sekunden.
Kann es da irgendetwas geben, das in dieser Zeit “einschläft”?
Wenn ich dasselbe mit der Optometrie-App aus macOS heraus mache und die Server unter Windows
laufen lasse, dann gibt es keine Verzögerung. Der Kunde hat eine Windows-Umgebung und hat
immer die Verzögerung.
Ich gebe mir auf allen Apps ein Testprotokoll aus. Im Fall der Verzögerung sehe ich, daß
sekundenlang nichts passiert und dann erst nach den 4 bis 7 Sekunden die Anfrage auf den
Servern ankommt. Die Antwort ist dabei ganz normal schnell. Mache ich nach so einer
Verzögerung gleich noch eine Anfrage, dann kommt die Anfrage auf den Servern sofort an und
die Antwort ist wieder innerhalb einer Sekunde da.
Beim Mac legt das System genre Prozesse schlafen.
Das kann man z.B. per MBS Plugin ändern mit der NSProcessInfoMBS class:
dim Activity as NSProcessInfoActivityMBS // property in your window, control, thread, app
dim AllowAppNap as boolean // allow or not?
dim ProcessInfo as NSProcessInfoMBS = NSProcessInfoMBS.processInfo
if AllowAppNap then
Activity = nil
else
// disable sleep to let us make something...
Activity = ProcessInfo.beginActivity(NSProcessInfoMBS.NSActivityBackground, "Backup running")
end if
Ich kenne das Verhalten der URLConnection unter Windows. (auf dem Mac läuft das).
Ich hab das auf Curl umgestellt (MBS) … läuft.
Ich habe das Problem scheinbar nur mit dem TCPSocket unter Windows.
Hattest du nicht geschrieben
Die Client-App ermittelt über einen URLConnection Daten von einem Windows-Server
Dann hab ich das missverstanden.
Ja schon.
Nachdem die URLConnection aufgerufen wurde werden die Server über die TCPSocket’s aufgerufen.
Für ein besseres Verständnis wollte ich nur den kompletten Ablauf skizzieren.
Und sicher das nicht der Aufruf der URLConnection deine Anwendung ausbremst ? Bei mir hat der Aufruf per URLConnection die ganze App komplett unresponsiv und hackelig gemacht. (Egal ob sync, asyn, im thread usw).
Die URLConnection hatte ich nie in Verdacht. Ich muß das mal ausprobieren.
Ich werde dazu mal die Server-Aufrufe abklemmen und testen was nach einer Wartezeit dann passiert. Das kann ich aber erst heute Abend oder morgen früh angehen.
Das hat mir jetzt keine Ruhe gegeben, daher habe ich den Test vorgezogen.
Das hier ist ein Protokoll aus der Optometrie-App (Client) im Windows.
In dem unteren Kasten sieht man die Aufrufe aus einer Methode in der Optometrie-App. Man sieht, daß die Anfrage um 15:08:31 begonnen und beendet wurde.
Im oberen Kasten sieht man den Erhalt der Antwort im jeweiligen TCPSocket im Ereignis DataAvailable. Da sieht man schon, daß die Antwort um 15:08:34 also drei Sekunden später gekommen ist ( ich hatte jetzt eben einmal 11 Sekunden!!).
Das sind jetzt drei Bilder aus dem Protokoll der Server (leider etwas klein geraten):
Man sieht hier, daß die Anfrage um 15:08:33 also erst zwei Sekunden später bei den Servern angekommen ist.
Die URLConnection ist im unteren roten Kasten mit “GetKundenNummer Euronet Aufruf” und “GetKundenNummer Euronet Antwort”. Sie ist wie es scheint nicht der Grund für die Verzögerung.
Hier im Beispiel habe ich jetzt “nur” drei Sekunden Verzögerung, es können auch mal 6, 7 oder 11 Sekunden sein.
So ist das schwer zu sagen … da müsste man parallel z.B. mit Wireshark einen Trace haben um das genau zu sehen.
Ich war soweit das die native URLConnection unter Windows den gesamten TCP Stack irgendwie ins “stocken” gebracht hat. Ich habe alles am Mac entwickelt und war dann aus allen Wolken gefallen wie meine ganze Anwendung unter Windows gelaufen ist wie ein Sack Muscheln.
Wenn du eine MBS Lizenz hast, vielleicht ist es den (ich denke überschaubaren) Aufwand wert das mal umzustellen. URLConnection → MBS Curl ist überschaubar. Ich denke es gibt auch TCPSockets … hab ich aber von MBS noch nicht verwendet.
Ich traue dem nativen Xojo Netzwerkstack (unter Windows) aktuell nicht über den Weg ;-).
Vielleicht kannst du dir auch einen Dummy zum Test bauen.
Ändern muß ich was. Ich hatte so die Idee das es am Verhalten des TCPSocket unter Windows liegt. Ich hatte auch schon mal Performancemessungen für die einzelnen Programmteile eingebaut. Die Dauer der einzelnen Routinen erklärt nicht die Gesamtdauer des Vorgangs.
Ich muß mal drüber nachdenken und dann schaue ich was es da für Alternativen gibt.
Danke für die Unterstützung!
Ich habe zu dem Thema den Issue #69229 eröffnet.
