Reduce Server Trips
Accessing the sever in between the field navigations causes sever performance issues and it is imperative to manage these trips to make a better coded application.
What happens in a server trip?
- All the below activities are repeated for each server trip.
- 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
- Storing the buffers on the web server
The below items brings in server trips
- 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.
Steps to identify and control server trips
- Analyzing server trips: showcounters = 1
- Using Deferred mode whenever possible
- Avoid using FieldChange PeopleCode to hide, unhide, enable, or disable elements on the same page. 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.
- Clicking the Refresh button forces a trip to the server
- Make the calculations / totaling in the deferred mode
- Use warning messages in Deferred mode with proper value tagging
- Use %PerfTime which helps you to determine how long a program takes to execute and adjust it accordingly
Other recommended methods includes
- Run a SQLTrace and review the transaction for SQL statements that have a long processing time and tune it with the assitance from the DBA
- A simple join optimizes SQL more effectively than issuing two related SQL statements separately.
- While working with the counter, use the GetNextNumberWithGaps PeopleCode function to avoid unwanted commits.
- Minimize the events to be triggered and consolidate the PeopleCode under less number of events for better managing and performance.
- Messages sent online should always be coded in the SavePostChange event. Safer that the message will not send until the commit happens
- Use metadata and Rowset Cache
- Increasing MaxCacheMemory. Keeping a low memory space can degrade the performance when a significant cache is created and lower the performance
- Declare all variables upfront and specifically by the type and do not leave the program to do the auto declaration
- Create application packages for repeated and re-usable code fragments
If you have your suggestions, please comment it below and I will incorporate in this post.
Post a Comment