|
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.
|
Troubleshooting and performance tuning 