Best Practices for HA Applications
Writing JavaScript correctly and reducing round trips to the ThingWorx Platform will always help improve performance. To support high availability cluster mode in ThingWorx 9, the storage and use of the model changed and a shared-state mechanism to keep data synchronized across the servers was implemented. These changes have an impact on the performance of certain APIs since they do more work than before to retrieve the same information. Code that was not previously optimized for performance may be much slower in ThingWorx 9 and could be very slow in a clustering environment.
• Model information is no longer stored at the Thing; the system walks the model tree every time to get the model information. All APIs that retrieve Thing information are impacted.
• All JavaScript service states are now stored in a cache layer.
◦ In single-server mode, it is an in-memory cache that is fairly fast but has more overhead than just storing in the Thing object. When running in cluster mode, the cache is distributed, and each call will do a round trip to a remote host. This can add latency to calls and is not easily controlled.
◦ The cache layer can be local or remote. The new system creates a one-way proxy from the JavaScript object back to the original object. Therefore, every change to the JavaScript object triggers a full update of the property in the original object. And, changes to the original object are not reflected in the JavaScript object.
Everything should be treated as a remote object. With remote objects, you want to make as few calls as possible across the remote gap to remove latency. The same approach should be taken when calling APIs on the server. Less calls are better.