How does ThingWorx 9.x use Ignite ?

[seanccc]

Hi, 

Ignite was introduced since ThingWorx 9.0  cluster,  I want to know under what circumstances it will  be used. 

1.  Will the none-persistent property store in Ignite  ? whatever the data type is . 

2.  Will the performance of JavaScript service benefit from increasing the memory size of Ignite ? 

Regards,

Sean

[yhan · Accepted solution]

Hi @seanccc,

Thank you for reaching out to PTC.

"How does TWX 9.x uses Ignite" is a long story that it's hard to talk about in general without any specific question. However, if you would like to know it in detail I suggest you can refer https://ignite.apache.org/docs/latest/index

Answer your two questions:

1. Non-persistent properties of TWX are usually stored in the JVM heap. The logic in Ignite is to read the data of local node and put it into a cluster cache, and usually Ignite will keep data in their own off-heap memory regions. So from this aspect, the non-persistent properties will be stored in Ignite.
2. Take an example, if you run a query service against an Ignite cluster, the queries will access data and indexes stored in the off-heap memory while the result sets of such queries will be kept in Java Heap until the TWX application reads the result sets. So in this sense, the performance of JavaScript service will benefit from increasing the memory size of Ignite.

Thanks,

/Yoyo

[seanccc]

@yhan ,

One more question regarding to the none-persistent property. 

If the ThingWorx cluster use the embedded Ignite , instead of the separated Ignite cluster,  will the property value written into ThingWorx foundation A sync to ThingWorx foundation B and the property value has a short time inconsistency before finishing the sync ?  or there's certain global/distributed lock to prevent the property from reading/writing until the property value finish the sync,  or certain snapshot of property value , so that reading the property  value always keep consistent ? 

Regards,

Sean 

[yhan]

Hi @seanccc,

Actually, ignite allows configuring cache mode(PARTITIONED or REPLICATED) and rebalance mode (SYNC or ASYNC) through class org.apache.ignite.configuration.IgniteConfiguration.

But for Thingworx ignite mechanism, I believe it uses the sync mode to control the cache rebalancing process, that is "Any requests to the cache’s API are blocked until rebalancing is completed".

Thanks,

/Yoyo

[seanccc]

@yhan ,

Thank you for the replies.  I marked your 1st reply as solution .  This reply is also very helpful. 

Regards,

Sean 

[seanccc]

@yhan ,

I think of another question although I've accepted the solution.   Hope I can get your answer. 

Comparing to the the standalone ThingWorx server,  the cluster ThingWorx servers may always introduce additional delay for updating property.  For the embedded Ignite there may be a sync lock for updating property,  for the separated Ignite there is additional network cost , either of the mode bring updating delay.   

While in the IoT case,  it's normal that a property get updated every 500ms or event faster,  does the cluster ThingWorx servers can still meet the performance requirement ?   Do we have a performance measurement for updating property in ThingWorx cluster mode ? 

Regards,

Sean 

[yhan]

Hi Sean,

Thanks for your questions that let us know the current problems our customer meets in the TWX active-active HA environment. Currently, we have some monitoring tools, you can refer to: Monitoring the High Availability System.

But to my understanding, the two conditions you mentioned are not only for TWX HA, but also for any other enterprise systems. At least we need to make sure the network speed and throughout are good between HA nodes.

Thanks,

/Yoyo