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

ThingWorx Navigate is now Windchill Navigate Learn More

Translate the entire conversation x

Need fix to resolve performance issue

MA_10759583
4-Participant

Need fix to resolve performance issue

I've create custom mashup, that will generate the part structure and its associated object(ex: drawing, design info).
I've different service and generate the info table data in the grid.

if suppose, I've 300 rows then it would generated the result, but if I've more 500 rows/record it would take long time to generate the result.

Minimum, it took more 5 minutes to generate the report/table.

need suggestion to optimize the performance issue. also need some suggestion how to minimize the running time, I've already update ScriptTimeOut value, still not fix the issue.

ACCEPTED SOLUTION

Accepted Solutions

Hello,

 

  1. When you navigate your part structures -- do it one level at a time. Such calls will fetch less data and thus will be faster, allowing you to make your UI more interactive. The grid widget supports "lazy loading".
  2.  Only select the bare minimum of attributes when calling Windchill APIs. Provide $select parameter for each API call.
  3. Restructure your UI in such a way that things like related drawings are displayed interactively, for example when the user clicks on a part.
  4. Call APIs in parallel where possible, rather than in sequence.
  5. In some scenarios you can afford running your APIs under wcadmin. This usually works faster, as some permission checks are skipped.

 

Apart from that, in case you really need to get all of that data at once, I'm afraid the only working solution would be to implement it as a custom REST endpoint on the Windchill side. In the corresponding Java code you'd be able to craft a large complex QuerySpec, which would fetch that data in a single large SQL...

 

/ Constantine


Vilia (my company) | GitHub | LinkedIn

View solution in original post

2 REPLIES 2

Hello,

 

  1. When you navigate your part structures -- do it one level at a time. Such calls will fetch less data and thus will be faster, allowing you to make your UI more interactive. The grid widget supports "lazy loading".
  2.  Only select the bare minimum of attributes when calling Windchill APIs. Provide $select parameter for each API call.
  3. Restructure your UI in such a way that things like related drawings are displayed interactively, for example when the user clicks on a part.
  4. Call APIs in parallel where possible, rather than in sequence.
  5. In some scenarios you can afford running your APIs under wcadmin. This usually works faster, as some permission checks are skipped.

 

Apart from that, in case you really need to get all of that data at once, I'm afraid the only working solution would be to implement it as a custom REST endpoint on the Windchill side. In the corresponding Java code you'd be able to craft a large complex QuerySpec, which would fetch that data in a single large SQL...

 

/ Constantine


Vilia (my company) | GitHub | LinkedIn

Hi @MA_10759583 
 

I wanted to follow up with you on your post to see if your question has been answered.
If so, please mark the appropriate reply as the Accepted Solution for the benefit of other members who may have the same question.
Of course, if you have more to share on your issue, please let the Community know so that we can continue to support.
 

Thanks,
Abhi

 

Announcements


Top Tags