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?
Solved! Go to Solution.
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)
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
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.
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)
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
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