Too many server trips will reduce you PeopleSoft Application performance. The main reason is each server trip consumes resources on the application server and it takes time to assemble the component buffer that stores the data being processed. each server request generates the HTML for the pages to be redisplayed, updated the component buffer and storing the buffer on the web server. To increase your PeopleSoft application performance you may want to reduce the server trips.
The following user interactions cause a trip to the server. Only the first three items in the list are deferred in deferred processing mode.
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.
How to count 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.
Use Deferred Mode
You can selectively made interactive mode enabled (i.e. Deferred Mode disabled) for individual fields on a page if you need a action to be triggered in your field immediately (such as FieldChange). obviously This will depend on your users requirements. If you unnecessarily made Deferred Mode disabled on a page or a component then it carry extra trips to the server hence it may reduce your application response time.
Hide, Unhide, Enable and Disable Fields
As a general rule use Page Activate PeopleCode or for objects that are on another page in the component, in FieldChange PeopleCode to hide or unhide objects and enable or disable objects.
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.
Using the Refresh Button
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.
Using Warning Messages
In deferred mode, for 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.
Unlike FieldEdit error messages, for warning messages PeopleTools does not change field to red or position the cursor to the field when it displays the message. 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
Using Optimised Algorithm
In the previous post http://peoplesoftdotnet.blogspot.com.au/2015/04/time-taken-to-execute-peoplecode.html I explained how to use %PerfTime system variable for determining elapsed time for your PeopleCode programming constructs. That way you can optimise the logic of your PeopleCode program.
