cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Community Tip - New to the community? Learn how to post a question and get help from PTC and industry experts! X

ThingWorx cache

AK_10385731
4-Participant

ThingWorx cache

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

3 REPLIES 3

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

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

 

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.

 

 

Announcements


Top Tags