Skip to main content

Hi, 
For our application, we are facing on several screens performance issues since we are in production and the set of data is growing.
Some examples:

  • For a table we moved some big fields containing json content already to a separate table, and made them visible in a form tab. But when click on the form tab, it still will take > 30 sec before it is loaded. It looks like the full table is loading before the related record is shown.
  • For a screen we have defined a form layout to show (summary) details of related child records. This is currently build in a view, but when loading that tab it will take some time before the (filtered) data is shown.
  • For a table we are showing lot of extra data with expression fields as the base data is not stored in that table, but in related tables. It is not preferred to have that data stored twice, als in the ‘header’ table to reduce the number of expression fields.

Are there suggestions to improve the performance for loading the data in a form detail?

As you are using views and filters it's probably a good start to look at the indexes, you might be missing some or they exist but are fragmented and need maintenance.


Did you check this blog post to see if this helps you?

 

 


Thanks @AndreKemmeren and @Erwin Ekkel for both advices. 
At least for 1 table, I found a missing index.

Will go through the steps as mentioned in the blog.


@HJ van Dalfsen We also encounter the issue that the Universal GUI can’t properly load a large JSON field in the Form. We have a (long-standing) TCP ticket open for this, and I believe this to be a bug. I know of no good way to deal with this at the moment.


Out of curiosity @HJ van Dalfsen - which GUI are you using? (Windows/Web/Universal?)


@Ricky , We are using the Windows GUI


You can take a look behind the scenes using this link:
https://docs.thinkwisesoftware.com/docs/deployment/universal_troubleshooting

It is pretty hard this way to say what the bottlenecks are, by the given information.

If you like to exclude columns with large chunks of data in it for a subject showing a lot of records at once, the best way to skip them is the usage of a table variant in the SF.

Working in a detail subject, it is important the parent record could be found fast based on its primary key.


Hi @HJ van Dalfsen, have the performance issues been resolved or do you need more help? Thanks!