I'm trying to gather the best configuration settings for maximum performance of the out-of-the-box Time Series Chart (TSC) widget. The goal is to lower the amount of time it takes for the TSC widget to display data lines while maintaining the fidelity and integrity of data displayed (if that makes sense). Obviously less data means less time, but does anyone know how the TSC properties (Autoscaling, Smoothing, Marker Size, etc.) affect performance?
This post is part question, part knowledge share. If you've discovered how certain widget or other settings seem to affect the performance of the TSC, please share!
My Current Scenario:
Thingworx 7.1. We have multiple data points on multiple Things. When I select a Thing in a mashup, the numerical properties will be queried to display in a TSC. I'm not for sure how many points we will eventually want to throw into a chart but I've used 5000 as a MaxItems test value when querying property history. The widget doesn't seem to like this much data. Takes a minute or more to draw 5 lines from the QueryPropertyHistory service with 5k max items.
What I've found:
Rather than run QueryPropertyHistory on the Thing and giving all the property data to the TSC at once, I tried running QueryNumberPropertyHistory for each property I want data from and feeding these into the chart separately. This drastically reduced the amount of time it took for the TSC to draw the lines with same widget settings (around 10 seconds).
We have also had the same performance issues using the standard Time Series Charts. The time series chart 2, available from the marketplace under custom chart widgets, did provide somewhat better response time, but it came with a bit of unreliability and the response time wasn't improved to a level that is functional. Maybe the combination of the QueryNamedProperties approach you used in combination with the Time Series Chart 2 will give you a good enough solution.
Another issue we had was with some properties that do not have value changes as often as some others resulting in a timeframe being queried for display purposes that did not include a new value and it resulted in no trend line showing. It is not a good idea changing the property logging to Always because of the unnecessary data being stored and the query set becoming even larger with essentially the same data. What worked well though, because the performance issues are in the front-end widget and not in the back end query, to query a larger time frame and then have a sub-query to query the required time frame.
I did see on the Thingworx Manufacturing Apps a Time Series widget they use for Trending and Troubleshooting that looks to have much better performance (with the testing that I have done on manufacturing apps with large data sets), but it is not a standard widget and not available on the market place, PTC might be able to provide access to this.
This reply was also more information sharing than an answer, but I am short on those relating to this topic.