Troubleshooting and performance tuning  
The gadget spec URL could not be found




S.No

What? Problem summary

Why? Possible reasons

How? Suggested alternative

1

Page takes a longer time to load during login.

In most cases, the landing page (home page) after login is the worktop that contains the list of items assigned to the user along with the counts for each item and link to access the inbox. If there are more than 1000 items assigned to a user, then the user might face this problem during login as the system loads all of these instances in the memory to calculate the item counts.

 

Users responsible for maintaining master data are more likely to face this problem as the number of instances in a master could easily be more than 1000.

There are two possible solutions:

 

Perform a worktop redesign such that the counts are not computed and displayed for master data. Just provide a link to the inbox to access master data. This is the recommended solution.

 

Use the team inbox feature. This will help resolve the problem during login. However, the user will face similar page loading issue when accessing the team inbox.

2

Page takes a longer time to load while creating a new instance.

The chances of users facing this problem are remote. However, should such a scenario arise, it could be because child model with more than 25 instances are displayed based on the reference cells such as CreatedBy, ModifiedBy etc in the newly created instance.

 

Restrict the number of child instances displayed to 25 or less using a separate reference cell.


3

Page takes a longer time to load while opening/reading an existing instance.

This could be because of either one or more of the reasons detailed below.

 

       A one-many form has been used to display child model with more than 25 child instances.

 

       A Network select box (context based dropdown box) is used with more than 100 items in a select box.

 

       The form is used to display data from more than 100 instances.

Here are the suggested fixes to resolve this issue.

 

Restrict the number of child instances displayed to 25 or less using a separate reference cell.


 

Provide the advanced search feature when the number of items to be displayed in the select box is more than 100.

Group relevant data and use multiple forms to capture/display data.


 

4

Page is unresponsive or response is slow during field updates.

This could be because of either one or more of the reasons detailed below.

 

       The sync parameter is set to true for database functions written based on an aggregate relationship. The greater the number of instances, the slower the response.

 

Database functions have been written based on a parent-child relationship. The greater the number of instances, the slower the response.

 

        DSEARCH or DFIND has been coded in the rules perspective.  The performance of DSEARCH and DFIND varies depending on the number of instances.

 

        Lots of dependencies are defined for a field in the rules design perspective.

 

Here are the suggested fixes to resolve this issue.

 

Use database functions in actions or incremental logic in actions for performing calculations.


Use Many-One form instead of writing a DGET to fetch values for displaying it in the field.

 

 DSEARCH function can be leveraged (used instead of DFIND) for improved performance when the number of objects to be searched is greater than 1000.


Use the “Submit on dependency”, “Don’t submit” or “Submit” to control when the updates should be committed to the database.

 

5

Page is unresponsive or response is slow when the user performs an action by clicking on a button.

This is the easiest of all the problems, because we already know where the problem is; we just need to focus on the action that is invoked when the button is clicked.

 

The probable cause for this could be an Rcall or a child call in the action that works on a model with more than 100 instances.

 

Use limit or criteria to control the number of records processed by these commands.




ĉ
Boobesh Ramalingam,
Oct 12, 2011, 4:02 AM