ThingWorx cache

[AK_10385731]

What’s the best way to cache data in ThingWorx?

• Should I use properties, configuration tables, or user sessions (of course user session is valid only for user)?
• Are there other options available?

1. If the value changes very frequently, is there a better alternative to Thing properties?
2. If the value changes less frequently, what’s the best approach for caching?

Also, can Ignite be utilized for caching in any way?

I am aware that it depends on use case and scenario. I would like to know what are the feasible options available or supported by the ThingWorx platform.

Thank you in Advance.

-Abhiram

[Constantine]

The answer really depends on the amount of data and your access patterns. For large amount of data, I'd delegate caching to an external system like Redis and access it via a Java extension (no, I'm not aware of existing extensions for that, but implementing a new one is easy). One of the key questions you'd need to ask yourself is whether you cache for reducing latency or increasing the overall throughput. If it's the latter -- an external system is almost always a better choice.

For small and medium data volumes, non-persistent, non-logged "basic" (numbers, strings) properties are managed entirely in memory, and are thus fast enough for most caching scenarios. Infotables are slow. Reading/writing properties under Administrator will likely be (much?) faster, as ThingWorx won't perform permission checks. If you use shared caches, you'd need to be careful with threads synchronization, which ThingWorx doesn't do.

I'm not sure about the User session performance characteristics, as it is probably implemented via Tomcat session, which might have its own performance overhead, associated with serializability and thread safety. This is something you'd need to test.

Can't say anything about Ignite, sorry.

/ Constantine

[Rocko]

Just for completeness of available features, as of version 9.6. there is also a level of client-side caching offered in Mashups, which can help to reduce the number of Service Calls:

https://support.ptc.com/help/thingworx/platform/r9.6/en/#page/ThingWorx/Help/Mashup_Builder/DataServicesandLinking/CachingServiceDatainMashups.html#wwID0EJ6JAB

[wcui]

Hi @AK_10385731 

It appears that some responses answered your question.  For the benefit of other Community Members who may have the same question, it would be great if you could designate the proper one as the Accepted Solution.

In the event that this response did not answer your question, please post your current status so that we can continue to support.

Thanks for using the PTC Community!

Regards,

wenjing

[VladimirRosu · Accepted solution]

First you would need to define the scope of the cache (eg: 1. the "time" validity, meaning what's the lifetime of the data you want to cache - will it be destroyed when the user logs out or its session expires and 2. the "spatial" validity of the cache - what are the object types for which the cache will be valid: an user, a group of objects or for the ThingWorx instance etc, 3. the size of that cache and 4. the expected read and write latency of that cache).

A. Properties are meant to store one value (whatever the basetype), but they will store that value in memory, so it will not be useful for large amounts of data. To be clear: for a normal Thing (non-Remote), reading that Property will result in an in-memory read, without a disk read access. Writing can be configured (if you uncheck the Persistent and Logged) to not result in a disk write (but frequently users check the Persistent so that they can get the last value if the Thing or Platform restarts). Latency is very good.

B. User extension properties are good for any user-focused cache (point 2 above) - again, if it matches with your cache definition on top of this reply.

C. Users can use external systems (I include here the standard easily accessible entities like DataTables, Streams or pure SQL tables), but I would not go as far as to consider these systems I mentioned as caches, as writing to them always results in a disk access, hence they won't be suitable for  very fast data writes, at least. However, a good third-party system designed for caching will definitely work excellent for this category, just that you need to create an extension - Constantine summarized this aspect.

D. I strongly suggest looking at the OOTB Caching we added for the Mashups - that's really cool - as Rocko started. Starting from that, you can start looking at services like Azure Front Door, that can cache the HTTP requests themselves.

It would be interesting to hear what exact situation you would want to design a cache for, then we can get out of the theorizing mode :D.