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.