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

service execution is slow when called from a mashup

SOLVED
Highlighted
Marble

service execution is slow when called from a mashup

I am using ThingWorx 8.3.2-b535.  I have an sql query service that returns 1 row of data (containing about 6 columns).  when I execute this service from the thing it takes around 1 second.  When this service is called from a mashup it takes around 7 seconds.  This mashup executes about 7 other services which are also sql queries and they generally take less than 1 second.   What is the proper way to diagnose why this is occurring?

1 ACCEPTED SOLUTION

Accepted Solutions

Re: service execution is slow when called from a mashup

This type of performance issue (where chained SQL services take too long) is usually a result of contention at the JDBC connection layer.

 

By default the Database connector you're using for your custom queries has a default of 5 connections.  Each statement you're executing uses one of these connections.  The delay is usually caused by the last statement having to wait for a connection to the DB while the other ones are active.

 

You can check the number of available connections in the Configuration section for your DB thing.  For context, the platform uses 100 connections to the DB and we typically set our JDBC connectors to 100 as well if this is going to be a high-volume operation (and this will be since it runs from mashups)

Tudor_0-1580138182784.png

This is configuration issue is not always the case, but it's definitely something to rule out first.  If the issue is not a bottleneck at the connection layer we'll need additional diagnostics.  Specifically, you may want to install the SupportTools extension and capture thread dumps while stressing this mashup (i.e. launch 10-20 mashups in parallel).  The tool is available here and you can post any resulting stacktrace files in this thread (zipped) or open a case so I can have a look at them: https://marketplace.ptc.com/apps/196419/support-tools-for-tw-66#!overview

View solution in original post

3 REPLIES 3

Re: service execution is slow when called from a mashup

Hi kyetzer,

 

You have already got the solution in your query itself.

Sequence of services execution within your mashup binds might be delaying the response. You can test it by removing all other services and just keep that service bind to widget and run it.

Re: service execution is slow when called from a mashup

This type of performance issue (where chained SQL services take too long) is usually a result of contention at the JDBC connection layer.

 

By default the Database connector you're using for your custom queries has a default of 5 connections.  Each statement you're executing uses one of these connections.  The delay is usually caused by the last statement having to wait for a connection to the DB while the other ones are active.

 

You can check the number of available connections in the Configuration section for your DB thing.  For context, the platform uses 100 connections to the DB and we typically set our JDBC connectors to 100 as well if this is going to be a high-volume operation (and this will be since it runs from mashups)

Tudor_0-1580138182784.png

This is configuration issue is not always the case, but it's definitely something to rule out first.  If the issue is not a bottleneck at the connection layer we'll need additional diagnostics.  Specifically, you may want to install the SupportTools extension and capture thread dumps while stressing this mashup (i.e. launch 10-20 mashups in parallel).  The tool is available here and you can post any resulting stacktrace files in this thread (zipped) or open a case so I can have a look at them: https://marketplace.ptc.com/apps/196419/support-tools-for-tw-66#!overview

View solution in original post

Re: service execution is slow when called from a mashup

Hi @kyetzer.

 

If one of the previous responses answered your question, please mark the appropriate one as the Accepted Solution for the benefit of others with the same question.

 

Regards.

 

--Sharon

Announcements

Thingworx Navigate content has a new home! Click here to access the new Thingworx Navigate forum! ______________________________