Skip to main content
M
mabender1-Visitor
1-Visitor
August 4, 2020
Solved

Slow mashup performance after upgrading to Thingworx 9.0

  • August 4, 2020
  • 2 replies
  • 2810 views

We upgraded to Thingworx 9.0 the other week and got feedback from our users, that some of them got a very slow mashup performance and others were able to use the mashup as usual.

 

We tracked down the problem to two specific users:

- User A accessing the mashup using the most recent Google Chrome version on Windows 10 and experiencing a very slow/delayed performance

- User B using the same configuration (Windows 10, Chrome) with the normal experience.

 

Both users are using the same internet connection and similar hardware (8 GB RAM, i5-8350, SSD). The Chrome configuration (version, extensions, ...) is identical. The server does not show any troublesome values (Memory, CPU, ...). 

 

Having a look at the Chrome inspector the data requests take around 500-700 ms on both workstations. But rendering the data or reaction to a button click takes up to 15 seconds for User A instead of instant feedback for User B. 

 

Are there any known issues regarding the use of Google Chrome with Thingworx 9.0? Or are there any tips on how to improve the performance or track down the problem even further? 

 

We're currently out of ideas and therefore not able to roll-out the mashup inside our enterprise. 

 

 

Best answer by wposner-2

We've definitely seen performance issues in TWX 8.5 where the request takes milliseconds, but the render of the data takes multiple seconds.  So your issue isn't unique to 9.0. You can even see this behavior in composer when running a service that returns an infotable.  The service execution will be extremely quick, but the datagrid will not render for a few seconds.  

 

I think this behavior is due to the massive amount of JS that gets dumped on the client computer regardless of whether your mashup is using widgets contained in that JS or not.  I can substantiate this claim by building a React based UI, loading only the JS required to render my UI, calling TWX REST APIs to populate my UI and comparing the render times.  Take a guess which UI is significantly faster...

2 replies

S
slangleyCommunity Manager
Community Manager
August 4, 2020

HI @mabender.

 

I noticed you posted this in the Manufacturing Apps queue.  Is your question related to mashups delivered with Manufacturing Apps or is this a platform issue?

 

Regards.

 

--Sharon

M
mabender1-VisitorAuthor
1-Visitor
August 5, 2020
Thanks for reaching out! It’s more a platform issue. Would be great if you could move the topic if required, thanks!


W
wposner-21-VisitorAnswer
1-Visitor
August 6, 2020

We've definitely seen performance issues in TWX 8.5 where the request takes milliseconds, but the render of the data takes multiple seconds.  So your issue isn't unique to 9.0. You can even see this behavior in composer when running a service that returns an infotable.  The service execution will be extremely quick, but the datagrid will not render for a few seconds.  

 

I think this behavior is due to the massive amount of JS that gets dumped on the client computer regardless of whether your mashup is using widgets contained in that JS or not.  I can substantiate this claim by building a React based UI, loading only the JS required to render my UI, calling TWX REST APIs to populate my UI and comparing the render times.  Take a guess which UI is significantly faster...

    K
    kevinb_kad1-Visitor
    1-Visitor
    August 7, 2020

    @wposner-2 Thanks for your comment! 

    Actually that would have been our next step: Creating a sample application with React or Vue, only consuming the TWX REST APIs and comparing the performance. Referencing your comment it's easy to guess which UI will be way faster, sure. 

    Did you find any way to improve the performance in the end? Is there a way to limit the amount of JS which will be send to the client? 

    Actually the build in mashup builder was one of the reasons we started to use TWX. Running into this performance issues is a real bummer - and building every application by hand (React/Vue) would not really be an option for us. 

    W
    wposner-21-Visitor
    1-Visitor
    August 7, 2020

    Unfortunately, not completely.  Controlling how much data is returned to the UI is one way to increase performance.  Using other visualization charting widgets that are more performant than those PTC has included with Thingworx is another way to increase performance.  But ultimately, if you're looking for max performance you need to look at a combination of mashups and an external UI framework.  The reason I say combination is that is you need instant property value updates to be reflected in your UI (GetProperties with websocket feature enabled), then you need to use a mashup.  Everything else can be externalized to the framework of your choice.  We've had amazing results with React based UIs, but have taken the hybrid approach and load our React UIs via TWX mashups using an iFrame.

     

    Take a look at WaveMaker.  They offer a product that is what the Mashup Builder should be!  It's the mashup builder on steroids, and the end result is an easily deployable Angular based application.

    Terms & ConditionsCookie settingsAccessibility statement