Reducing Trips to the Server

This section discusses how to:

  • Count server trips.

  • Use deferred mode.

  • Hide and disable fields.

  • Use the Refresh button.

  • Update totals and balances.

  • Use warning messages.

  • Use the fastest algorithm.

Server trips are bad for performance. Each server trip consumes resources on the application server, slows down the user data entry, and can affect type ahead. Whenever you see an hourglass as you move between fields on a page, it is because the browser is waiting for a server trip to complete.

The larger the component’s buffer (based on the number of record definitions accessed, the number of fields in each record, and the number of rows in each grid or scroll area for each record), the longer each round trip to the server, because of the increased server processing.

Deferred mode reduces the user’s time to complete the transaction and conserves application server resources.

The following user interactions cause a trip to the server. Only the first three items in the list are deferred in deferred processing mode.

  • Entering data in fields with FieldEdit or FieldChange PeopleCode.

  • Entering data in fields that have prompt table edits.

  • Entering data in fields that have related displays.

  • Inserting a row in a grid or scroll area.

  • Deleting a row from a grid or scroll area.

  • Using grid or scroll area controls to move forward or back.

  • Accessing another page in the component.

  • Selecting an internal tab.

  • Expanding or collapsing a collapsible section.

  • Clicking a button or link.

Each trip goes through the same process of checking security, unpacking the buffers that store the data being processed, processing the service request, generating the HTML for the page to be redisplayed, packing updated buffers, and storing the buffers on the web server. To maximize online performance, minimize server trips.

Count the trips to the server to quickly identify transactions that have performance issues. PeopleTools can automatically count these trips by reason (such as, adding a row in a grid or FieldChange PeopleCode) and write the output to a log file.

To turn this feature on, run a debug version of PeopleTools and add the following to the [trace] section of the appserv.cfg file:

showcounters = 1

The output is written to the appsrv.log file.

Keep components in deferred mode and enable fields for interactive mode only if there is a strong business case.

For every field on the component to run in deferred mode, Deferred mode must be selected at the component level, Allow Deferred Processing must be selected for each page in the component, and Allow Deferred Processing must be selected for each field.

PeopleSoft recommends that you continue to code field edits in FieldEdit PeopleCode and field change logic in FieldChange PeopleCode, but set this logic to run in deferred mode. You do not need to move field edits to SaveEdit.

Avoid using FieldChange PeopleCode to hide, unhide, enable, or disable elements on the same page, unless the element is triggered by a separate button.

Hiding or unhiding objects and enabling or disabling objects should, as a general rule, be coded in either page Activate PeopleCode or, for objects that are on another page in the component, in FieldChange PeopleCode.

Perform cross-validation edits to prevent invalid data combinations from being written to the database for fields that previously would have been hidden or unavailable. If unhiding fields that were previously hidden or unavailable results in making the page confusing, consider designing a longer page so that users can easily associate related fields.

You can hide or unhide objects or set them to display-only in page Activate PeopleCode before the page initially appears based on setup data, configuration options, or personalization settings. You can set fields to display-only using PeopleCode by setting the DisplayOnly property for the field to True.

You can hide or unhide fields on another page, or set the fields to display-only, based on the value that a user enters in a field on the current page, as long as that component or field is set up to run in deferred processing mode. In some cases, it may make sense to split transactions across pages to achieve progressive disclosure.

The Refresh button gives users control of their environment. Clicking the Refresh button forces a trip to the server. PeopleTools then redisplays the page in the browser. The refresh action allows the user to:

  • See related display field values for the data entered so far.

  • See any default values based on data entered previously on the page.

  • Validate the data that has been entered on the page so far.

When the page is redisplayed, the cursor is positioned in the same field it was when the user pressed the Refresh button.

Note: The Refresh button does not refresh the page from the database. It simply causes a server trip so that any deferred PeopleCode changes are processed. If no deferred changes exist or the deferred changes do not cause any errors or other changes on the page, it may appear to the user as if nothing has happened.

Fields on derived work records are not updated if the user clicks the Refresh button.

In some pages, totals or balances appear based on data entered into a grid or scroll area. This process should work in deferred mode also, showing the totals or balances as of the last trip to the application server.

Continue to keep any accumulation and balancing logic in FieldChange PeopleCode, but run the field in deferred mode. Users can click the Refresh button at any time to see the latest totals based on the data entered. Totals and balances in deferred mode are always updated and displayed after any trip to the application server.

In deferred mode, FieldEdit PeopleCode errors and warnings do not appear when a user moves out of the field, but rather on the next trip to the server. This next trip might not occur until the user enters all the data and clicks the Save button.

For FieldEdit error messages running in deferred mode, PeopleTools changes the field to red and positions the cursor to the field in error when it displays the message. This behavior allows the user to associate the error message with a specific field.

For warning messages, however, PeopleTools does not change the field to red or position the cursor. For a user to clearly understand to which field a warning message applies, ensure that warning messages clearly describe the fields affected by the warning.

For example, the warning message “Date out of range” would be confusing if there are seven date fields on the page, since a user could not easily determine which date field needed to be reviewed. Instead, you could include bind variables in the message to show which dates are out of range.

You should determine which algorithms perform the best and have the smallest elapsed time. Tracing does not provide subsecond level of timing information. Plus, tracing imposes a higher overhead to the runtime environment, which skews the elapsed time reading.

However, you can use the %PerfTime system variable for determining elapsed time. %PerfTime retrieves the local system clock time by making a system call, and the return time is down to the millisecond.

The following example of %PerfTime determines how long a program takes to execute:

   &Start = %PerfTime;
   &results = "";
   For &I = 1 To &Count;
      &GnnwgNumber = GetNextNumberWithGapsCommit(QEORDER_DTL.QE_QTY, 999999, 1, "where QE_ORDER_NBR='GNNWG'");
      &results = &results | " : " | &GnnwgNumber;
   End-For;
   
   &End = %PerfTime;
   &out = "Count = " | &Count | ", total GNNWG time (s) = " | NumberToString("%6.3", Value(&End - &Start));