What is the maximum number of subscriptions I can use?

[Michail]

In my application there are 300+ integer properties and each requires a subscription. I've created 300+ subscriptions in XML and imported the shape. After I opened "Subscriptions" section in the composer, the platform took too long to respond thus killing my browser session. Next time, after a very long wait I managed to open "Subscriptions" page and found all of my subscriptions. Clearly it takes a long time to render the page since the XML file is quite large.

1. What are the limitations when it comes to "Subscriptions"?

2. Is AddDynamicSubscription() service a better alternative? If so, how can I monitor active subscriptions?

Cheers.

[jkaczynski · Accepted solution]

Hi mnudel​,

I believe that only limitation is your Thingworx / Tomcat memory pool. If you increase the available memory, it should work better.

However! - point one: 300 subscriptions is a lot if it comes to one Thing. Maybe a better alternative is to split them up for a few, related entities? It would probably work better if you have 6 Thing x 50 properties, related somehow (Networks?). Or so...

However! - point two: The problems to show / render those subscriptions are from the browser side. It doesn't mean, that the subscriptions are invalid or don't work at all. The Platform can have a hiccup and require more memory, but it should work anyway.

What's more - I don't think that AddDynamicSubscription() will make a big difference in the overall picture.

[Michail]

Thank you Jakub for confirming my suspicions. An alternative I came up with is to store previous values and compare them with the current values every minute (scheduled event). Thus I can determine an integer property which has changed and fire appropriate service (same service for all integers). I assume such approach is less burdensome.