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

Community Tip - If community subscription notifications are filling up your inbox you can set up a daily digest and get all your notifications in a single email. X

Thingworx connectivity endpoint performance

LuisCabello
12-Amethyst

Thingworx connectivity endpoint performance

Hello community,

 

I have a  services Thing Hub, where a lot of devices send to this twx endpoints messages in json format. The number of post request to this twx endpoint is going to have more demand and I do different operations as data processing, add logs, set the data in the thing that represent the digital twin of the device etc... . I create this with a general thing template and I have some questions:

 

1. Exist any template that have a good performance to this use case? (Receive a lot of post request)

2. Have I check the async check box to improve the performance?

3. Exist any information about the number of request that one thingworx endpoint can have?

4. Can I monitoring that number of request?

 

Thank you in advance,

Luis.

 

 

 

1 ACCEPTED SOLUTION

Accepted Solutions

Hi Luis,

First you should setup a monitoring system (if possible) to verify your instance CPU/RAM usage. Optimizations you do on ingestion services should have a visible impact on these hardware resources. Whatever optimization you will do, you need to be able to understand what are its results.

Ref 1: I remember, though not 100% sure, that if in the service that requests that process you raise a (custom) event instead of processing directly the payload, you'll get that logic executed via the Event Subsystem (which is configurable in terms of threads etc.). You can try to modify your logic to do things in this pattern.

Ref. 2: async is not necessary a performance improver, because at the end of the day that logic will still be done. It just allows you to dispatch the request without waiting for response. So, if you mark your service as async, you can also say goodbye to potential responses you might want to send to the originator of that request. One very important thing to remember is that async threads are spawned as needed, with no enforced maximum limit. You could have your system slowing down more and more due to some async threads which for some reason did not finish execution, etc. That's why the Event subsystem is more desirable, since you can control the max number of tasks.

Ref 3.Yes, that's in the sizing tests we do with various loads. More information here. Please remember, that, as we are a platform, we can not guarantee these numbers, since you will always provide custom code that we can not predict.

Ref 4. The number of HTTP requests we get in the platform is not monitored by the platform. However, you most probably need the number of executions of that specific service, which the platform will monitor if you enable the Utilization Subsystem. However, note that this subsystem tracks all service executions in the platform, and it is not advisable to let it run forever. Another option you have is to increment a counter (Property) in your thing, so that you have an idea of how many executions happened.

View solution in original post

2 REPLIES 2

Hi Luis,

First you should setup a monitoring system (if possible) to verify your instance CPU/RAM usage. Optimizations you do on ingestion services should have a visible impact on these hardware resources. Whatever optimization you will do, you need to be able to understand what are its results.

Ref 1: I remember, though not 100% sure, that if in the service that requests that process you raise a (custom) event instead of processing directly the payload, you'll get that logic executed via the Event Subsystem (which is configurable in terms of threads etc.). You can try to modify your logic to do things in this pattern.

Ref. 2: async is not necessary a performance improver, because at the end of the day that logic will still be done. It just allows you to dispatch the request without waiting for response. So, if you mark your service as async, you can also say goodbye to potential responses you might want to send to the originator of that request. One very important thing to remember is that async threads are spawned as needed, with no enforced maximum limit. You could have your system slowing down more and more due to some async threads which for some reason did not finish execution, etc. That's why the Event subsystem is more desirable, since you can control the max number of tasks.

Ref 3.Yes, that's in the sizing tests we do with various loads. More information here. Please remember, that, as we are a platform, we can not guarantee these numbers, since you will always provide custom code that we can not predict.

Ref 4. The number of HTTP requests we get in the platform is not monitored by the platform. However, you most probably need the number of executions of that specific service, which the platform will monitor if you enable the Utilization Subsystem. However, note that this subsystem tracks all service executions in the platform, and it is not advisable to let it run forever. Another option you have is to increment a counter (Property) in your thing, so that you have an idea of how many executions happened.

Hi Vladimir,

 

Thanks you a lot. I'm gonna test and I will see what I can achieve :). 

 

Have a good day,

 

Greetings,

 

Luis.

Top Tags