Optimale Vorgehensweisen für HA-Anwendungen
Das korrekte Schreiben von JavaScript und das Reduzieren von Roundtrips zu ThingWorx Platform tragen immer zur Verbesserung der Leistung bei. Um den Cluster-Modus für hohe Verfügbarkeit in ThingWorx 9 zu unterstützen, wurde die Speicherung und Verwendung des Modells geändert und ein Mechanismus mit einem geteilten Status implementiert, damit die Daten auf den Servern synchronisiert werden. Diese Änderungen wirken sich auf die Leistung bestimmter APIs aus, da das Abrufen derselben Informationen aufwändiger ist. Code, der zuvor nicht für Leistung optimiert war, ist in ThingWorx 9 evtl. viel langsamer und in einer Clustering-Umgebung sehr langsam.
• Modellinformationen werden nicht mehr im Ding gespeichert. Das System durchläuft den Modellbaum jedes Mal, um die Modellinformationen abzurufen. Alle APIs, die Dinginformationen abrufen, sind betroffen.
• Alle JavaScript-Dienststatus werden jetzt in einer Cache-Ebene gespeichert.
◦ Im Einzelserver-Modus handelt es sich um einen relativ schnellen Arbeitsspeicher-Cache, der aber mehr Overhead aufweist als beim reinen Speichern im Dingobjekt. Bei der Ausführung im Cluster-Modus ist der Cache verteilt, und für jeden Aufruf erfolgt ein Roundtrip zu einem Remote-Host. Dies kann zu Latenz bei Aufrufen führen und ist nicht einfach zu steuern.
◦ Die Cache-Ebene kann lokal oder remote sein. Das neue System erstellt einen unidirektionalen Proxy vom JavaScript-Objekt zurück zum ursprünglichen Objekt. Jede Änderung am JavaScript-Objekt löst daher eine vollständige Aktualisierung der Eigenschaft im ursprünglichen Objekt aus. Und Änderungen am ursprünglichen Objekt werden im JavaScript-Objekt nicht widergespiegelt.
Alles sollte als Remote-Objekt behandelt werden. Bei Remote-Objekten möchten Sie so wenige Aufrufe wie möglich remote durchführen, um Latenz zu vermeiden. Derselbe Ansatz sollte beim Aufrufen von APIs auf dem Server verwendet werden. Weniger Aufrufe sind besser.