PeopleSoft Performance Guidelines April2021

PeopleTools Performance
Guidelines
PeopleSoft Technical Reference Paper
April 2021
Copyright © 2021, Oracle and/or its affiliates
Public
1 Technical Reference Paper / PeopleTools Performance Guidelines

Purpose Statement
This technical reference paper is a practical guide to use in conjunction with your organization’s performance tuning
plan. Performance tuning requires systematic testing of various settings in order to find the most beneficial
combination given your organization’s hardware and workload. Because each implementation of the PeopleSoft
system is different, this technical brief does not attempt to provide specific guidelines. Rather, it includes basic
recommendations to be used as a starting point in your planning, describes some common pitfalls, and gives
suggestions for the best approach to use in researching problems and solutions.
Disclaimer
This document in any form, software or printed matter, contains proprietary information that is the exclusive property
of Oracle. Your access to and use of this confidential material is subject to the terms and conditions of your Oracle
software license and service agreement, which has been executed and with which you agree to comply. This
document and information contained herein may not be disclosed, copied, reproduced or distributed to anyone
outside Oracle without prior written consent of Oracle. This document is not part of your license agreement nor can it
be incorporated into any contractual agreement with Oracle or its subsidiaries or affiliates.
This document is for informational purposes only and is intended solely to assist you in planning for the
implementation and upgrade of the product features described. It is not a commitment to deliver any material, code,
or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing
of any features or functionality described in this document remains at the sole discretion of Oracle. Due to the nature
of the product architecture, it may not be possible to safely include all features described in this document without
risking significant destabilization of the code.

Table of contents
Purpose Statement 2
Disclaimer 2
Structure of This Technical Reference Paper 7
Related Materials 7
Working with Application Server Guidelines 8
Determining the Need for Additional Memory 8
Determining Application Server Memory Usage (Microsoft Windows) 8
Determining Excessive Memory Swapping (Microsoft Windows) 9
Determining Application Server Memory Usage (UNIX) 9
Determining Excessive Memory Swapping (UNIX) 10
Managing Application Server Recycle Count 10
Managing Application Server Dynamic Recycle (PeopleTools 8.53 and
Prior) 11
Managing Application Server Recycling with ProcessRestartMemoryLimit
(PeopleTools 8.54 and Later) 11
Working with Application Server Cache Options 12
Understanding Application Server Cache Options 12
Enabling Non-Shared File Cache 12
Enabling Shared File Cache 12
Enabling Database Cache (PeopleTools 8.51 and Later) 13
Loading Application Server Cache (LOADCACHE) 13
Preloading Cache (PeopleTools 8.48 and Later Versions) 13
Using Application Server Cache Over NFS 14
Working with Guidelines for Application Server Instances 15
Managing PSAPPSRV Instances 15
Using Parallel Boot 15
Setting Application Server JVM Options 15
Confirming Oracle Tuxedo Version and Minimum Rolling Patch
Installation 16
Working with Web Server Guidelines 17
Confirming Web Server, Service Pack, and JRE Installation 17
Reducing System Resource Usage Using Jolt Session Pooling 17
Reducing Homepage Loading Time Using Parallel Pagelet Loading 17
Working with Oracle WebLogic Guidelines 19
Confirming the JRE Version 19
Increasing File Descriptors 19

Lowering TCP/IP Cleanup and Timeout Settings 19
Managing and Monitoring JVM Heap Size and Garbage Collection 19
Capturing JOLT Request Timing Traces 20
Working with IBM WebSphere Guidelines (PeopleTools 8.56 and Prior) 22
Managing IBM WebSphere Log Levels 22
Enabling Just In Time (JIT) Option and Skipping Class Verification 22
Setting Up and Configuring IBM WebSphere 22
Setting the Thread Count 23
Managing JVM Heap Size and Other JVM Options 23
Disabling Servlet Reload 24
Capturing JOLT Request Timing Trace 24
Working with Web Browser Configuration Guidelines 26
Understanding Web Browser Configuration 26
Confirming Installed Browser Versions 26
Managing Browser Compression 26
Managing Web Server Caching Options 27
Managing Navigation Page Caching 28
Maintaining Persistent Socket Connections 29
Reducing TCP Wait Times 29
Managing Timeout Settings 30
Reviewing Internet Explorer Performance 33
Working with Integration Broker Configuration Guidelines 34
Configuring the PSBRKHND Message Broker Handler 34
Optimizing Message Queues versus Message Consumption 34
Using Message Segments for Oracle-Delivered Full-Synchronous Service
Operations 35
Optimizing One Message versus Multiple Messages per Queue 35
Tuning PSADMIN Parameters for Asynchronous Messaging 35
Tuning PSADMIN Parameters for Synchronous Messaging 37
Configuring Dedicated Message Servers for High-Volume Asynchronous
Messaging 37
Configuring Dedicated Multiple Domains for High-Volume Asynchronous
Messaging 38
Working with Asynchronous Messaging 38
Improving Response Times for Synchronous Messaging 40
Configuring Load Balance Intervals (PeopleTools 8.48 and Later) 40
Implementing Primary/Secondary Load Balancing 40
Reducing Maximum Asynchronous Message Size 40

Using Multi-Threading to Send Groups of Messages in Parallel
(PeopleTools 8.46 and Later) 40
Troubleshooting Pub/Sub Errors on Application Server Start Up 41
Managing Operating System Settings 42
Managing Call Telephony Integration (CTI) 43
Using PSAE and PSAESRV 44
Managing Reporting Tools 45
BI Publisher (PeopleTools 8.48 and Later) 45
Business Objects Enterprise (PeopleTools 8.48 and Later) 45
Managing Monitoring Tools 46
PeopleSoft Ping 46
PSADMIN 46
PeopleSoft Performance Monitor 46
Online User Experience Enhancements 47
Understanding Online User Experience Enhancements 47
Auto-Complete (Type Ahead) 47
Look and Feel 47
Partial Page Refresh (AJAX Updates) 47
Full AJAX Support for the PeopleSoft Pure Internet Architecture 47
Modal Windows 48
Mouse-Over Pages 48
Deferred Mode versus Interactive Mode 48
Query Access Service (QAS) 49
Understanding Query Access Service (QAS) 49
Executing QAS Synchronous Queries 49
Executing QAS Asynchronous Queries 49
Executing QAS Sync/Poll Queries 50
QAS Performance Considerations 50
Configuration Recommendations 50
Feature Specific Recommendations for PeopleSoft Infrastructure 51
Pivot Grid 51
Classic Homepage and Dashboard 52
Fluid Homepage 53
Secure Enterprise Search (SES) (PeopleTools 8.55 and Prior) 53
Elasticsearch 54
Kibana 54
Related Action Menu 56
Push Notification Framework 56

Tile Event Refresh Considerations 57
File Attachments 57
Revision History 58

Structure of This Technical Reference Paper
This technical brief provides guidance across the major PeopleSoft Pure Internet Architecture components:
application server, web server, web browser, integration broker, and OS kernel.
Oracle updates this document as needed so that it reflects the most current feedback from the field. Therefore, the
structure, headings, content, and length of this document may vary with each posted version. To see if the document
has been updated since you last downloaded it, compare the date of your version to the date of the version that is
posted on My Oracle Support.
Related Materials
See the following resources for information on the PeopleSoft systems:
 PeopleSoft on Oracle Help Center
 PeopleSoft Information Portal
Additionally, you should be familiar with the documentation that is delivered with Oracle Tuxedo, Jolt, and WebLogic.
If you are using IBM WebSphere, we recommend that you read IBM’s documentation on WebSphere. See your
PeopleSoft installation and administration documentation for directions on accessing the Oracle and IBM
documentation.

Working with Application Server Guidelines
This section discusses how to:
 Determine the need for additional memory.
 Determine application server usage. (Microsoft Windows)
 Determine excessive memory swapping. (Microsoft Windows)
 Determine application server usage. (UNIX)
 Determine excessive memory swapping occurs. (UNIX)
 Manage application server recycling count.
 Manage application server recycling dynamically (PeopleTools 8.53 and Prior).
 Manage application server recycling with ProcessRestartMemoryLimit (PeopleTools 8.54 and Later).
Determining the Need for Additional Memory

Lack of memory resources on the application server is the most common cause of serious online performance issues.
If you are experiencing more than four (4) seconds of response time for every web page refresh (as opposed to just a
few transactions), lack of application server memory is probably the cause. “Memory swapping” is the most likely
culprit. Here are some tips to help determine if you need more memory for your application server:
 Ensure that you don't have too many PSAPPSRV processes booted.
During peak usage times, you should see some small amount of queuing for the PSAPPSRV processes. If you
have too many processes, performance is compromised. The extra PSAPPSRV processes not only take up
memory space and CPU time from the operating system, but also each PSAPPSRV may not be sufficiently cached
(that is, each PSAPPSRV caches only a portion of the user panels). Fully caching each PSAPPSRV process takes
more time. You can use Queue Status in PSADMIN to see the queue length. The # Queued column displays the
queue length for that application server process.
 Starting with PeopleTools 8.55, the PeopleSoft Health Center can also be used to monitor the system.
The memory footprint for PSAPPSRV varies between applications. Refer to the hardware requirements for
PeopleSoft PeopleTools in My Oracle Support, Certifications.
 Ensure that you include all domains running on the host in your calculations.
A common problem is having too many large domains on one computer with insufficient memory.
 Check the memory utilization on the application server when you experience performance problems.
 Check for memory swapping by using the memory monitoring procedures outlined in the topics described later in
this section.
If you determine that memory swapping is occurring, add more memory, or reduce the number of domains or
PSAPPSRV processes on the computer. You may scale horizontally by moving excess domains to other available
machines.
Determining Application Server Memory Usage (Microsoft Windows)

To determine PeopleSoft Application Server memory usage under Microsoft Windows:

1. Use Windows Task Manager to monitor all the PeopleSoft processes. PeopleSoft process names begin with PS.
2. Start Task Manager and select View from the menu bar, and then select Select Columns.
3. Pick the Memory Usage and Virtual Memory Size columns.
4. Sort the process by name, and the two memory columns will tell you approximately the amount of memory that
each PeopleSoft process is using.
Memory Usage is not the entire memory consumption of the process, but only the amount of physical RAM that
the process is using. However, with Microsoft Windows, an application may be using much more virtual memory
(that is, the paging file) than physical memory. Therefore, both fields must be considered when determining the
memory consumption of the process.
The Memory Usage column includes the shared libraries loaded into each process; therefore, if you add up all the
processes, you will be “double counting” the shared libraries portion. Because PeopleSoft shares many of the
common libraries, the summation of all PeopleSoft processes is a quick estimator, not an absolute measurement of
memory usage.
Note: The total memory usage and the virtual memory size of the combined PeopleSoft processes should not be
greater than 70 percent of the real memory of the server.
Determining Excessive Memory Swapping (Microsoft Windows)

To determine if excessive memory swapping happens under Microsoft Windows:
1. Start the Windows Performance Monitor, perfmon.
2. Add the Object Counter, under Memory, and then the Page/sec.
Pages/sec is the number of pages read from the disk or written to the disk to resolve memory references to pages
that were not in memory at the time of the reference. This is the sum of Pages Input/sec and Pages Output/sec. This
counter includes paging traffic on behalf of the system cache to access file data for applications. This value also
includes the pages to/from non-cached mapped memory files. This is the primary counter to observe if you are
concerned about excessive memory pressure (that is, thrashing) and the excessive paging that may result.
Note: When page/sec is greater than 100 hard pages per second, there is a swapping problem. Reduce the number of
PSAPPSRV processes or add more memory to the server.
Determining Application Server Memory Usage (UNIX)

To help the end user better understand the memory consumption and CPU usage of the PeopleSoft application server
domain, PeopleSoft has created several UNIX vendor-specific shell scripts to monitor the Performance Monitor
parameters. You can obtain the monitoring shell scripts from the same page where you obtained this technical
reference paper (My Oracle Support, Doc ID 747389.1).
Here is sample output of the ps_chk_domain script:

Please Enter your application server domain name?
PT84
Please Enter interval in seconds?
10
Please enter # of interval's?
100
Tue Oct 23 23:00:33 PDT 2001
For all PS Processes:
Resident memory size is: 123.543 MB
CPU for PS Processes: 11 %
Virtual memory size is: 198.098MB
For all PSAPPSRV Processes:
Resident memory size is: 108.453MB
CPU for PS Processes: 9%
Virtual memory size is: 106.559 MB
Resident memory refers to the real physical memory currently required by the process for its operation.
Virtual memory refers to the process virtual address size, which includes memory that has been paged out to the
physical disk. If the virtual memory continues to increase, you should lower the value of the RecycleCount parameter
of the application server in PSADMIN.
The output of ps_chk_domain.sh script divides the portion of PSAPPSRV processes from the entire domain so that
the system administrator can get a better understanding of the distribution of the memory resources.
Determining Excessive Memory Swapping (UNIX)

To determine if excessive memory swapping occurs under UNIX, use the vmstat command to determine if the
operating system is swapping memory.
To check whether paging is a problem, run the vmstat command and look at the pi column to see if you are doing
much paging in, and the po column for paging out.
You can also run the sar -q command to check paging or run the vmstat -s command and take multiple samples to
see if the page ins and outs to paging space are the majority of the total paging.
Managing Application Server Recycle Count

The application server recycle count parameter, Recycle Count, located in PSADMIN, dictates the number of services
after which the application server automatically restarts.
Background
Application server processes use physical runtime memory to cache Panel objects in order to speed up user response
time, instead of fetching the PeopleSoft Pure Internet Architecture (PIA) page objects from the database server every
time. However, as the number of requests serviced by the application server increases, the amount of physical
memory occupied by the application server processes also increases. When the amount of memory occupied by the
application server becomes too large relative to the real memory available at the time, paging to a file system occurs
and impacts user experience.
To effectively manage the memory footprint of the application server, keep the recycle count at a realistic level. When
the application server reaches the specified recycle count value, the application server terminates and restarts itself.
When the application server terminates, the occupied memory is released.
Recommendation
The recommended application server recycle count setting is 10000.
Adjust the recycle count so that no memory swapping is introduced because of a high recycle count value. (See the
previous section for information how to determine memory swapping.)
Managing Application Server Dynamic Recycle (PeopleTools 8.53 and Prior)

Application server restarts can cause inconsistencies in response times. If you set the recycle count too low, more
process restarts will occur. If you set the recycle count too high, the processes can grow big, resulting in reduced
response times due to swapping or increased likelihood of crashing due to memory violation.
PeopleTools provide a feature to recycle an application server process when its memory growth exceeds a
configurable threshold. When you enable this feature, the application server will service (at a minimum) the number
of requests specified by the recycle count. The application server will continue to accept requests beyond the recycle
count until its memory growth (that is not due to metadata loads) exceeds the configurable threshold. Note that if an
application server exceeds the threshold before reaching the recycle count, then the system logs a delaying recycle
message. To use this feature, consult the product documentation for PeopleTools: System and Server Administration,
“PSAPPSRV Options.”
If interested in this feature, initially experiment with it in a staging environment to determine an appropriate threshold
for your specific applications and environments before using the feature in production. Optionally, you can use the
recycle count achieved using the memory growth option in the staging environment as a static recycle count in the
production environment.
Managing Application Server Recycling with ProcessRestartMemoryLimit (PeopleTools 8.54 and Later)
Starting with PeopleTools 8.54, application server dynamic recycling has been replaced by the
ProcessRestartMemoryLimit parameter, which can be set in the [Domain Settings] or the [PSAPPSRV Options] section
in the application server configuration file.
When the server processes exceed the limit set by this parameter, the system restarts, or recycles, them. If set to zero
(0), this feature is disabled and the system recycles server processes according to the recycle count setting.
For information on how to configure this setting, see the PeopleTools: System and Server Administration product
documentation.

Working with Application Server Cache Options
This section provides an overview of application server cache options, and discusses how to:
 Enable non-shared cache.
 Enable shared cache.
 Enable database cache. (PeopleTools 8.51 and later.)
 Load persistent application server cache.
 Preload cache.
 Use application server cache over NFS.
Understanding Application Server Cache Options

Caching enables the system to store definitions locally on the application server, eliminating unnecessary trips to the
database server. If caching were disabled, the system would need to retrieve definitions from the database with each
request, every time. This adds significant overhead to each transaction and affects system response times.
To improve performance, the application server uses a caching mechanism that keeps commonly used objects in
memory, or file form on the application server (and starting with 8.51 in database cache). This reduces the need for a
database request each time that you access a component or page. As you access more pages and components, more
data is stored in the application server cache. However, if you have not already accessed a page, for example, that page
won’t exist in the current cache, and you may experience a slower response time as the system requests the page from
the database.
Application server caching can be configured as non-shared file cache, shared file cache, or, starting in PeopleTools
8.51, database cache. By default, non-shared file cache is enabled.
The application server loads the objects into memory as the objects are accessed and keeps them in memory. For all
subsequent requests to the same cached objects that are already in memory, the application server returns these
objects from memory directly.
The application server reads from either the persistent cache or the database and rebuilds the cache in memory when:
 The requested object has been changed.
 The server reboots (after reaching the recycle count or manual reboot
Enabling Non-Shared File Cache

With non-shared file cache, each application server process maintains its own separate cache files. The application
server can update its cache files if the cached metadata objects change.
When adding additional application server instances, you can speed up the cache building on the new instances by
copying the cache files from the existing instance to the new instances (as long as they’re on the same OS platform).
As described previously, non-shared cache is enabled by default.
Enabling Shared File Cache

With the shared file cache mode, all server processes point to a common set of cache files. The common cache is
updated by the LOADCACHE process. The application server treats the cache files as read-only. The application server
processes cannot update the cache files for any delta, and each access to any changed metadata will result in a costly
database access. If cached metadata objects are changed, you may choose to rerun LOADCACHE to update the shared
file cache.

Note: You must load all the necessary cache objects before you can enable the Shared File Cache feature.
Enabling Database Cache (PeopleTools 8.51 and Later)

Database cache is an additional cache option introduced since PeopleTools 8.51. Database cache provides a centralized
way of managing cached objects. With database cache, all server processes point to the common cache stored in the
database. Any metadata changes are updated to the database cache after being accessed the first time. In extremely
large concurrent user scenarios, using database cache can be slower than non-shared file cache. To enable database
cache, set EnableDBCache=Y in the psappsrv.cfg file.
The application server loads the objects into memory as the objects are accessed, and keeps them in memory. For all
subsequent requests to the same cached objects that are already in memory, the application server returns these
objects from memory directly.
The application server reads from the database and rebuilds the cache in memory when:
 The requested object has been changed.
 The server reboots (after reaching the recycle count or manual reboot).
When the application server rebuilds cache in memory, there will be extra load on the database server. During this
period, cache table retrievals will result in many database reads. After all cached objects have been retrieved into the
application server memory, the extra load on the database server will be eliminated.
Database cache adds slight overhead to the database server in CPU and memory when requested objects are retrieved
from the database cache into the application server memory. A dedicated database connection used to handle cache
table retrieval and updates consumes additional resources on the database server. In contrast, the application server
allocates less memory when using database cache because there are no cache files to be handled.
The end-user response time when using database cache is very comparable to that of using file cache. The exception is
for first-time access when the requested objects have not been loaded into the application server memory. Because of
the slower speed of database access compared to file access, the application server spends a longer time loading cache
from the database than from the cache files for the first access of the object. Once the cache is in the application server
memory, the performance is exactly the same because all requested objects come from the application server memory.
For Oracle databases, refer to the document “Optimize PeopleTools DB Caching network parameters in Oracle DB”
(Doc ID 1426813.1) on My Oracle Support for parameter settings that may yield better performance.
Loading Application Server Cache (LOADCACHE)

To build the persistent cache, PeopleTools provides a Load Application Server Cache process (which executes the
LOADCACHE PeopleSoft Application Engine program) to build most of the managed objects into persistent cache,
either in non-shared file cache, shared file cache, or database cache. Running LOADCACHE in parallel mode is
recommended. Total processing time using parallel mode is roughly 15 percent faster than using serial mode.
For instructions on how to execute this process, see the documentation for PeopleTools: System and Server
Administration, “Load Application Server Cache”. For additional information, refer to “E-AS: Understanding memory
usage and associated settings in PeopleSoft Application Server processes” (Doc ID 1457385.1) on My Oracle Support.
Preloading Cache (PeopleTools 8.48 and Later Versions)

In PeopleTools 8.48 and later, you can elect to preload cache or preload memory cache with commonly used
components.
Preloading cache involves creating a project containing commonly used components and then referring to these
projects in the PSADMIN settings PreloadMemoryCache and PreloadFileCache. (Starting in PeopleTools 8.51,
PreloadFileCache is deprecated. PreloadCache should be used.) To understand and use this feature, see the
documentation for PeopleTools: System and Server Administration, “Configuring an Application Server Domain to

Preload Cache”, and “Cache Setting.” For additional information, refer to “E-AS: Understanding memory usage and
associated settings in PeopleSoft Application Server processes” (Doc ID 1457385.1) on My Oracle Support.
Using Application Server Cache Over NFS

All application server file cache features can work on those application server domains that are running on the NFS
storage. Cached objects are stored in remote storage and accessed via the NFS protocol instead of local file system.
NFS version 4 is the recommended option to use to deploy the application server domain. For the Linux operating
system, both server and client support NFS version 4 from kernel 2.6 and onwards. (Using NFS version 3 to deploy the
application server domain is not recommended, due to file locking issues and poor IO performance.)
The following example illustrates mounting NFS version 4 to a client:
nfsserver:/ /mnt/NFS nfs4

auto,bg,rw,proto=tcp,hard,nointr,suid,rsize=131072,wsize=131072,timeo=600
Be aware of the noac option. This option tells the NFS server not to cache file attributes. This mount option causes
severe performance degradation especially when running the LOADCACHE Application Engine program. Remove this
option if it is in the option list.

Working with Guidelines for Application Server Instances
 Manage PSAPPSRV instances.
 Use parallel boot.
 Set application server JVM options.
 Set process-specific JVM options
 Confirm the Oracle Tuxedo version and minimum rolling patch installation.
Managing PSAPPSRV Instances

Keep the number of PSAPPSRV instances low. PSAPPSRV must cache PeopleSoft meta-objects to be effective. If there
are too many PSAPPSRV process instances, it makes it difficult to fully cache all of them. Too many process instances
in an Oracle Tuxedo domain on Microsoft Windows becomes even more troublesome because the Bulletin Board
process tries to use the same PSAPPSRV process ID and does not use the round-robin method as in UNIX.
Start with two to four PSAPPSRV processes per CPU core. If the application server machine is 100 percent utilized under
load, reduce the number of PSAPPSRV processes until there is some idle CPU. If as a result there is significant queuing,
then you may need additional application server hardware.
In general, it is best to allow a small amount of queuing during peak working hours. If the application server machine is
more than 80-percent loaded, then we do not recommend spawning an extra PSAPPSRV instance to handle high-
volume workload. Every time that a new PSAPPSRV process starts, the process must establish its cache, which takes
time, CPU, and memory. We recommend setting MIN and MAX to the same number.
Using Parallel Boot

PeopleTools 8.48 and later versions provide an option in PSADMIN for parallel booting the application server. Use
parallel booting to significantly speed up the process of starting a domain.
Setting Application Server JVM Options

Most PeopleSoft processes running in the Oracle Tuxedo domain support Java by embedding a Java virtual machine
(JVM) inside the native process. PeopleTools provides a JavaVM Options parameter in the psappsrv.cfg and psprcs.cfg
files for passing Java options to the embedded JVM when it is loaded. Starting with PeopleTools 8.53 the minimum and
maximum heap sizes for the embedded JVM are set to the default values listed in the following table:
JVM Default values
JAVA HEAP SIZE PARAMETER DEFAULT VALUE
Minimum Java heap size -Xms –Xms256m
Maximum Java heap size. -Xmx –Xmx512m
Set these values in the [PSTOOLS] section of the configuration file.

Prior to PeopleTools 8.53, no defaults were delivered. Regardless of the default values delivered by Oracle for
PeopleSoft systems, it is always necessary to tune the minimum and maximum heap sizes to values appropriate to
your needs. Use standard Java heap tuning practices to find the appropriate values.
Starting with PeopleTools 8.55, the PeopleSoft Health Center can also be used to assist in tuning the embedded JVMs.

For additional information, refer to “E-AS: Understanding memory usage and associated settings in PeopleSoft
Application Server processes,” My Oracle Support, Doc ID 1457385.1.
Confirming Oracle Tuxedo Version and Minimum Rolling Patch Installation

Confirm that the required Oracle Tuxedo version and the minimum rolling patch are installed specific to the
PeopleTools release and operating system from the Certifications section of My Oracle Support.
Use the following command to verify the installed Oracle Tuxedo rolling patch from the rolling patch level file:
<TUXDIR>\udataobj\patchlev

Working with Web Server Guidelines
 Confirm web server, service pack and JRE installation.
 Reduce system resource usage using Jolt session pooling.
 Reduce homepage loading time using parallel pagelet loading.
Confirming Web Server, Service Pack, and JRE Installation

Confirm that the required web server version, service pack, and JRE version are installed specific to the PeopleTools
release and operating system from the Certifications section of My Oracle Support.
Reducing System Resource Usage Using Jolt Session Pooling

In PeopleTools 8.48 and later releases, Jolt session pooling is enabled by default. Without Jolt session pooling, each
user session requires a dedicated Jolt session between the web server and the application server, which consumes
valuable system resources.
With Jolt session pooling, the Jolt sessions are shared among users, which reduces system resource usage. In an
internal test on a two-CPU Microsoft Windows environment, it was possible to run 500 users with Jolt session pooling
versus only 280 users without Jolt session pooling.
To check the Jolt session pooling setting, select web.xml under the appropriate directory for each web server platform.
To verify the Jolt session pooling setting, find this section in the configuration.properties:
## qc="1", sd="Jolt Pooling", dt="c", ld="Enable Jolt Pooling"
joltPooling=true
For more details on Jolt session pooling, refer to the document “E-AS: Master Note on Jolt Pooling,” My Oracle
Support, Doc ID 1273071.1.
Reducing Homepage Loading Time Using Parallel Pagelet Loading

Parallel pagelet loading is a performance improvement feature available beginning with the PeopleTools 8.52 release. It
allows for multiple pagelets to be requested in parallel on the web server, rather than the regular sequential loading
mode. Using parallel load, the total homepage loading time for a typical homepage containing seven pagelets is
reduced by 15 percent.
Enabling Parallel Pagelet Loading

Prior to PeopleTools 8.53.01, parallel loading is off by default. This section describes how to turn parallel loading on.
Note that enabling Jolt session pooling is required to use pagelet parallel loading.
To turn on parallel pagelet loading:
1. Access the configuration.properties file:
<web server home path>\<domain name>\applications\peoplesoft\PORTAL.war\WEB-

INF\psftdocs\ps\configuration.properties
2. Enable parallel loading by setting the following parameter equal to true:
parallelLoading=true
3. You should also enable Jolt session pooling for better performance:

joltPooling=true
Using Parallel Pagelet Loading

This section provides recommendations for using parallel pagelet loading to improve system performance.
Adjusting Web Server and Application Server Domains for Optimal Performance
Parallel pagelet loading enables you to process multiple pagelets concurrently to shorten the total roundtrip time to
load the homepage. While the overall total server resource usage is similar to non-parallel load, the peak usage may
increase when parallel load is enabled. Adjust the number of web server and application server domains to achieve
optimal performance.
Web Browser Tuning

Newer browsers generally have better performance than older browsers. Newer browsers support more concurrent
HTTP connections. For Internet Explorer 8 and above, Mozilla Firefox and Google Chrome, the default concurrent
connections is six.
Web Proxy Server Tuning

If you use a proxy server, make sure the proxy server allows more than six concurrent HTTP connections to the PIA
web server. Increase the proxy server’s concurrent HTTP connection limit to more than six, or switch to another proxy
server without this limitation.
Web Server Tuning

While the overall CPU usage is similar between sequential and parallel loading of pagelets, turning on the pagelet
parallel loading feature will increase the web server’s workload at peak time. Set the web server’s JVM heap size to a
minimum of one gigabyte (GB) on a 32-bit system or two GB on a 64-bit system to handle the peak workload.
Jolt Client Cleanup Timeout

The Jolt Client Cleanup Timeout parameter in the psappsrv configuration file specifies the inactivity interval permitted
for the server-side of a Jolt session. This value is measured in minutes, and the default value is 10.
Parallel pagelet loading uses a Jolt pooling session to connect to the application server. During workload peak time,
keeping an adequate number of Jolt pooling sessions available improves parallel pagelet loading performance. The Jolt
pooling session will be closed if the session’s idle time is longer than the Jolt client cleanup timeout setting. So a long
timeout duration will avoid creating Jolt Pooling sessions between two close workload peak time durations, thus
improving the pagelet parallel loading performance.
Specifying too low a value can cause unnecessary reinstantiation of resources for clients who surpass this inactivity
interval; specifying too high a value can keep unnecessary server-side resources allocated. The value should be based
on your application server machine’s hardware resources.
The Jolt client cleanup timeout parameter is in the [JOLT Listener] section in the psappsrv.cfg file as well as in the
Tuxedo Configurations. Any change to this value will require the corresponding changes in both locations.
Use PSADMIN to configure this parameter.
1. PSADMIN, Application Server, Administer a domain, DOMAIN_NAME, Configure this domain, Custom
Configuration.
2. Press Enter until you reach Jolt Listener. Press 'n'.
3. In the series of questions that follow, you can see Client Cleanup Timeout. Change that value.
4. Continue to finish configuring the domain. This will change both the Tuxedo Configuration and psappsrv.cfg.
For more detail, refer to the information on JOLT Listener/Client CleanupTimeout in the product documentation
PeopleTools: System and Server Administration, “Application Server Timeouts.”

Working with Oracle WebLogic Guidelines
 Confirm the JRE version.
 Increase file descriptors.
 Lower TCP/IP cleanup and timeout settings.
 Manage and Monitor JVM heap size and garbage collection.
 Capture JOLT request timing traces.
Confirming the JRE Version

Go to My Oracle Support, Certifications tab, to confirm the installed JRE is certified. Note that you may require OS
patches.
Increasing File Descriptors

A file descriptor is required every time one of the following occurs:
 A file is opened.
 Oracle WebLogic reads a *.class file.
 Jolt connections PIA/Portal make to the application server.
 A connection opens back to a client.
 Other socket-based communication occurs on the machine.

To increase the file descriptors for UNIX, use the following command, which raises limit to 4096:
ulimit –n 4096
In Microsoft Windows environments there is not an explicit parameter for the number of file descriptors. The
parameter is implicitly limited by hardware resources (mainly system memory).
Lowering TCP/IP Cleanup and Timeout Settings

Socket-based applications that are opening and closing hundreds or thousands of sockets must have their sockets
marked as closed. Once a process closes a socket, it is marked as closed only until the operating system, based on a
cleanup/flush timeout, makes that socket available again. The default timeout value for this is 11 (eleven) minutes.
Lower this value to 1 (one) minute.
Starting with PeopleTools 8.55, you may also reference the PeopleSoft Health Center to monitor TCP Socket states for
the web server.
Oracle also provides information on this topic.
See the Reducing TCP Wait Time section in this document to learn how to change the TCP Wait Time for a specific OS.
Managing and Monitoring JVM Heap Size and Garbage Collection

This section discusses managing and monitoring the JVM heap size and JVM garbage collection.
Understanding the JMV Heap Size and JVM Garbage Collection

The JVM heap space is the memory region where Java objects, both live and dead, reside. When the Java heap runs
out of space, the Java Garbage Collector (GC) invokes to deallocate the dead objects and free up more space for the
program to continue its operation.

The goals of tuning the heap size are two-fold:
1. Minimize the amount of time that you spend doing garbage collection, while,
2. Maximizing the number of clients that you can handle at a given time.
Note that the JVM cannot service user requests during garbage collections.
Setting the JVM Heap Size

Oracle recommends setting the JVM heap size to a minimum size of 256 MB and to a maximum size of 512 MB. Setting
the JVM heap size to a greater minimum value avoids the performance hit incurred by dynamically growing the JVM,
and improves predictability. It also lessens the frequency of JVM garbage collection. The requirements may vary
depending upon your environment. Monitor your environment and increase these values as needed.
Monitoring JVM Heap Usage and JVM Garbage Collection

To monitor the amount of heap usage and the time that Oracle WebLogic takes for the garbage collection (GC), you
can add the verbosegc switch to the setEnv.cmd script file. You have to start Oracle WebLogic from the command line,
with startPIA.cmd (instead of the Microsoft Windows service), to see the garbage collector output. In setEnv.cmd:
SET JAVA_OPTIONS=-hotspot –Xms256m –Xmx256m –verbosegc

Here is a sample output of the GC:
Sat Nov 24 22:15:34 PST 2001:<I> <WebLogicServer> Invoking garbage collection
Sat Nov 24 22:15:34 PST 2001:<I> <GC> GC: Before free/total=46867368/67108856 (69%)
<GC: freed 249213 objects, 15440712 bytes in 396 ms, 95% free (51334096/53687088)>
<GC: init&scan: 6 ms, scan handles: 105 ms, sweep: 124 ms, compact: 161 ms>
<GC: 0 register-marked objects, 140 stack-marked objects>
<GC: 1 register-marked handles, 559 stack-marked handles>
<GC: refs: soft 0 (age >= 32), weak 0, final 559, phantom 0>
<GC: compactHeap: blocks_moved=249506>
<GC: 0 explicitly pinned objects, 35 conservatively pinned objects>
<GC: last free block at 0x02A11B2C of length 35906768, is at end>

Verbose GC is fairly expensive. Starting with PeopleTools 8.55, for lower-cost heap usage monitoring, you can
reference the JVM Heap monitoring in the PeopleSoft Health Center.
See the PeopleTools: Performance Monitor product documentation for information on PeopleSoft Health Center.
Capturing JOLT Request Timing Traces

To capture JOLT request timing traces:
1. Using the Custom Properties page of the current Web Profile, add a String property named auditPWD and set the
value.
You will use this password in a later step.
2. Stop the web server.
3. In the Oracle WebLogic domain directory, open startPIA.cmd or startPIA.sh and add a command-line option -
Dloggersize=0 to the firing of the java process.

4. Restart the web server
5. Before logging on, submit the following URL to reset the existing log:
http://<hostname:port number>/psp/ps/?cmd=resetlog&pwd=<password from step 1>
A screen of messages appears on the browser window. The messages represent the log that has been collected.
6. Point to the logon URL and logon as usual.
After logging on, point to the previous URL again (http://<hostname:port

number>/psp/ps/?cmd=resetlog&pwd=<password from step 1>) to retrieve the log.
7. Copy and paste the log from the browser to a text file.

Working with IBM WebSphere Guidelines (PeopleTools 8.56 and Prior)
This section discusses how to
 Manage IBM WebSphere log levels.
 Enable the JIT compiler and skip bypass verification.
 Set up and configure IBM WebSphere.
 Set the thread count.
 Manage JVM heap size and other JVM options.
 Disable servlet reload.
 Capture JOLT request timing trace.
Managing IBM WebSphere Log Levels

This section discusses managing IBM WebSphere log level settings to improve web server performance. This applies to
PeopleSoft PeopleTools 8.56 and prior releases.
Reducing Log Levels

In some earlier IBM WebSphere versions, the log detail level is set as Info by default. This setting produces too much
logging data to the log file, which degrades performance in internal performance tests.
To improve performance up to 20 percent, change the log detail level from *=info to *= severe.
To set the log level:
1. Log in to the IBM WebSphere admin console.
2. Navigate to Troubleshooting, Logs&Trace, server1, Change Log Detail Levels.
3. Set the value to *=severe.
Reducing the Number of Logs

To reduce the number of logs written in the webserver log files, disable the diagnostic trace log.
1. Log in to the IBM WebSphere admin console.
2. Navigate to Troubleshooting, Logs&Trace, server1, Diagnostic trace.
3. Clear the Enable log check box.
Enabling Just In Time (JIT) Option and Skipping Class Verification

Ensure that JIT is enabled by default in the Admin console. If you disable the JIT compiler, throughput decreases
noticeably. Therefore, for performance reasons, keep JIT enabled.
To bypass class verification use the following JVM property: -Xverify:none.
When you set this JVM value, the class verification stage is skipped during class loading. By using this property with the
JIT compiler enabled, performance tests indicate that start-up time improves up to 15 percent.
Setting Up and Configuring IBM WebSphere

Before you begin the installation, review the PeopleTools Certifications on My Oracle Support to make sure that you are
installing IBM WebSphere into a supported environment.

For detailed installation instructions, especially the required e-fixes needed for IBM WebSphere, see the IBM
WebSphere install document.
Setting the Thread Count

1. Locate server.xml at:
%PS_HOME%\webserv\{profile_name}\config\cells\{cell_name}\nodes\{node_name}\servers\server1\
2. Modify the thread pool maximumSize for web container:
<services xmi:type="threadpoolmanager:ThreadPoolManager"
xmi:id="ThreadPoolManager_1208430577007" enable="true">
...
...
<threadPools xmi:id="ThreadPool_1208430577008" minimumSize="10" maximumSize="50"

inactivityTimeout="3500" isGrowable="false" name="WebContainer"/>
...
...
</services>
3. Log in to the IBM WebSphere admin console and navigate to:
servers > Application server > server1 > Thread Pool > WebContainer.
4. Modify the thread pool maximumSize for the web container.
Managing JVM Heap Size and Other JVM Options

This section discusses managing the JVM heap size and other JVM options in IBM WebSphere.
Setting the JVM Heap Size

Refer to the Oracle WebLogic section Managing and Monitoring JVM Heap Size and Garbage Collection on how to
decide the JVM heap size.
The JVM heap size settings can be changed from the administrative console using these steps:
1. Expand Servers, Server Types, WebSphere application servers and click your server name.
2. Select Java and process management, Process definition, Java virtual machine.
The JVM Heap size can be adjusted by using the Xms: Initial Java Heap Size and Xmx: Maximum Java Heap
Size command-line parameters.
To adjust the JVM Heap size for IBM WebSphere version 8.5:
1. Log in to the IBM WebSphere admin console with the following URL:
http://<machine name>:<admin port number>/ibm/console.
To obtain the admin port number, see the AboutThisProfile.txt file present in PS_CFG_HOME/logs.
2. Enter your admin id and password that you have provided while deploying PIA.
3. On the left Navigation, select Servers > Application Servers.
4. Select your server name (default is server1).

5. Click Process Definition under Additional Properties.
6. Click Java Virtual Machine under Additional Properties.
Here you can change all the parameters where you need verbosegc and so on.
Disabling Servlet Reload

The servlet reload parameters in IBM WebSphere are located in the following location:
<PS_CFG_HOME>\<PeopleSoft Domain Name>\installedApps\<Domain Name>NodeCell\<domain
name>.ear\PORTAL.war\WEB-INF\ibm-web-ext-xmi
In the PSINTERLINKS/WEB-INF directory, such a file may not exist. If this is the case, create a file called ibm-web-
ext.xmi with the following content:
<webappext:WebAppExtension xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI"

xmlns:webappext="webappext.xmi" xmlns:webapplication="webapplication.xmi"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmi:id="WebAppExtension_1"
reloadInterval="0" reloadingEnabled="false" fileServingEnabled="true"
directoryBrowsingEnabled="true" serveServletsByClassnameEnabled="false">
<defaultErrorPage xsi:nil="true"/>
<additionalClassPath xsi:nil="true"/>
<webApp href="WEB-INF/web.xml#WebApp_1"/>
<extendedServlets xmi:id="ServletExtension_1">
<extendedServlet href="WEB-INF/web.xml#Servlet_1"/>
</extendedServlets>
</webappext:WebAppExtension>
Also copy the file ibm-web-bnd.xmi from the PORTAL/WEB-INF directory.

Moreover, %WAS_HOME%/<PeopleSoft web domain>/META-INF/ibm-application-ext-xmi should look like the
following example, with the reloadInterval line deleted:
<applicationext:ApplicationExtension xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI"
xmlns:applicationext="applicationext.xmi" xmlns:application="application.xmi"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmi:id="Application_ID_Ext" reloadInterval="0">

<application href="META-INF/application.xml#Application_ID"/>
</applicationext:ApplicationExtension>
Capturing JOLT Request Timing Trace

To collect JOLT request timing traces for IBM WebSphere:
1. Using the Custom Properties page of the current Web Profile, add a String property named auditPWD and set the
value.
You will use this password in a later step.
2. Stop the web server.
3. To set -Dloggersize=0, sign in to the WebSphere admin console.
Expand Servers > Server Types > WebSphere application servers, and click your server name.
4. Click Java and process management > Process definition > Java virtual machine.
Here you can add the parameter.
5. Restart the web server.
6. Before logging on, submit the following URL to reset the existing log:
http://<hostname:port number>/psp/ps/?cmd=resetlog&pwd=<password from step 1>.
A series of messages appears on the browser window, which comprise the log that has been collected.
7. Point to the logon URL and log on as usual.
8. After logging on, point to the previous URL again to retrieve the log:
http://<hostname:port number>/psp/ps/?cmd=resetlog&pwd=<password from step 1>
9. Copy and paste the log from the browser to a text file.
For more comprehensive data, repeat steps 5 through 8.

Working with Web Browser Configuration Guidelines
 Confirm installed browser versions.
 Manage browser compression.
 Manage web server caching options.
 Manage navigation page caching.
 Maintain persistent socket connections.
 Reduce TCP wait times.
 Manage timeout settings.
 Review Internet Explorer performance.
Understanding Web Browser Configuration

Take advantage of the browser’s caching ability to reduce the unnecessary checking and downloading of the same
Internet objects within an online transaction session. Here are the browser objects that most likely remain unchanged
during an online session, and which should be kept in the browser cache (verify the cache settings in the browser’s
Options configuration):
 Graphics objects
 Style sheets
 JavaScript files
 Some HTML pages (such as the PeopleSoft Pure Internet Architecture login page)
Confirming Installed Browser Versions

Confirm that you install the required browser version for your specific PeopleTools release and operating system, by
reviewing the Certifications section of My Oracle Support.
Managing Browser Compression

From PeopleTools 8.44 forward, you can enable compression between the web server and the browser by selecting the
Compress Response option in the PeopleSoft Pure Internet Architecture. To set this option, select PeopleTools, Web
Profile, Web Profile Configuration, select the web profile that you are using, and clear the Compress Response check
box to turn off compression. Gzip and Compress are supported. The check box is selected by default.
If the Compress Response References check box is selected, compression of additional resource files from web server
to the browser is enabled. Only files that have their mime types specified in the Compress Mime Types field are
compressed. Gzip and Compress are supported. The check box is cleared by default because there were some versions
of Internet Explorer with certain settings that did not support JavaScript and cascading style sheets (CSS) in
compressed format. However, that is a rare scenario; therefore, in general, this check box should be selected.
Note: The main purpose of compression is to reduce the amount of data to be transmitted. However, compression
comes at a price: extra CPU processing time. In cases where high-speed links are used and the gain in transmission
time does not justify the loss in CPU processing time, turn off compression.
The Compress Mime Types text field specifies a comma-delimited list of the MIME-type objects that should be sent in
compressed form to the browser. Note that this is applicable only when Compress Response References is set to true.
Gzip and Compress are supported. Here is the default: application/x-javascript,text/javascript,text/css,text/html.

Managing Web Server Caching Options
Caching improves system performance by reducing service requests from the web server to the application server. For
PeopleTools 8.44 and later, cache settings are configured using the Web Profile Configuration page in the PeopleSoft
Pure Internet Architecture. Go to PeopleTools > Web Profile > Web Profile Configuration, select the Web Profile that you
are using, and then select the Caching tab.
The following table lists and describes some of the settings on the Web Profile Configuration – Caching page for
caching on the web server:
Web Server Caching Settings
FIELD DESCRIPTION
Cache Proxied JavaScripts The portal caches proxied JavaScripts to improve

performance if the Cache Proxied JavaScripts check
box is selected. The check box is selected by default.
Cache Target Content Select the Cache Target Content check box to allow
caching of target content. Clearing this check box
disables all target content caching in the portal servlet,
even if the target tag specifies cached content. By
default, Cache Target Content is enabled.
Cache Portal Objects If Cache Portal Objects is selected, the portal servlet
(psp) will cache the following objects in web server
memory:
Portal registry.
Node. (Remote and local.)
Content references.
Template. (Static only.)
If Cache Portal Objects is selected, object changes won’t

take effect until the objects become stale and are
refreshed (see Cache Stale Interval) or you restart the
web server.
This option is selected by default.
Cache Stale Interval The Cache Stale Interval is the amount of time, in
seconds, before portal cache is considered stale and
updated with the latest copy from the application
server. In other words, this is the amount of time before
changes to cached objects take effect. This setting
applies to the same objects as Cache Portal Objects.
Here is the default setting: 86200 (24 hours).
Cache Purge All Hit Count The portal automatically throws away all cache entries
in memory after the number of requests specified in

Cache Purge All Hit Count. This setting applies for all
websites on this web server. Setting this value to -1
disables hit count purging. The default setting is 1000.
Homepage Caching
Homepages can also be cached on each user's browser. This means that the browser does not access the web server
after the homepage is initially retrieved. You can turn this feature on or off, and also adjust the specific time interval
that must pass before the web server is accessed again to get a "fresh" homepage. In any case, if a user clicks the
browser's Refresh button, the homepage is accessed from the web server again, overwriting the homepage cached on
the browser.
Caching the homepage is beneficial in either a production or development environment. We recommend that you turn
on homepage cache.
Note: Homepage Caching does not apply to Fluid Homepage. Fluid Homepages are actual components and adhere to
the same rules for loading of components.
The following table lists and describes the settings on the Web Profile Configuration – Caching page for homepage
caching:
Homepage Caching Settings
FIELD DESCRIPTION
Cache Homepage By default this setting is enabled.
Homepage Stale Interval The default value is 1200 and is measured in seconds.
Note: The Browsers section specifies which web browser that you can use with homepage caching. Verify that your
choice of browser is enabled for caching.
Managing Navigation Page Caching

As with homepages, navigation pages can be cached on each user's browser. Caching on each browser improves user
response time in traversing between cached menu pages. The Portal administrator can set system-wide options for
navigation cache by using the Define Personalizations page and modifying the value for METAXP.
Set the METAXP to a high value. Doing so will keep the menu pages inside the browser cache. If your menu pages are
not going to change frequently, set METAXP to 10080 (one week) or more. To set METAXP:
1. Go to PeopleTools > Personalization > Personalization Options.
2. Enter PPTL (PeopleTools) as the Option Category level value.
3. Select the Format tab and then select Set Option Default Value in the METAXP row.
4. Enter the appropriate value and click OK.
5. When brought back to the previous page, click save.

Note that a change to METAXP is picked up by the application server immediately; however, because the users’
browsers already have cache control set by the previous value of METAXP, you must delete browser cache for the new
METAXP to take effect.
Users can override the METAXP value on their individual browser sessions. After logging on, go to My Personalizations,
then click the Personalize Option button for General Options. Change the METAXP value by entering a new value for
Time page held in cache and then click the OK button.
Do not use navigation caching during development time because any newly added menus will not be reflected in the
cache. Use navigation cache only in production systems.
Maintaining Persistent Socket Connections

HTTP KeepAlive is intended to maintain a persistent socket connection between the web browser and the web server
so that no new connections are required when the HTML pages refer to other HTML objects.
However, keeping the socket connection persistent occupies a socket pair between the browser and web server. When
the KeepAlive timing is set too long, the following problems occur:
 The web server must manage many idle connections.
 Then number of new connections available is reduced.

We generally advise that those with PeopleTools 8.4x turn on KeepAlive. KeepAlive is the default for Oracle WebLogic,
and IBM WebSphere.
Reducing TCP Wait Times

This section provides an overview of TCP, TCP wait times, and describes how to manage TCP wait times on various
platforms.
Understanding TCP and TCP Wait Times

The default TCP Wait Time for Microsoft Windows and most UNIX operating systems is 4 minutes, which is too long for
PeopleSoft Pure Internet Architecture usage and tends to leave too many socket connections staying in the TIME_WAIT
state.
By shortening the TCP Wait Time, the socket can be recycled more efficiently.
Reducing TCP Wait Time (Microsoft Windows)

Use the registry editor, regedit, and create a REG_DWORD named TcpTimedWaitDelay under
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TcpIp\Parameters. Set the value to 60 secs (seconds).
Reducing TCP Wait Time (UNIX IBM AIX)

To see the current TCP_TIMEWAIT value, run the following command:
/usr/sbin/no –a | grep tcp_timewait

To set the TCP_TIMEWAIT values to 15 seconds, run the following command:
/usr/sbin/no –o tcp_timewait =1
The tcp_timewait option is used to configure how long connections are kept in the timewait state. It is given in 15-
second intervals, and the default is 1 (one). Use the default or change the value to 2 (two) for slower networks.
Note: Be careful when you use the no command, which performs no range checks and instead accepts all values for
the variables. If used incorrectly, the no command can cause your system to become inoperable.

The no command operates only on the currently running kernel. The command must be run again after each startup or
after the network has been configured.
Reducing TCP Wait Time (UNIX HP/UX-11)

As root user, execute the following command, where 60000 is for 60 secs, the minimum recommended value:
ndd -set /dev/tcp tcp_time_wait_interval 60000

You must put this command in one of the rc2.d scripts to get it to set automatically at boot time.
For HP/UX 11, you can place the ndd settings inside the /etc/rc.config.d/nddconf file without the need of the startup
scripts.
Reducing TCP Wait Time (Solaris Versions Prior to 2.8)

Use the parameter name tcp_close_wait_interval instead of tcp_time_wait_interval.
AIX Thread Model

IBM has recommended the following environment variables setup to improve the Threading model with PeopleSoft
Pure Internet Architecture.
Set up the following environment variables for the PeopleSoft Application Server user, database user, and web server
user:
For Korn Shell users, place the following lines in the .profile:
export AIXTHREAD_SCOPE=S
export AIXTHREAD_MNRATIO=1:1
export AIXTHREAD_COND_DEBUG=OFF
export AIXTHREAD_GUARDPAGES=4
export AIXTHREAD_MUTEX_DEBUG=OFF
export AIXTHREAD_RWLOCK_DEBUG=OFF
For C Shell users, place the following lines in the .cshrc file:
set AIXTHREAD_SCOPE = S
set AIXTHREAD_MNRATIO = 1:1
set AIXTHREAD_COND_DEBUG = OFF
set AIXTHREAD_GUARDPAGES = 4
set AIXTHREAD_MUTEX_DEBUG = OFF
set AIXTHREAD_RWLOCK_DEBUG = OFF
Managing Timeout Settings

This section provides an overview of timeout types and describes how to manage timeout values for major system
components. This section also describes a common problem scenario and the solution.
Understanding Timeout Types

There are in general three types of timeouts:

 Timeout during a PeopleSoft Pure Internet Architecture transaction (intratransactional): When the timeout
expires, the transaction fails and must be resubmitted.
 Timeout between PeopleSoft Pure Internet Architecture transactions (intertransactional): When the timeout
expires, the user has been idling for too long, and the resources associated with the user are freed. You must log
in again to re-establish the state.
 Timeout that "reserves" a resource until the expiration time before putting it back into the pool for recycling (for
example, tcp_timewait).
Values for intratransactional types of timeout should be staged. The end-to-end timeout value should always be
greater than that of its intermediate legs.
Understanding Timeout Values

This section describes timeout values for the major system components.
Application Server
For the application server (in psappsrv.cfg) the Service Timeout=x sec (default 300) Type=intratransaction, includes the
time it takes at the database server. According to the PeopleTools: System and Server Administration documentation:
Service Timeout. Specifies the number of seconds a PSAPPSRV waits for a service request, such as MgrGetObj or
PprLoad to complete, before timing out. Service Timeouts are recorded in the TUXLOG and APPSRV.LOG. In the event
of a timeout, PSSAPSRV terminates itself and Tuxedo automatically restarts this process.
In other words, it has to be large enough to accommodate the longest acceptable requests and queries. It is
recommended to set x=1200 (20 minutes).
PeopleSoft Pure Internet Architecture

The following table describes the timeout settings for the PeopleSoft Pure Internet Architecture. Set these parameters
in the peopletools.properties file:
Timeout Settings for the PeopleSoft Pure Internet Architecture
TIMEOUT SETTING PARAMETER DESCRIPTION
Send timeout tuxedo_send_timeout w sec (the default is 50)
Receive timeout tuxedo_receive_timeout x sec (the default is 600)
The receive timeout is also intratransactional, and it has to be bigger than application server service timeout.
The receive timeout indicates the maximum number of seconds that the servlet waits for a response from the
application server. If you increase your application server service timeouts, such as the Service Timeout setting for
PSAPPSRV, then increase the tuxedo_receive_timeout parameter to be greater than the Service Timeout values that
appear in the psappsrv.cfg configuration file on the application server.
Servlet Timeout
The servlet session timeout = x sec (default 1200) (in configuration.properties)
This is intertransactional, as one has to relogin when the servlet expires (technically this is a security setting).
The meta refresh tag is in seconds and should be less than or equal to the session.timeout for the servlet.
Jolt Timeout

The JOLT Client Cleanup Timeout = x min (in psappsrv.cfg)
This is intertransactional. See description (the default value is 60 prior to PeopleTools 8.51 and the default value is 10
beginning with PeopleTools 8.51. However, in most cases you can reduce the value to 10 to conserve resources):
The Client Cleanup Timeout specifies the amount of time, in minutes, that a client connection can remain idle (no work
requested) before Tuxedo terminates a client connection. Client disconnects are transparent to a client. To reconnect,
users must only click the mouse.
Web Server Session Timeout

The web server session timeout is given by this expression, located in <webserver home dir>/<PeopleSoft web
domain>/PORTAL/WEB-INF/web.xml:
<session-config><session-timeout>x</session-timeout></session-config>
This is intertransactional and specifies the number of minutes (Oracle WebLogic) to wait before invalidating an unused
session.
Note that setting this value too high ties up web server resources, especially when users close their browsers instead of
logging out. Setting it to be the same as (or a bit higher than) the JOLT cleanup timeout is generally a good idea.
HTTP Timeout
Apache: Timeout = x sec (in httpd.conf)
HTTP timeout, unfortunately, serves as both intertransactional and intratransactional in different scenarios, so it may
or may not be higher than the rest of the timeouts. This directive defines the amount of time Apache will wait on three
occasions:
 The total amount of time it takes to receive an HTTP GET request.
 The amount of time between receipt of TCP packets on a POST or PUT request.
 The amount of time between acknowledgements on transmissions of TCP packets in responses.
Troubleshooting PeopleSoft Pure Internet Architecture Timeout Errors

Problem:
Sometimes in PeopleSoft Pure Internet Architecture, time out error occurs on PeopleSoft pages even when people are
using the page.
Solution:
1. Increase the timeout values in servlet session timeout and web server session timeout.
In configuration.properties:
sessionTimeout = 3600 sec
In web.xml:
<session-config>
<session-timeout>60</session-timeout>
</session-config>
2. Increase values in configuration.properties in Apache Group > Apache\htdocs\PeopleSoft.

Set "meta-tag" session timeout to 3600 (which enables users to use the page for 60 minutes with no time out
errors).
3. Increase the values in pstools.properties if long queries are common:
Set tuxedo_receive_timeout to 1500.
Reviewing Internet Explorer Performance

In general, newer browser versions provide better user experience. For latest supported browsers, refer to the
document “PeopleTools 8.42 - 8.56 Browser Compatibility Guides,” My Oracle Support, Doc ID 704492.1.
Compared to all other supported browsers, performance issues have been observed on fluid pages when using Internet
Explorer 11. These performance issues mirror those reported by other non-PeopleSoft users to Microsoft. Complex fluid
pages such as those that include grids of over 300 rows, those that include multiple grids of differing types, as well as
other complex and compound page structures cause Internet Explorer 11 to perform continuous page re-layout
computations that other browsers do not perform. In particular, performance issues include but are not limited to:
 Initial rendering of the entire page is slow.
 Even after initial rendering, the page continues to be unresponsive and unavailable for some additional time.
 Interactions with individual page elements can be slow.

Starting with PeopleTools 8.55.19 and 8.56.04, Oracle has delivered fixes that mitigate some of the observed
performance problems with Internet Explorer 11. Some performance issues due to Internet Explorer 11 remain.
However, except for security issues, Microsoft does not intend to update Internet Explorer 11.

Working with Integration Broker Configuration Guidelines
This section describes performance guidelines for PeopleSoft Integration Broker and discusses how to:
 Configure the PSBRKHND message broker handler.
 Optimize message queues versus message consumption.
 Use message segments for Oracle-delivered full-synchronous service operations.
 Optimize one message versus multiple messages per queue.
 Tune PSADMIN parameters for asynchronous messaging.
 Tune PSADMIN parameters for synchronous messaging.
 Configure dedicated message servers for high-volume asynchronous messaging.
 Configure dedicated multiple domains for high-volume asynchronous messaging.
 Improve asynchronous messaging performance.
 Improve response times for synchronous messaging.
 Configure load-balance intervals. (PeopleTools 8.48 and later versions.)
 Implement primary/secondary load balancing.
 Reduce maximum asynchronous message size.
 Use multi-threading to send groups of messages in parallel. (PeopleTools 8.46 and later versions.)
 Troubleshoot pub/sub errors on application server start up.
Configuring the PSBRKHND Message Broker Handler

The primary purpose of this handler is to determine the appropriate routings based on the Tuxedo request received
and update the appropriate database tables (queues) accordingly. This handler also executes the OnRoute PeopleCode
events (OnRouteSend or OnRouteReceive) and Inbound Transformations.
Note that the processing time to determine the routings is much faster than actually processing a PeopleCode event.
The number of OnRoute and Transform events is typically low compared to the overall number of different messages.
If physical resources are a problem, you can reduce the number of this handler without impacting performance.
Optimizing Message Queues versus Message Consumption

There is a difference between the messaging system being able to receive a given number of messages per slice of
time and being able to process the message data (that is, a notification process) per slice of time. For example, if a non-
PeopleSoft system needs to send messages at a rate of x number per minute, the PeopleSoft messaging system can
receive and queue them at this rate. But if the notification process involves a lot of business logic or actions that take
up a lot of server resources, the application may not be able to consume the messages at the same rate that the
messages are queued by the messaging system (given a particular hardware configuration).
You should determine what the real requirement is for slice of time throughput. Is the requirement the ability to have
the messages queued at x number per minute (with the data from x messages being processed in more than that
minute), or does the message data from x messages absolutely have to be run through the business logic within that
minute slice of time? If the messages must be queued (that is, must you receive them as fast as other systems are
sending them), then you should explore additional configuration options for optimization. You might even look at
deferring message consumption (running the business logic) until certain times of the day or night when additional
system resources may be available. If the data from x messages absolutely has to be run through the business logic in

that one minute slice of time, then you may have to look at what is happening in the notification event and optimize
that.
Using Message Segments for Oracle-Delivered Full-Synchronous Service Operations

Messages (service operations) should be designed to take full advantage of as much queue partitioning as possible.
One area of concern is the Oracle-delivered full synchronous service operations. These particular service operations do
not take advantage of partitioning due to the way that they currently have to chunk the content data and process the
notifications. Integration Broker has come up with an alternative to this current chunking mechanism using message
segments.
Message segments provide a way to process and send large amounts of data (Gbytes) without impacting performance
due to PeopleCode processing, or running out of memory. Message segments enable a single message to load with all
the data segmented by any chunkable size desired. After one segment is populated based on a configuration parm, or
overridden by PeopleCode, that segment is serialized to XML and inserted into the IB database queue compressed. The
next segment is then available for processing. This type of loading continues until the message is completely loaded
with all the desired data. The message can be sent either as one message (ordered segments) or multiple messages
(unordered segments). The actual data is sent chunked by segments to the gateway and received by the target system.
These segments should be complete stand-alone data structures. The message object is responsible for this memory
management. The consumption of a segmented message in PeopleCode is straightforward. One segment at a time is
decompressed and serialized into a rowset. After the data is inserted into the database, the rowset is destroyed, freeing
up memory, and the next segment is then loaded. This process repeats for the number of segments in the message.
Refer to the product documentation for PeopleTools: PeopleSoft Integration Broker and PeopleTools: PeopleCode API
Reference for more information about Message PeopleCode APIs with respect to message segments.
Optimizing One Message versus Multiple Messages per Queue

Another design-time consideration when creating queues is whether to have one message per queue or many
messages in one queue. The answer to this question depends on many factors. For example, if there are 20 unrelated
messages in a queue, the dispatcher will try to process the 20 messages in the queue assuming these messages are
partitioned. If you create a queue for each message, there would be 20 queues. The dispatcher would have to traverse
all 20 queues to process those 20 messages, which would compromise performance due to more dispatch cycles and
database reads and writes.
Therefore, ideally you should put related messages in one queue and partition accordingly. For high volume
transaction messages, create a queue for each message, as these queues can then be part of a dedicated messaging
server.
Tuning PSADMIN Parameters for Asynchronous Messaging

Many configurable pub/sub parameters in PSADMIN have significant impact on performance of asynchronous-based
messaging. This section discusses each of these parameters in detail and their impact on performance.
General Parameters
This section describes general pub/sub parameters that impact asynchronous messaging.
Tuxedo Queue Size: The actual Tuxedo message queue size. For Microsoft Windows, the Tuxedo queue size is a
registry parameter. For UNIX systems, it is a kernel parameter. This value is used for Tuxedo queue threshold
determination by the pub/sub dispatchers. This value should be 1 MB or 2 MB instead of using the default of 64 KB.
Note that for AIX, the Tuxedo queue size is dynamic; therefore, you should use an arbitrary value. Otherwise, the
benefits of throttling are not realized.

As Tuxedo requests are queued, there is a point where the queue can get full and any additional requests are
disregarded. The dispatcher reads the number of queued requests and determines, based on this parameter, if any or
all requests should be sent out for this cycle. Therefore it’s important that this value accurately reflects the actual size.
Dispatcher Parameters
This section describes parameters for pub/sub dispatchers that impact asynchronous messaging.
Recycle Count: The dispatcher automatically recycles itself when this value is reached. By default, the recycle count is
set to 0 (zero). This count is based on the number of Tuxedo requests. In general, you should not have to cycle the
dispatcher. However, if a recycle count is used, it will affect performance because initialization will be performed which
includes rebuilding all the in-memory queues for each active queue assigned to that dispatcher.
Dispatch List Multiplier: This is a parameter used to throttle the number of requests sent to its associated handlers.
The actual list is the number of associated handlers multiplied by this value. The current default is set to 10. This value
was obtained by many performance tests. You should not have to change this value because it scales well.
Scan Interval: This is the interval that the dispatcher runs its on-idle processing. The current value is set to 15, which is
fine if Pub/Sub servers are running in the same domain as the PeopleSoft Pure Internet Architecture application
servers. However, if the Pub/Sub servers are stand-alone, this value should be set to 1, as this is the only mechanism to
initially poll the database queue for work.
Dispatcher Queue Max Queue Size: This value is the maximum number of items (messages) per queue that the
dispatcher retains in memory. The current default is set to 1000, which was obtained after many performance tests.
You should not have to change this value because it scales well.
Memory Queue Refresh Rate: This is the number of actual dispatches that the dispatcher will automatically rebuild in
its in-memory queue for a particular queue. The queues should not be corrupted; however, the current default value of
1000 is set at such a high level that it does not impact performance and is recommended based on performance tests.
You should not have to change this value because it scales well.
Restart Period: This is the time that the dispatcher attempts to re-dispatch messages that are still in the START status.
This value can potentially have a big impact on overall performance of the messaging system. When the dispatcher
dispatches a request, the system sets the status of the message to START. The Tuxedo request is queued, and the next
available handler will attempt to process this request and set the status to WORK. However, when the message system
is under configured (that is, there are not enough handlers to process all the requests), the request stays queued. The
dispatcher again sends the request after the restart period has elapsed. This potentially leads to many redundant
requests that the available handlers must cycle through. This leads to the Tuxedo queue overflowing and potentially
losing requests, requests that must be picked up when the restart period is reached. However, you do not want to set
this value too high, as messages would not be restarted in case of a handler crash. A good guideline is to use the
number of incoming requests per second divided by the number of associated handlers, multiplied by the average
processing time per second. Use this formula:
((Incoming requests per second)/ (# of associated handlers)) * (average processing time per
request)
Dispatcher Parameters – PSPUBDSP Only

This section describes pub/sub parameters for the PSPUBDSP dispatcher that impact asynchronous messaging
performance.
Ping Rate: This parameter—along with the scan interval—determines how often a node that is in the PSNODESDOWN
table should be pinged to see if it is in a valid state to send a request to. Part of the on-idle processing performs these
ping requests. When there are many nodes that are down due to improper configuration of routings on Service
Operations, many CPU cycles are spent performing these pings. This value allows for a longer time between
subsequent pings. Here is the algorithm used to determine the interval:

Attempts * Ping Rate * Scan Interval
Maximum Ping Interval: This value is the maximum time between subsequent pings for a node that is in the
PSNODESDOWN table. This value is in hours.
Handler Parameters
This section describes pub/sub handler parameters that impact asynchronous messaging performance.
Min Instances and Max Instances: These values should always be the same. If the Min Instance is not the same as the
Max Instance, then under load, the system has to wait for the process (the handler) to boot up and initialize before it
can be used. It is better to boot all at one time, avoiding allocations during max load.
Recycle Count: Because the handlers run IB Events that contain PeopleCode, memory leaks are likely. Therefore, you
should have a high recycle count and monitor it to determine if it grows to an undesirable size. The recycle count by
default is 20000; however, depending on the PeopleCode being run, you can set this value higher or lower. The
problem with a recycle count on a handler is that with proper load balancing from Tuxedo, all associated handlers
recycle at approximately the same time. If this becomes a problem, set the recycle count to 0 (zero) and create an
automated script that will stagger the recycling of the handlers by using Tuxedo command line arguments to specify
the specific handler.
Max Retries: This value represents the number of times that the handler will attempt to process a message before the
status is set to TIMEOUT. Therefore, if the PeopleCode being run causes a crash of the process, it will attempt to
process it again. This value should be set to a low value—5 or lower—to limit the amount of handler crashes for one
specific bad message.
Handler Parameters - PSPUBHND Only

This section describes pub/sub parameters for the PSPUBHND handler that impact asynchronous messaging
performance.
Thread Pool Size: This value represents the number of concurrent threads that the handler can spawn for HTTP
requests. Note that with performance benchmark testing in this area, with a thread count set to 5, one handler was able
to replace three non-threaded handlers. This is something to consider if memory resources are scarce.
Tuning PSADMIN Parameters for Synchronous Messaging

These are the configurable PSADMIN parameters for synchronous messaging that can affect performance. This section
discusses each of these parameters in detail and its impact on performance.
Min Message Size For Compression: Size of message content data that will cause Integration Broker to compress the
data prior to posting to the integration gateway. In general, synchronous messages should be as small as possible to
improve response time. Third parties should always use compression if possible.
Thread Pool Size: This value represents the number of concurrent threads that one PSAPPSRV process can spawn for
HTTP requests. The default is set to 5 based on performance benchmarks.
Configuring Dedicated Message Servers for High-Volume Asynchronous Messaging

It is best to run pub/sub (asynchronous) messaging activity on dedicated servers when processing a high message
volume. These domains should have application server processes (PSAPPSRV) configured in addition to pub/sub
servers. The advantage of having the application server processes on the pub/sub machine is that if the server has
only pub and sub services defined, it must poll the database queue to determine if there is work to be done. With the
(additional) application servers configured on the same machine as the pub and sub services, you get event-driven
notification of work to be done without the latency of polling. The gateway should “point” to this application server
domain for message processing. PeopleSoft Pure Internet Architecture should not be accessed on the dedicated
machine. To access PeopleSoft Pure Internet Architecture for configuring messaging, use the PeopleSoft Pure Internet
Architecture install on the other online application servers.

Dedicated messaging servers are assigned a certain number of queue names that result in its queue list. This list must
be unique across messaging servers pointing at the same database. The default messaging server defined by _dflt at
the end of each dispatcher process creates its own queue list based on all queues in the database, less the queues
defined for the same type dedicated server process. Therefore, to configure multiple dedicated servers on different
domains (to spread across different machines), ensure that the queue lists are indeed unique for the different
dispatcher types; otherwise, there will be database contention and the overall performance will be significantly
impacted.
In addition, add only the server type needed for the queue. This means that if you have long running notifications,
create only a subscription contract server. Moreover, remove all queues no longer in use, as these will consume
additional resources.
For information on how to configure dedicated servers, reference the product documentation for PeopleTools:
Integration Broker.
Configuring Dedicated Multiple Domains for High-Volume Asynchronous Messaging

Pub/sub domains for high-volume messaging should usually run on a machine other than one that used for online
users. Having pub/sub domains run on separate machines helps to prevent messaging traffic from being affected by
the number of online users, and vice versa. Separate pub/sub domains work only for asynchronous messaging.
Synchronous messaging runs as a service in the online application server. When running pub/sub on a dedicated box,
adjust the Scan Interval for each dispatcher in PSADMIN to 1 (one), as this will be the fastest initial poll rate from the
database queue.
Within a dedicated pub/sub machine, you can configure one or more domains. There are few scenarios in which
having multiple domains on one box will result in performance advantages. The reason is that each domain has a
publish dispatcher and a subscription dispatcher. The roll of the subscription dispatcher is to take messages from the
database queue and create Tuxedo calls to get them processed. The dispatcher is where the partitioning logic is
applied. The dispatcher looks at the queue, figures out how many messages can be processed next (based on
partitioning), and then puts them in the Tuxedo in-memory queue to be processed. The dispatcher locks the rows in
the database message queue until the Tuxedo calls come back with either success or failure. The dispatcher doesn’t
wait for the return of the first set of calls before moving on. It will continue to read the database queue and make the
Tuxedo calls even before the first set of calls have come back. The second dispatcher may not be able to read from the
database queue because the first dispatcher locks certain rows while processing. The second dispatcher can also add
complications in debugging. Adding another domain takes up systems resources. If you are going to consume
resources, then add handlers rather than a new domain. If you are trying to configure for failover, configure using
Integration Broker failover.
Working with Asynchronous Messaging

This section describes performance guidelines for asynchronous messaging, including:
 Message partitioning.
 Publishing PeopleCode.
 Notification PeopleCode.
 GetMessage method.
 Transform code. (PeopleCode and XSLT)
 Message compression.
 Full Synch Enterprise Integration Points (EIPs)
Message Partitioning

You should partition messages as much as possible. Third-party clients should post to PeopleSoft in parallel. To reduce
delays due to posting/queuing, use large messages (multi-transaction) for full synchronous processes, and use
compression.
Publishing PeopleCode
When publishing from PeopleCode, use the enqueue option as much as possible, or publish the message as late in the
transaction as possible. If you publish a message early in a transaction, and the transaction takes a long time to
complete, a lock will be maintained on the queue sequence ID table, blocking other messages in the same queue.
Notification PeopleCode
Notification PeopleCode should be as light as possible. For multi-transaction messages, commits should be frequent to
minimize contention. Component Interfaces (CIs) should not be used for full synchronous processes. They may be
used in incremental synchronous processes where volumes are not expected to be high. Note that CI performance is
dependent on the underlying component. If the component is light, it is possible to have a fast CI. The heavier the base
component, the slower the CI processing.
GetMessage Method
GetMessage is a relatively heavy call. You should use and reference the message that’s passed into the method
whenever possible in PeopleCode.
Transform Code (PeopleCode or XSLT)

Transform code (either PeopleCode or XSLT) should be as light as possible. In general, XSLT transforms will be much
faster than PeopleCode transforms.
Message Compression
Message compression is automatic for PeopleSoft-to-PeopleSoft transactions. For third-party applications, set the
HTTP target connector property “sendUncompressed” to N. Compression can reduce response time by 20 to 80-
percent based on message size. By adding a simple relay servlet, third-party messaging can take advantage of
compression.
Full Synch Enterprise Integration Points (EIPs)

Areas to review when using the Full Synch Enterprise Integration Points (EIPs):
Database Tuning: Create database statistics in a test environment from test runs and export them before production
runs. Full Sync EIPs are used for initial database creation. Empty databases do not have database statistics. If EIPs are
using temp tables, make sure the indexes are available for reads. After temp table population, create the database
statistics for these tables.
Archiving: Enable the archive option on the Queue page for queues designated for EIPs. This will cause the message
data to be archived into other Integration Broker PeopleTools tables. The Full Sync EIPs are one-time in nature and
hence do not need to be archived.
Database Layout: Plan database layout by splitting PeopleTools tables from application tables for better throughput.
Additional Tips:
 Enable archiving for Full Sync EIPs or any process where archiving is not required.
 Deactivate all message queues that are not being used.
 After Full Sync is run, the database administrator should update the database statistics for the new (grossly
changed) table sizes.

 Keep commits at the transaction level and not at the message level. This will reduce locking and improve
performance.
Improving Response Times for Synchronous Messaging

This section describes guidelines for improving response times for synchronous messaging.
Response time tends to be important in synchronous requests, so transforms and OnRequest PeopleCode should be
light.
Use CIs only if the base components are light and have quick response times.
Keep the number of sync requests from a client to a minimum or use synchronous threading. For example, if you have
a certain amount of work to be done on a remote system, pack as much of the work into as few of calls as possible.
Minimizing calls reduces the amount of PeopleCode message overhead to instantiate request and response messages.
In general, synchronous messages should be small to improve response time. Third-party clients should use
compression, if possible. (Compression is used by default for PeopleSoft-to-PeopleSoft synchronous messaging.)
Partitioning is not an issue with sync messaging. Sync messaging should typically be used for remote queries, not for
remote inserts, updates, or deletes. If synchronous messaging is used for insert, updates, or deletes, SyncRequests do
not share a transaction context with the requesting system. If a SyncRequest has been completed, and the client
transaction rolls back, the SyncRequest will not be rolled back. (Publishes will be rolled back).
Also, a component should not depend on the successful completion of a SyncRequest. If the remote system is down,
the SyncRequest will fail. The requesting application should be prepared to deal with this by using exception logic, or
should use the asynchronous system. If the remote system is down, the asynchronous system will retry. If you need to
send data to multiple systems at the same time, use threaded sync requests or possibly asynchronous messaging. The
asynchronous system is much more efficient at fanning out information to multiple target systems.
Configuring Load Balance Intervals (PeopleTools 8.48 and Later)

During on-idle processing, the Integration Broker dispatcher will ping nodes that are down (Publication Dispatcher
only) and also synchronize its in-memory queue with the database queue table. If the dispatcher is constantly busy, the
on-idle processing may not be run for extended periods of time, resulting in failed messages not getting retried or new
messages not being processed.
In PeopleTools 8.48 and later, there is a new configuration parameter in psappsrv.cfg, called Load Balance Interval.
Setting this parameter (measured in minutes) forces the dispatcher to perform on-idle processing at fixed intervals,
which could help avoid queues not being processed due to the previously mentioned reasons.
Implementing Primary/Secondary Load Balancing

When setting up a primary/secondary (“master/slave”) configuration using machines with different CPU processing
power, use the more powerful machine as the master. If you use the slower machine as primary, that machine may not
keep up with the secondary machine. As a result, the secondary machine would sit idle and throughput would not be
maximized.
Reducing Maximum Asynchronous Message Size

Some operations may benefit from smaller message size. For example, when running the FULLSYNC message from an
HCM instance to set up Enterprise Portal Resource Finder, reducing the maximum message size from the default of 10
MB to 25 kb enables the process to run significantly faster. To reduce the maximum message size, go to PeopleTools,
Utilities, Administration Options, PeopleTools Options and change the Maximum App Message Size field. We suggest
manually setting the value back to the default after the FULLSYNC messages are complete because this setting affects
all message types.
Using Multi-Threading to Send Groups of Messages in Parallel (PeopleTools 8.46 and Later)

This section describes how use multi-threading to send groups of messages in parallel.
Understanding Multi-Threading Messages

Multi-threading allows you to send a group of synchronous requests in parallel, thereby eliminating the need to wait
for a response for one synchronous message to be returned before you send the next synchronous message. You can
also use multi-threading to send a configurable number of asynchronous message publications in parallel.
PeopleTools 8.46 provides a multithreaded version of IntBroker.SyncRequest() and enables users to configure the
number of message handling threads. In general, setting the thread count equal to the number of psappsrv.exe
processes in the target domain for the messages can improve message handling response times by as much as 80
percent over a single threaded implementation.
Note: Make sure that you apply PeopleTools 8.46.12 or later and PeopleTools 8.47.06 or later if you are not on
PeopleTools 8.48. These patches fix an important thread leak issue associated with using this feature.
Using Multi-Threading for Asynchronous Messaging

As with synchronous messaging, we recommend setting the number of threads for the PSPUBHND handler equal to
the number of PSAPPSRV processes in the target domain.
Note: If needed, you can distribute PSPUBHND through a primary/secondary configuration if the number of threads
is limited by the source domain hardware.
Troubleshooting Pub/Sub Errors on Application Server Start Up

Problem:
These PSSUBDSP_dflt errors were occurring upon starting the application server. There were hundreds of entries like
this. While these errors occurred, no access to the PeopleSoft system was possible in three-tier mode. Two-tier mode
invoked no errors.
PSSUBDSP_dflt.1784 [10/24/00 13:46:22](1) (NET.333): The service PSSUBHND_dflt could not be sent
because of a blocking condition within Tuxedo on the client.
Second Error:
>PSSUBHND_dflt.2253 [10/24/00 13:46:25 SubConProcess](1) (NET.346): Failed to execute

SubConProcess request
PSSUBHND_dflt.2253 [10/24/00 13:46:25](2) Service SubConProcess failed
Resolution:

This problem was appearing when the nightly backup inadvertently shut down the database while the application
server was running. When we tested shutting down everything in the correct order, the problem disappeared. The
PSSUBHND instances were too busy erring out to handle even one subscription.
As long as you follow the correct shutdown procedures, you can avoid this problem. If, however, this problem does
occur, shut down the web server, application server, and Process Scheduler (not the database) and restart them in the
correct order.
Managing Operating System Settings

For a large environment with many domains, refer to the document “Application Server and Web Server Kernel
Parameters for UNIX and Linux Operating Systems,” My Oracle Support, Doc ID 608218.1.

Managing Call Telephony Integration (CTI)
This section describes recommendations for configuring Call Telephone Integration (CTI) based on our recent
customer experiences.
Create a separate application server domain dedicated to the REN server. Note the following:
 This domain should run two application servers.
 The application servers in this domain should not be accessible to the web server.
 There is not a need to run MCF servers or most other servers in this domain.
 You will need to configure your MCF servers to use the new REN server cluster.
In the psrenconfig.txt file, please ensure the following settings have been made:
PSRENCONFIG FILE SETTINGS
PROPERTY VALUE COMMENTS
tcp_nodelay 1 Set this property in the nssock and nsopenssl sections of the file
listenbacklog 512 NA
maxthreads 512 NA
minthreads 256 NA
reaper_interval 90 NA
default_kn_expires 600 or higher NA

Using PSAE and PSAESRV
The benefits of PSAESRV versus PSAE are a popular topic of discussion. Our studies have shown that PSAE is as good
as PSAESRV for most practical purposes.
If you have an application engine job that runs longer than 10 seconds, PSAE is equivalent to PSAESRV. PSAE has the
added advantage of being recycled at the end of each application engine job, cleaning up any outstanding SQL cursors
to the database that may have been left behind. Because PSAE recycles after each use, PSAE does not have any
possible memory leakage problem that may occupy the precious system memory. In short, PSAE is a cleaner
workhorse.
For instructions on how to enable PSAESRV, refer to the document “AE: How to Enable or Disable PSAESRV Process
Type in a Process Scheduler Domain,” My Oracle Support, Doc ID 659343.1.

Managing Reporting Tools
This section describes performance guidelines for:
 BI Publisher (PeopleTools 8.48 and later versions.)
 Business Objects Enterprise (PeopleTools 8.48 and later versions.)
BI Publisher (PeopleTools 8.48 and Later)

Consider the following guidelines when using BI Publisher:
 Increase JVM heap size to 512MB.
More memory may be needed for very large reports. Customers should test and find optimal heap size for their
functional usages. See the Setting Application Server JVM Options section of this document for information on
updating the JVM heap size.
 Use PDF format for reports where the PDF template will suffice.
For more complex reports that require the RTF template, take greater care when designing the RTF template and
data source.
 Use SQR or other mechanisms to generate the XML file as a preprocessing step, as the XML file is the most
optimal data source for a BIP report.
While PSQuery and Connected Query are supported data sources, they will, in effect, be converted to XML during
report processing. Using SQR or other mechanisms is one optimization technique.
Business Objects Enterprise (PeopleTools 8.48 and Later)

For customers who have a large reporting load, and have converted the report format to SAP Business Object
Enterprise 11 (BOE) to avoid the reporting load affecting other online users, we recommend that you configure a
dedicated application server domain and install the BOE server on a separate machine.
BOE will request data via the integration gateway and Query Access Services (QAS). QAS will make requests to
PSANALYTICSRV to retrieve the actual data. You should set the Max Instance Count of PSANALYTICSRV to a value
equal to or greater than the maximum number of concurrent reports that you must run. By default, PSANALYTICSRV
recycles after each request. If you are running many small reports that take less than 1 minute to finish, it may be
beneficial to set recycle count to a greater value to minimize the cost of restarting PSANALYTICSRV. However, if you
are running large reports, the memory footprint of the PSANALYTICSRV may be high, and it is better to set the recycle
count to 0 (zero). In addition, if there is a burst of report requests, the PSANALYTICSRV processes spawned to handle
the request will continue to consume memory if you set recycle count to greater than 0 (eventually the idle processes
will shut down).
Depending on the size of the document, when generating BOE reports, many physical files are created in various
layers: BOE temporary files, QAS repository files, and Report Repository files. For better performance, configure these
locations such that the physical files are created on fast disks that are optimized for faster read and write.
While submitting BOE reports through your PeopleSoft application, set the Minutes Before an Idle Connection is
Closed setting to a lesser value (1 minute) to free up resources from inactive users more quickly. You can change this
setting from the BOE Management Console.

Managing Monitoring Tools
 PeopleSoft Ping.
 PSADMIN.
 PeopleSoft Performance Monitor.
PeopleSoft Ping
PeopleSoft Ping is a convenient monitoring facility using PeopleSoft Pure Internet Architecture, and it shows the time
spent in different tiers of the PeopleSoft system. Select PeopleTools > Utilities > PeopleSoft Ping.
See the PeopleTools: System and Server Administration documentation for more details.
PSADMIN
You can use PSADMIN to monitor Oracle Tuxedo queueing. You can use this information to determine the optimal
number of PSAPPSRV processes.
See the Application Server Guidelines section of this document for more details.
PeopleSoft Performance Monitor

You can capture detailed performance information for individual requests using PeopleSoft Performance Monitor
(PPM). PPM provides a breakdown of the response time for the request and enables you to see time consumed by
individual SQL statements or PeopleCode executions.
For more information on PPM, refer to the document "PeopleSoft Performance Monitor," My Oracle Support, Doc ID
747510.1.
See the product documentation PeopleTools: Performance Monitor.
Starting with PeopleTools 8.55, the PeopleSoft Health Center enables you to monitor the health of your PeopleSoft
application by providing real-time analysis of performance and load. See the product documentation PeopleTools:
Performance Monitor, “Working with PeopleSoft Health Center.”

Online User Experience Enhancements
 Auto-complete (type ahead).
 Look and feel.
 Partial page refresh (AJAX updates).
 Full AJAX support for the PeopleSoft Pure Internet Architecture.
 Modal windows.
 Mouse-over pages.
 Deferred mode versus inactive mode.
Understanding Online User Experience Enhancements

With each new release of PeopleTools, additional improvements are made to improve online user experience and
performance. The information in this section is intended to explain how some of the user interface enhancements
actually work to give you a better understanding of how they might affect your environment.
Auto-Complete (Type Ahead)

Auto-complete vastly improves the user experience. It is enabled for all prompt fields. It allows the user to perform
partial searches on prompt fields without having to navigate to the prompt page. In one step, the user can enter
search data, wait for the list to populate, and then choose from the list of retrieved values. This reduces the amount
of typing and clicks that the user has to perform to find the desired value. This feature can be disabled via a user
personalization change. The amount of time that the browser waits before requesting a list of values is 0.5 seconds.
This value cannot be changed.
Look and Feel

Beginning with 8.50, new style sheets, look and feel improvements, and enhanced user experience improvements
that leveraged cascading style sheets (CSS) and JavaScript increased the amount of CSS and JavaScript that is loaded
on the browser. These will typically require more requests to the web server when compared to 8.49, however once
the objects are cached on the browser, these objects are not downloaded unless the objects have been updated, such
as in a patch update or new PeopleTools release.
Partial Page Refresh (AJAX Updates)

To achieve AJAX updates for a page required a new infrastructure on the browser to handle the responses as well as
additional JavaScript processing. JavaScript manipulation and XML processing can slightly increase the amount of
time required by the browser to load the page. This is due to the browser HTML engine applying the new updates to
the HTML page. AJAX has been shown to reduce the number of bytes transferred to the browser in some situations
when partial page updates occur. This reduces your network utilization.
Full AJAX Support for the PeopleSoft Pure Internet Architecture

AJAX enabled actions make the transition much smoother and quicker. Starting in PeopleTools 8.52, AJAX has now
been enabled for all aspects of a PeopleSoft page, component and pagelet. Page generation has been restructured to
take advantage of Partial Page Refresh in the following areas:
 From Search to bringing up the component
 From page to page via Tab or TransferPanel PeopleCode

 From Component to DoModal or DoModalComponent
 All actions from the Tool Bar, including Next in List, Rev in List, Return to Search, Update, Correction, and
Notification.
 All actions performed during grid customization, including copy, share, delete, and customize.
Modal Windows
Modal Windows are used for a number of tasks including:
 Messages.
 Prompt look ups.
 Secondary pages.
To achieve the look and feel of a floating modal window required the use of an HTML tag called an iFrame.
 An iFrame is a separate window within the main browser window or HTML page.
 This enables the ability to display two HTML pages within the same browser window.
 This iFrame can be resized and moved around within the browser window.
For each page with a Modal, the browser makes an additional request to the application server.
 The additional request happens at page load time for the iFrame
 This iFrame infrastructure is reused for all the Modal lookups on the same page.
We have attempted to minimize the effect of this additional request from a performance perspective; however, it may
be questioned during load testing.
 You will see your HTTP requests increase to support this feature and as a result more Jolt requests and some
increase in web server CPU time.
 These additional requests may increase the web server and application server CPU time accordingly.
 The impact of this enhancement is dependent upon the actual test that is performed during load testing.
Mouse-Over Pages
This feature has been used across the PeopleSoft 9.1 applications to aid in providing additional data to the user on
specific fields. This page generally contains additional data pertaining to Vendor ID, Employee Info, Department ID,
and so on. It provides contextual data in an easy-to-access window on a transaction page without the need to
navigate to another page. It also supplies additional data to the end user while reducing the number of clicks required
to navigate within the application. These pages are loaded in the same application server request as the main page,
so the load time will be a combination of the main page as well as the mouse over page.
Deferred Mode versus Interactive Mode

AJAX and the other features discussed here are considered usability features and are not performance
improvements. It is not recommended to change pages from deferred to interactive mode without considering the
impact to performance as this will increase the load on your system.

Query Access Service (QAS)
This section provides an overview of the Query Access Service (QAS) technology and describes how to:
 Execute QAS synchronous queries.
 Execute QAS asynchronous queries.
 Execute QAS sync/poll queries.

This section also describes performance considerations and configuration recommendations for the technology.
Understanding Query Access Service (QAS)

QAS (Query Access Services) allows application developers to create web service-based applications that can retrieve
data from PeopleSoft applications. QAS provides several web service operations.
QAS utilizes the PeopleSoft Integration Broker framework to satisfy requests.
When designing an application that will invoke QAS service operations, it is important to consider performance. In
particular, there are three modes of query execution that impact performance:
 Synchronous query execution.
 Asynchronous query execution.
 Sync/poll query execution.
Executing QAS Synchronous Queries

When a synchronous query execution request is issued, the calling application process must wait for a reply. The full
result of the query will be included in the reply. The amount of time that it takes to reply to the request depends on
several factors, including but not limited to:
 Network performance.
 Application server performance.
 Database server performance.
 Query complexity.
 Amount of data in the result set.

The amount of data in the result set is determined by two factors:
 Number of rows of data.
 Number of columns in each row.

In general, if you expect most queries to be simple in nature and result sets on the small size (for example, hundreds of
rows, not thousands of rows), then synchronous query execution may be an appropriate query execution mode.
If you expect query complexity to be high and/or you expect that large result sets will be commonplace, or if response
time is critical, then you may want to consider other modes of query execution.
Executing QAS Asynchronous Queries

When an asynchronous query execution request is issued, the calling application process does not have to wait for the
result set to be returned. When the result set is created, QAS will post to the calling application the result set. The
calling application, of course, must be designed to be able to accept that post and process it accordingly.

The query result set resulting from an asynchronous query execution request is posted to the requesting application in
one result post. For a large result set this means that the message posted to the calling application can become quite
large. Thus, it is recommended that asynchronous query execution be used only when you expect query result sets to
be small. Large result sets will take more time to convey in the network and take more time to process.
Executing QAS Sync/Poll Queries

When a sync/poll query execution request is issued, the return to the request includes a unique transaction id. Control
returns very quickly to the calling process. At this point the calling application does not have any query results. It will
have to issue additional web service calls to get the query results. After QAS receives the request it queues the request
internally in the Integration Broker Pub/Sub system. The query will be run, and the query result set will be stored
internally. When the calling program requests query results using the Get Query Results web service operation and
passing the unique transaction id, query results will be returned in blocks, one block returned for each Get Query
Results request. One query may result in one or more result blocks being passed. The maximum size of the result
block can be configured.
This mode of execution is best suited for returning large or small numbers of rows of data. It is the mode typically used
by reporting applications accessing PeopleSoft data via QAS.
QAS Performance Considerations

Choosing the execution model to run depends on the number of rows and columns returned in the response.
Keep the following guidelines in mind:
 Synchronous execution is not recommended for large result sets.
 Response data that consists of a large number of columns with fewer rows of data has a slower response than
response data that consists of fewer columns and more rows, even though the response size may be smaller.
 Requesting that a query be executed in synch/poll mode with block size = 0 or Max will result in all data in one
block. This is probably not what you want to do.
 In sync/poll execution, the larger the response block, the fewer blocks are returned and total response time for all
blocks is less, but the user has to wait longer for the response.
 In synch/poll execution, if the heap size in the web server is not sufficient to retrieve the large response block, it
will lead to a Java out of memory exception.
 In synch/poll execution, if a smaller block size (less than 100,000) is used, this will result in too many blocks
containing very few rows. Optimal request block size in kilobytes (KB) is in the range from 100,000 to 1,000,000.
Configuration Recommendations
Recommended configuration options include:
 Minimum Web Server Heap Size: Min and Max=512 MB
 Client Heap Size: Min and Max=1024 MB.
 Sync/Poll: Optimal Request Block Size in KB in the range from 100000 to 1000000.
 Sync/Poll: PSBRKHND instance count needs to be increased as response block count increases.
 Client SocketTimeout=600000 ms or Max limit approved for the query response time.

Feature Specific Recommendations for PeopleSoft Infrastructure
This section includes recommendations for:
 Pivot Grid
 Classic Homepage and Dashboard
 Fluid Homepage
 Secure Enterprise Search (SES)
 Kibana
 Related Action Menu
 Push Notification
 Tile Event Refresh Considerations
 File Attachment
Pivot Grid
The Pivot Grid enhancement is available in PeopleTools 8.52 and later releases. PeopleSoft Pivot Grid enables users to
display data visually in a dashboard. You can display data in different views by performing operations such as pivoting
and filtering, which enables business analysts to interpret data in a variety of ways.
The performance of Pivot Grid is directly related to the performance of its data source. The data source can either be a
PS Query or a Composite Query. If the data source has poor performance, the same is reflected in the performance of
the Pivot Grid as well. Hence, the queries should be tuned properly for a good and acceptable Pivot Grid performance.
Additionally, Pivot Grid displays aggregated data. It manipulates the data source at run time to render data for different
visualizations. So, the Pivot Grid queries should be conducive for such manipulations as well. Pivot Grid fires two or
three queries per transaction. The first query is to get the unique values for all the dimensions and the second one is
for the actual data to be displayed on the grid or chart. In the case of Fluid Pivot Grid, an additional query may be
executed to display the Detailed View.
We suggest the following general guidelines:
 Limit the number of joins in PS Query.
 Tune the Pivot Grid queries for optimal performance.
 Use the “Chart Only” option.
If a Pivot Grid is designed to show both grid and chart, and is published as a tile on a homepage page, you can
create a Pivot Grid View with the "Chart Only" option to replace the original Pivot Grid View used in the tile. The
"Chart Only" Pivot Grid View tile will perform better on the homepage, because the business logic to fetch the grid
content is eliminated. When the user selects the Pivot Grid tile, the additional grid content will be fetched and the
Pivot Grid will display both grid and chart.
 Use columns with limited distinct values as filters.
A filter column with too many distinct values will take longer to process and render in the filter panel on the Pivot
Grid detail page.
 Adjust Oracle database parameters.
If using an Oracle database, adjust these database parameters according to your hardware for better Pivot Grid
performance. Here are the minimum recommended values:

_pga_max_size =3 GB
pga_aggregate_target =10 GB
 Use Materialized Views on Oracle, Index Views on Microsoft SQL Server (MSS) and Materialized Query Tables on
DB2.
PeopleSoft systems support Materialized Views on Oracle, Index Views on Microsoft SQL Server (MSS) and
Materialized Query Tables on DB2. In case of complex queries having multiple tables and joins, these features can
also be used for better performance. See application product specific recommendations on materialized view
usage.
Classic Homepage and Dashboard

Homepages in the classic user interface are PeopleSoft pages that aggregate and display pagelets that share some
common or similar purpose. Homepages provide quick access to useful information by presenting concise but feature-
rich pagelets to the user. These pagelets can vary in function and complexity, enabling you to see not only an overview,
but to drill into your data to access more granular and detailed information. Pagelets can enable you to perform routine
tasks or provide you with a high-level overview of aspects of your company that are pertinent to you. In addition,
pagelets can interact with each other by publishing and subscribing to messages in a process called interwindow
communication that refreshes pagelet content based on any passed values.
Homepages are accessed when the user signs in, and also when the user clicks on the Home button in the Toolbar.
All pagelets on the default homepage are loaded when the user accesses the homepage. Pagelets on secondary
homepages are not loaded until the user explicitly accesses the secondary homepage. The processing resources
required to load the default homepage can increase depending on the content in those pagelets. If the pagelets on the
homepage require a large amount of processing, then the resources necessary to handle the work will increase also.
When there are a large number of users accessing the homepage, then system-wide resource requirements will also
increase to handle concurrent processing.
Note: Customers should monitor and run performance tests on homepages, and allocate sufficient resources to
ensure adequate responses during peak load.
Here are some items that can help improve overall homepage response time:
 Tune each pagelet to handle concurrent users. Even one single slow pagelet can impact all users.
 Enable parallel pagelet loading.
See the section Reducing Homepage Loading Time Using Parallel Pagelet Loading in this document.
 Ensure adequate application server recycling to reclaim memory.
See the section Working With Application Server Guidelines in this document for more details.
 Monitor system resource usages to ensure adequate hardware is allocated to handle the peak load.
 Reduce the number of pagelets on the homepages to only the functionally necessary pagelets that are frequently
accessed.
Remember all pagelets on the default homepage will be loaded whenever the user navigates to the Home button
(including after signing in or clicking the Home button in the Toolbar).
 Move less frequently viewed pagelets to Dashboards that are not loaded automatically at sign in, but only loaded
upon specific user request.

See the product documentation PeopleTools: Portal Technology, "Understanding Homepages and Dashboards."
Fluid Homepage
A fluid homepage is a PeopleSoft page that aggregates related information and displays tiles that provide access to
fluid applications. Tiles can be compared to pagelets used in the portal technology. For more information on fluid
homepages, see the product documentation PeopleTools: Fluid User Interface Developer’s Guide.
Fluid homepages are accessed when the user signs in using fluid mode, and also when the user clicks on the Home
button in the Toolbar when in fluid mode. Navigational tiles are lightweight and should not impact performance
substantially.
In PeopleTools 8.54, when the user accesses the fluid homepage, all tiles on all fluid homepages will be loaded. Thus,
resources will be used to process all tiles including those on secondary homepages.
Note: In PeopleTools 8.54, accessing the fluid homepage will load all tiles on all fluid homepages. Customers should
monitor and run performance tests on the fluid homepage, and allocate sufficient resources to ensure adequate
responses during peak load.
PeopleTools 8.55 improved performance dramatically by loading only tiles on the visible homepage. Invisible tiles are
no longer loaded by default, with the exception of tiles with “Refresh Timer” greater than 0 in the Fluid Attributes. Tiles
with “Refresh Timer” greater than 0 (zero) will be loaded whenever the fluid homepage is accessed and will be
refreshed according to the timer setting.
Here are some tasks that can help improve overall homepage response time:
 Tune each tile to handle concurrent users.
 Reduce the number of tiles on the homepages to only the functionally necessary tiles that are frequently
accessed.
Remember all tiles on the visible homepage will be loaded whenever the user navigates to Home (including after
signing in or clicking the Home button in the Toolbar).
 Move less frequently viewed tiles to secondary homepages so they are loaded only when the user explicitly
selects the secondary homepage.
 Limit the use of “Refresh Timer” as the tiles with timer greater than 0 will be loaded and refreshed regardless of
whether the data has changed.
 Limit the use of an Event to refresh a tile. Do not use events to refresh a tile if the event can be triggered
frequently by many users.
See the section Tile Event Refresh Considerations in this document for more details.
 Ensure adequate application server recycling to reclaim memory.
See the section Working With Application Server Guidelines in this document for more details.
 Monitor system resource usages to ensure adequate hardware is allocated to handle the peak load.
Secure Enterprise Search (SES) (PeopleTools 8.55 and Prior)

The PeopleSoft Search Framework provides a standard, declarative method for creating, deploying, and maintaining
search indexes for all of your PeopleSoft applications. Oracle Secure Enterprise Search (SES) is the search engine on
which the PeopleSoft Search Framework relies.
While SES provides a set of rich features, it will require additional hardware resources to implement. In addition to the
hardware necessary for the SES installation, SES will introduce an additional load on the application server domain due

to SES call backs through the integration gateway, search response processing, and related action processing in global
search. SES also uses the Process Scheduler for indexing documents. Customers should run performance tests to find
the appropriate number of PSAPPSRV and PSAESRV processes to handle their expected production workload.
Review the following for more details on SES implementation considerations:
 PeopleTools: Search Technology
 PeopleTools installation guide for your database platform, "Configuring Integration Between PeopleSoft
PeopleTools and Oracle SES"
 "Oracle Secure Enterprise Search Deployment Considerations for PeopleSoft 9.2," My Oracle Support, Doc ID
1684035.1.
 "How To Implement High Availability For Oracle SES 11.2.2.2," My Oracle Support, Doc ID 1611280.1.
Note: Beginning with PeopleSoft PeopleTools 8.55.11, a new search engine, Elasticsearch, can be used. Refer to the
PeopleTools: Search Technology product documentation for your installed PeopleTools release.
Elasticsearch
Elasticsearch 7.10 is supported for PeopleSoft Search Framework beginning with PeopleTools 8.59.
Compared with Elasticsearch 7.0, which was supported for the previous PeopleTools release:
 Elasticsearch 7.10 has better data compression and reduced storage size.
 Search performance is approximately the same as with Elasticsearch 7.0.
 Depending on the data, crawl time and CPU usage may be higher for some indexes.
For information on using Elasticsearch with PeopleSoft Search Framework, see the product documentation
PeopleTools: Search Technology.
To install the Elasticsearch, Logstash, and Kibana DPK, see PeopleSoft Deployment Packages for Elasticsearch
Installation (PeopleSoft PeopleTools 8.59) on the Oracle Help Center.
Kibana
The use of Kibana visualizations for PeopleSoft applications analytics is supported beginning with PeopleTools 8.58.
Moving analytics to the Kibana server frees the PeopleSoft Online Transaction environment to do other tasks. To
learn about PeopleSoft Search Framework and Kibana Analytics, see “Elasticsearch Home Page,” My Oracle Support,
Doc ID 2205540.2.
Setting Logging Levels

In production environment, set all the Elasticsearch logger levels to “info”. In log4j2.properties, ensure
“logger.action.level = info”, and “rootLogger.level = info”. For more information on logger setting, refer to
Elasticsearch documentation for your installed version.
Setting the Request Timeout Setting

Set the Kibana request timeout to 60 seconds. In the configuration file kibana.yml, change to
“elasticsearch.requestTimeout: 60000”. If the Kibana dashboard contains complex analytics, the value in the yml file
can be increased further to avoid timeout issues.
Using Failover and Load Balancing

To support failover and provide load balance, we recommend that customers have a minimum of three Elasticsearch
nodes. For more details, refer to the document “High Availability in Elasticsearch and Kibana Using Load Balancer,”
My Oracle Support, Doc ID 2704089.1.
Using Elasticsearch Nodes

The Elasticsearch node uses all available CPU resources to process the visualizations in a Kibana dashboard
concurrently. You may notice heavy CPU usage on Elasticsearch nodes and longer response times with a large
number of concurrent Kibana visualization users.
Use horizontal scaling of Elasticsearch nodes to support large concurrent users with heavy Kibana analytic
visualizations. The Kibana server manages the distribution of shards across the Elasticsearch nodes to handle the
concurrent analytic processing workload. Monitor your Elasticsearch usage and add Elasticsearch nodes as required
for your custom usage patterns.
Add Elasticsearch nodes in the same subnet to reduce network latency.
Adjusting Memory
Monitor memory swapping in the Elasticsearch nodes. If you observe excessive memory swapping, utilize the normal
memory management options for your operating system to reduce swapping.
Elasticsearch also comes with an option to lock memory. To enable a memory lock, set “bootstrap.memory_lock: true”
in elasticsearch.yml and restart Elasticsearch. The bootstrap.memory_lock setting tries to lock the process address
space into RAM, preventing any Elasticsearch heap memory from being swapped out. For more details, refer to the
Elasticsearch documentation for your Elasticsearch version.
For more details on the concepts mentioned here, see the Elastic web site, www.elastic.co.
For large data volume indexes and high concurrent transaction loads, monitor JVM heap. If necessary, the Young
Generation heap can be increased up to 30% for better response times and more optimized garbage collection (GCs)
based on your custom usage patterns. The implicit default is 10% of heap. To change the Young Generation heap size,
add the flag "--XX:NewRatio=<value> " to the jvm.options configuration file for Elasticsearch.
For example: “--XX:NewRatio=2” will set the Old Generation to twice the Young Generation (Old Generation = 2 x
Young Generation), giving Young Generation 3 GB out of 10 GB JVM heap.
Be sure to monitor the statistics for your system to find the best setting for your custom usage. The actual value that
you use will depend on factors such as the visualizations you choose.
For more details, refer to the Java documentation for your installed Java version.
Caching
When a user accesses Kibana, the user credentials are cached to improve performance. Kibana related tile loading js
and css requests are cached in the browser to improve performance.
Using Kibana Tile Visualizations

For better scalability and user experience, we suggest the following guidelines for Kibana tile visualizations in
PeopleSoft applications.
 Limit the number of Kibana tiles on the primary PeopleSoft Homepage.
The user’s primary Homepage is processed every time the user navigates to “Home”. By moving Kibana tiles to a
secondary Homepage, the Kibana processing will not be triggered every time the user navigates to Home. Kibana

processing on a non-primary Homepage will execute only when the user explicitly chooses to go to the secondary
page containing Kibana tiles.
See PeopleTools: Portal Technology for information on homepages and tiles.
 For Kibana tiles pulling from a large data volume index, use a filter to reduce the data selected.
 Use a saved search rather than data table visualization for improved performance.
See information on visualizations in the Kibana documentation for your Kibana release.
 Avoid computed scripted field columns in data table visualization as it involves expensive sorting.
See the information on scripted fields in the Kibana documentation for your Kibana release.
See Kibana Guide, https://www.elastic.co/guide/en/kibana/index.html.
Related Action Menu

PeopleSoft applications use Related Action Menus on many pages in the application such as Company Directory page
and Direct Line Reports pagelet. The related action menu consists of multiple transactional links. When a user clicks to
access the menu, each link in the menu is validated for security before presenting to the user. The security validation in
case of links that are local to the system is done via a PeopleCode call, and add processing cost to the local app server.
The validation of remote application links is done using Integration Broker sync requests. Integration broker sync
requests use IB and therefore add processing/wait time on the local app server.
Customers must evaluate the usage of application pages that have related actions and factor the usage of related
actions in the stress/load testing to figure out the app server domain configuration requirements.
 Create a separate domain that is referenced by the PeopleSoft Integration Broker gateway and plan for the
number of PSAPPSRV processes in the domain.
 When sizing the PeopleSoft system be sure to set the JVM min and max memory settings for each instance of
PSAPPSRV.
 Because SES search uses PeopleSoft Integration Broker, and Integration Broker internally needs Java, each
PSAPPSRV process involved in search will load JVM and JVM reserve memory as defined in the domain
configuration files. Though this was also the case with previous PeopleSoft PeopleTools releases, there were
fewer use cases that loaded JVM.
 Plan for additional PSAPPSRV processes required to handle the related actions usage.
Push Notification Framework

The PeopleTools Push Notification framework can render the user interface with real time changes. This feature uses
WebSocket push technology in the web server with Tuxedo Eventing in Application Server.
For more details on Push Notification, refer to the product documentation PeopleTools: Fluid User Interface Developer’s
Guide, “Understanding the Push Notification Framework.”
In high load situations, if you see "java.util.ConcurrentModificationException" Java Exception on the web server, tune
the "SE_QUEUE_SIZE" parameter to improve the Server Side Event sending throughput.
The default value for "SE_QUEUE_SIZE" is 1000. Increasing this number can increase Server Side Event sending
throughput, but will also increase the web server JVM's heap usage. When tuning the "SE_QUEUE_SIZE" value, monitor
the web server's JVM heap size usage, and adjust the web server JVM "-XX:NewSize","-XX:MaxNewSize", "-Xms" and "-
Xmx" to the suitable size.

Note: Setting "SE_QUEUE_SIZE", "-XX:NewSize","-XX:MaxNewSize", "-Xms" or "-Xmx" too high may exceed the web
server hardware computing capability, thus derogating the entire web server's performance.
Tile Event Refresh Considerations

Push notification events can be used to force refresh of a tile. In the Fluid Attributes of the tile definition, select the
event name to subscribe to a push notification event defined on the server. Subscribing to an event allows the tile
content to be updated when the event is published.
While the push notification event framework is an effective method to automatically refresh a tile when a specific event
happens, there are potential performance ramifications that should be considered.
These are not good uses of Tile Event Refresh methodology:
 Frequently updated event: Frequently published events, especially when the events can be published by
multiple users, can bring about continuous rapid refreshes of the tiles subscribing to the event.
 Tile used by many users: Event triggered refresh of tiles viewed by many concurrent users can cause a spike in
resource usages. Whenever the event is published, all visible tiles subscribing to the event for all live users will be
refreshed. Since all tiles subscribing to the event for all users viewing the tiles will refresh at the same time, this
creates a peak load on the servers.
 Event for multiple tiles: All visible tiles subscribing to the same event will be refreshed at the same time. If the
tiles subscribe to different events, then the peak load will reduce since not all events will be published at the same
time. Use different functionally specific events for different tiles to reduce unnecessary concurrent tiles refreshes.
 Tiles with heavy processing: If the tiles are lightweight, then concurrent refreshes are fine. Limit auto refresh (by
timer or event) of tiles requiring heavy processing. If the application tile processing code takes time, then
application server queuing can occur and can delay other transaction processing as well.
File Attachments
PeopleTools supports a set of PeopleCode built-in functions to upload and download file attachments: AddAttachment,
MAddAttachment, ViewAttachment, and DetachAttachment. Files are transferred in chunks between the source
location and the target location.
In PeopleTools 8.52, non-database attachment uploads and downloads use a fixed chunk size of 16KB for upload and
download. In PeopleTools 8.53, for non-database repositories, like FTP, change to the Maximum Attachment Chunk
Size will affect all add, view, and detach attachment actions. The downloads will use the chunk size as specified by the
Maximum Attachment Chunk Size value. The uploads will use the chunk size as specified by the Maximum Attachment
Chunk Size value, but is limited to a maximum of 1 MB.
For database Add attachments, the chunk size is governed by the value in the Maximum Attachment Chunk Size field
on PeopleTools Option page. The system administrator can adjust this value to improve the performance of file
attachment features. A larger chunk size (where supported by your database) will result in fewer chunks, thus better
performance. For Oracle database, we recommend setting Maximum Attachment Chunk Size to 1 MB. When using a
database repository, viewing or detaching of the attachments will ignore change to the value of Maximum
Attachment Chunk Size. The chunks will be retrieved in the exact same size they are stored in the database.

Revision History
Document Revision History
DATE CHANGE
2021 April  Added Elasticsearch section.
2020 December  Added Kibana section.
 Removed the section Using Browser Statistics to Optimize Performance.
 Removed the section Confirm that the Posix Performance Pack is loaded.

Connect with us
Call +1.800.ORACLE1 or visit oracle.com. Outside North America, find your local office at: oracle.com/contact.
blogs.oracle.com facebook.com/oracle twitter.com/oracle
Copyright © 2021, Oracle and/or its affiliates. All rights reserved. This document is Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be
provided for information purposes only, and the contents hereof are subject to change trademarks of their respective owners.
without notice. This document is not warranted to be error-free, nor subject to any other
Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC
warranties or conditions, whether expressed orally or implied in law, including implied
trademarks are used under license and are trademarks or registered trademarks of SPARC
warranties and conditions of merchantability or fitness for a particular purpose. We
International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or
specifically disclaim any liability with respect to this document, and no contractual
registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open
obligations are formed either directly or indirectly by this document. This document
Group. 0120
may not be reproduced or transmitted in any form or by any means, electronic or
mechanical, for any purpose, without our prior written permission. Disclaimer: This document is for informational purposes. It is not a commitment to deliver any
material, code, or functionality, and should not be relied upon in making purchasing decisions.
This device has not been authorized as required by the rules of the Federal
The development, release, timing, and pricing of any features or functionality described in this
Communications Commission. This device is not, and may not be, offered for sale or
document may change and remains at the sole discretion of Oracle Corporation.
lease, or sold or leased, until authorization is obtained.

PeopleSoft Performance Guidelines April2021

Uploaded by

Copyright:

Available Formats

PeopleSoft Performance Guidelines April2021

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

PeopleSoft Performance Guidelines April2021

Uploaded by

Copyright:

Available Formats

What is the purpose of this document?

What is the purpose of this document?

What topics does it cover?

What topics does it cover?

PeopleTools Performance

PeopleSoft Technical Reference Paper

1 Technical Reference Paper / PeopleTools Performance Guidelines

2 Technical Reference Paper / PeopleTools Performance Guidelines

3 Technical Reference Paper / PeopleTools Performance Guidelines

4 Technical Reference Paper / PeopleTools Performance Guidelines

5 Technical Reference Paper / PeopleTools Performance Guidelines

6 Technical Reference Paper / PeopleTools Performance Guidelines

 PeopleSoft on Oracle Help Center

 PeopleSoft Information Portal

7 Technical Reference Paper / PeopleTools Performance Guidelines

 Determine the need for additional memory.

 Determine application server usage. (Microsoft Windows)

 Determine excessive memory swapping. (Microsoft Windows)

 Determine application server usage. (UNIX)

 Determine excessive memory swapping occurs. (UNIX)

 Manage application server recycling count.

 Manage application server recycling dynamically (PeopleTools 8.53 and Prior).

Determining the Need for Additional Memory

Determining Application Server Memory Usage (Microsoft Windows)

8 Technical Reference Paper / PeopleTools Performance Guidelines

3. Pick the Memory Usage and Virtual Memory Size columns.

Determining Excessive Memory Swapping (Microsoft Windows)

1. Start the Windows Performance Monitor, perfmon.

Determining Application Server Memory Usage (UNIX)

Here is sample output of the ps_chk_domain script:

9 Technical Reference Paper / PeopleTools Performance Guidelines

Please Enter interval in seconds?

Please enter # of interval's?

Tue Oct 23 23:00:33 PDT 2001

For all PS Processes:

Resident memory size is: 123.543 MB

CPU for PS Processes: 11 %

Virtual memory size is: 198.098MB

For all PSAPPSRV Processes:

Resident memory size is: 108.453MB

CPU for PS Processes: 9%

Virtual memory size is: 106.559 MB

Determining Excessive Memory Swapping (UNIX)

Managing Application Server Recycle Count

10 Technical Reference Paper / PeopleTools Performance Guidelines

Managing Application Server Dynamic Recycle (PeopleTools 8.53 and Prior)

11 Technical Reference Paper / PeopleTools Performance Guidelines

 Enable non-shared cache.

 Enable shared cache.

 Enable database cache. (PeopleTools 8.51 and later.)

 Load persistent application server cache.

 Use application server cache over NFS.

Understanding Application Server Cache Options

 The requested object has been changed.

Enabling Non-Shared File Cache

Enabling Shared File Cache

12 Technical Reference Paper / PeopleTools Performance Guidelines

Enabling Database Cache (PeopleTools 8.51 and Later)

 The requested object has been changed.