Analysis and Resolution of Performance Issues

This section discusses tools and procedures for resolving performance issues after implementation. It also contains best practices when migrating from one environment to another.

If you identify a performance issue related to your configurations, the following steps offer some guidance on how to isolate and resolve the issue.

Evaluate User Feedback

• • What were you doing when the issue occurred and was the action related to any aspect of your configurations? The actions will point to specific objects, views and Groovy scripts.
  • Collect as much specific detail as you can about the issue. Exact navigation paths, exact sequence of operations, items selected, buttons clicked, menus selected, time of day, number of rows affected.

Reproduce the Issue

• Enable logging for the application and try to reproduce the issue yourself – see Logging for more information.
• If you can't reproduce the issue:
  • Evaluate the possibility of an external issue triggering the issue – a bad Wi-Fi connection for example.
  • Try a series of tests; for each test, vary a single element of the reported steps or data to see if you can reproduce the issue.
  • If you can't reproduce the issue, track the incident details and these details - combined with future reports - might help you spot a pattern that will allow you to isolate the issue.
• Is the issue reproducible only some time? Reproducing the issue even once with logging enabled should provide valuable insight. If you do have log entries recorded while reproducing the issue, see Analyze the Application Script Log for suggested next steps. If you're stuck, keep in mind that an inability to consistently reproduce a bug often equates to lack of enough detail regarding the conditions that trigger the bug; always gather as much detail as possible.
• issue is reproducible and not attributable to some external condition or event (network, server load) - see Analyze the Application Script Log for suggested next steps.

Analyze the Application Script Log

The following set of points outline strategies for isolating the source of the problem in some common use cases with the Application Script Log enabled.

• If there are many scripts involved, you can narrow down the list of candidates for elapsed time logging by answering the following questions.
  • Is the performance problem associated with page loading of a particular page?
    • Have you implemented any Groovy scripts recently that are executed during page load (formula fields, conditionally updatable attribute, conditionally required attribute or object/global scripts executed in these contexts)?
    • Have you added new custom attributes related to the use case? Do these attributes implement scripts as described above?
    • Have you added any new Long Text or other fields that are potentially expensive to fetch and display? See Custom Attributes for best practices related to optimizing custom attribute usage.
• Is the performance problem associated with saving changes?
  • Have you recently implemented any Groovy scripts that are executed during save operations (Object validation or trigger scripts including - but not limited to - Before Insert in Database, After Insert in Database, Before Update in Database, After Update in Database, Before Delete in Database, After Delete in Database, After Changes Posted to Database, Before Commit in Database, After Commit in Database, Before Rollback in Database, After Rollback in Database or object/global scripts executed in these contexts)?
  • Have you added new custom attributes to an object that participates in the use case? If the affected object also suffers from degraded page load performance, review the guidance for page load issues first. If page load performance isn'tdegraded, review the scripts associated with these attributes.
  • Does the use case that triggered the issue include a much larger number of rows than a typical use case? Large row counts magnify the impact of poorly performing code.
• Is the performance problem associated with some other action on a page? The diagnostic steps are similar for any use case that suffers performance degradation relative to the baseline.
  • Identify any recently implemented Groovy scripts that are executed in the course of the use case
  • Identify any recently implemented custom attributes along with associated scripts. If the object also suffers from degraded page load or save performance, review the guidance those issues first. If page load and save performance aren't degraded, review the scripts associated with these attributes.
  • Consider the number of database rows affected by the action.

Logging

The Application Script Log (select Runtime Messages in Common Setup in Application Composer) is an important tool for diagnosing various problems including performance related issues. Application Composer places specific limits on the scope of logging to minimize the impact of logging on overall application performance.

• Application - Logging is enabled and disabled at the application level. If a particular logging use case spans multiple applications, you need to enable logging for each application.
• User – Logged in user enables and disables logging for their user id only; a user must have access to Application Composer to enable logging.
• The impact of enabling and disabling logging is limited to the println command:
  • When logging is disabled, the println command does nothing.
  • When logging is enabled, the println command sends output to the Application Script Log.

Any other code that supports logging (for example, code used to generate log content) is executed for all users, all the time; by default, enabling or disabling logging has no impact on any code other than println. This is mainly a concern in cases like the following:

• Your logging support code is performing relatively expensive operations that are performed only to support logging.
• Your logging support code is implemented in a often executed script – for example an attribute formula script. The frequency of execution could elevate otherwise innocuous code to the level of a performance issue.

To limit the potential impact of logging-related code other than println statements, see Guidelines for Implementing Logging Support Code and Example Logging Functions.

To view the Application Script Log, click Runtime Messages in the Common Setup node in Application Composer. In the following screen shots, logging has been enabled for the Sales application and the John Dove user.

Runtime messages in ERP and SCM Cloud

Logging is enabled and disabled for each individual application. In this example, the user has selected the Sales application. Next, select Runtime Messages in Common Setup. Finally the user checks the Enable Application Script Logging. Note that logging is enabled for a current logged in user only – the John.Dove user in this case.

Guidelines for Implementing Logging Support Code

In this context, logging support code refers to any code (other than simple println statements) that's used only for logging. Output from println statements is disabled when you disable Application Script Logging. Any other code used only for logging will execute all the time for all users.

• Avoid implementing logging support code that's expensive in terms of time and/or resources.
• If you plan to implement any logging code that might have performance impact (for example fetching rows that are used only to generate log output) and or logging in scripts that are often executed (for example an attribute formula script), ensure that such code is disabled when not in use.
• Avoid replicating common logging code directly in your individual scripts. Where feasible, concentrate common logging-related work in global logging functions that you call from individual functions. This let's you to enable and disable logging support code in a single place.