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

Community Tip - Did you get an answer that solved your problem? Please mark it as an Accepted Solution so others with the same problem can find the answer easily. X

Thing Remote/Local Property Limits

alexe1
1-Newbie

Thing Remote/Local Property Limits

I'm looking at a situation now where we have 50 devices we need to connect, each with 40 properties. These actually connect via a single gateway Thing, and so all 2000 remote properties are bound to that gateway thing. In this case our model also dictates that we have individual Things to represent each device, so then we have 50 Things, with their 40 properties each locally bound to its corresponding properties on the gateway Thing.

So all in all we've got 2000 remote properties on a Thing (each updating say once per second), and each of those properties is bound locally to one of 50 other Things. Is there any limit we are approaching in this situation? I know this support case says maybe 1,000,000 property limit to safely open in composer, so I assume we are fine here. I'm just curious if the remote and local bindings start to decrease the limit recommendations for opening in composer, server load, etc.

Thanks!

Alex

1 ACCEPTED SOLUTION

Accepted Solutions
jkaczynski
4-Participant
(To:alexe1)

Hi Alex,

I don't know the official limits, but as far as I know it's pretty high. Your architecture is fine and should work correctly even with more properties. The worse use case would be to connect every device directly to the Platform - with a larger set of devices this could clog your Platform's connection possibilities. But I'm talking now about the thousands of devices - and then Connection Server should be used to balance the overload.

View solution in original post

4 REPLIES 4
jkaczynski
4-Participant
(To:alexe1)

Hi Alex,

I don't know the official limits, but as far as I know it's pretty high. Your architecture is fine and should work correctly even with more properties. The worse use case would be to connect every device directly to the Platform - with a larger set of devices this could clog your Platform's connection possibilities. But I'm talking now about the thousands of devices - and then Connection Server should be used to balance the overload.

Thanks for confirming my suspicions here Jakub. Good note about device connections as well!

Jakub,

Let me summarize

Basically there is a line on # of properties on a single thing where you should stop using a single Thing (and connection)

When you hit that, you break it out to multiple Things/connections. But there is now a new issue, eventually, which is # of devices/connections

When you hit that, you start adding connection servers

Does that sound right?

jkaczynski
4-Participant
(To:jasong)

Hello Jason,

Short answer: yes, that's true.

Longer answer:

The first step (# of properties on one Thing) - I don't know the exact limit, but it depends also on your hardware (especially memory available). I have seen an implementation with really a huge amount of properties on one Thing. But I'd say - rather keep it on reasonable level (also from business logic perspective).

Splitting up to multiple devices - basically Thingworx can receive a lot of websocket connections without a loose of performance or rejected connections. The necessity of using Connection Servers is estimated to show up around 100k of devices.

For more informations and very interesting testing results regarding Connection Servers and High Availability, please refer to: Digital Media Publisher

Hope that helps.

Regards,

J.

Top Tags