Administering the Performance Monitor

This chapter provides an overview of Performance Monitor and discusses how to:

Set global system options.
Set system definition defaults.
Modify system definitions.
View agent definitions.
Set agent filter options.
Schedule the reaper program.
Schedule performance data archiving.
Populate Performance Monitor lookup tables.
Work with Performance Monitor tables.
Disable Performance Monitor agents.
Work with Performance Monitor web profile properties.
Trace Performance Monitor agents.
Trace the Monitor and PPMI servlets
Configure performance monitoring sampling rate.
View monitor servlet diagnostics.
Set up monitor clusters.
Use Performance Monitor data mover scripts.
Estimate you performance database size.

Performance Monitor Administration

This section discusses Performance Monitor administration and lists the pages used for Performance Monitor administration.

Performance Monitor Administration

Performance Monitor administration includes:

Specifying global settings.
Viewing performance definitions such as those related to systems, agents, metrics, and so on.
Setting system defaults.
Scheduling batch programs that maintain performance data.

Pages Used for Performance Monitor Administration

Page Name	Object Name	Navigation	Usage
Global Administration	PSPMMONITORGBL	PeopleTools, Performance Monitor, Administration, Global Administration	View and modify global administration settings, such as the PPMI URL value and monitor servlet clusters.
System Defaults	PSPMSYSDEFAULTS	PeopleTools, Performance Monitor, Administration, System Defaults	Set global system defaults for all monitored systems.
System Definitions	PSPMSYSDEFN	PeopleTools, Performance Monitor, Administration, System Definitions	View and modify the system definition that is associated with each of the systems that are being monitored. For example, you can set archive, PMU timeout, and agent buffer size.
Agent Definitions	PSPMAGENT	PeopleTools, Performance Monitor, Administration, Agent Definitions	View the definitions of the agents that are running on the monitored system's application server, web server, and Process Scheduler servers. It also enables you to disable the display of agent information.
Agent Filters	PSPMAGENTFILTER	PeopleTools, Performance Monitor, Administration, Agent Filters	Set the filter levels for the agents that are running on the monitored system. The filter level determines the amount and granularity of the performance data that is reported by an agent.
Schedule Reaper	PSPMREAPERRUNCNTL	PeopleTools, Performance Monitor, Administration, Schedule Reaper	Schedule the PeopleSoft Application Engine reaper program that is designed to maintain the integrity of the performance data that is in your monitoring system.
Schedule Archive	PSPMARCHIVERUNCNTL	PeopleTools, Performance Monitor, Administration, Schedule Archive	Schedule the PeopleSoft Application Engine archive program that is designed to archive or purge the performance data that is in your system.
Schedule Lookup Maintenance	PSPMLOOKUPRUNCNTL	PeopleTools, Performance Monitor, Administration, Schedule Lookup Maintenance	Schedule the PeopleSoft Application Engine program that is designed to maintain the lookup lists that are associated with the Performance Monitor interface. The lookup maintenance program ensures that the lookup lists are populated with current lookup options.

Setting Global System Options

Access the Global Administration page.

PPMI URL

The PPMI URL that is stored in the monitoring system's database is used by PSPPMSRV processes to locate the PPMI servlet with which to register.

The format of the URL is: http[s]://<host[:port]>/ppmi/<site_name>/

For example,

http://server1.peoplesoft.com/ppmi/ps/

After you specify this URL value, it is stored in the URL catalog under the ID PPM_PPMI.

Note. If you select HTTPS, then the PSPPMSRVs use SSL encryption when sending the PPMI user ID and password to the PPMI servlet, but performance data sent from the PPMI servlet to PSPPMSRV is not encrypted. Because the data is not encrypted, the PSPPMSRV and the monitor servlet should reside in a secure network environment.

Note. Use the Ping Test button to verify that you have entered a valid URL and that the URL is available.

PPMI User ID

The PSPPMSRV server processes pass this user ID and password to the PPMI servlet. The servlet verifies that the user ID and password are valid, and that the user has permission to access the PPMI servlet.

The user ID that you specify must have a permission list with Performance Monitor PPMI Access selected in its PeopleTools permissions. PeopleTools recommends using the PTPMCLNT permission list, which is shipped expressly for this purpose.

Note. The PPMI User ID and PPMI Password values are required.

See Performance Monitor Security Considerations.

PPMI Password

The password associated with the PPMI user ID.

Archive: Clear PMUs & Events

Indicates to the archive program to delete all of the performance history data that is currently stored in the monitoring database. This is in the form of an unqualified DELETE on the history tables, or for those platforms for which it is supported, the tables are truncated.

Note. If you select this option, the delivered archive program deletes all of the performance history data for every monitored system.

Note. Deleting and truncating performance data may cause the current user count to appear artificially low. The system bases the count on events that are found in the PSPMEVENTHIST table, and rows from this table may be deleted during the archive process.

Note. This option overrides any archive mode option that is set on the System Definition page.

See Modifying System Definitions.

Collator Row Limit

Limits the amount of data that can be inserted into the Performance Monitor tables. Collators (PSPPMSRVs) periodically count the number of rows in each of the performance tables. If the total count of rows in PSPMTRANSHIST, PSPMTRANSCURR, and PSPMEVENTHIST is higher than this value, the PSPPMSRV does not insert any more rows into these tables until the number of rows deleted (by the archive program, the reaper program, manual intervention, or any combination of the three) brings the row count below this limit. If you set this value to 0, the PSPPMSRVs do not check for a row limit.

Note. If the row limit is reached, the System Performance page will report that the agents on the monitored system have stale agent data.

Search Row Limit

Limits the number of rows that are returned and displayed in searches that are initiated from Performance Monitor pages. The system imposes this limit on all users who access the monitoring system.

Performance Monitor Cluster

To provide failover and scalability, performance monitor servlets on multiple web servers can be configured as a cluster. Entering the cluster information in the Performance Monitor Cluster grid enables the load-balanced monitor and PPMI servlets to share client registration information so that PSPPMSRV instances need not be aware of the cluster configuration.

The format of the cluster member URL is http://host[:port]/ppmi/<site_name>/, where the host name is the actual web server machine.

Click Save and Notify Cluster to notify the cluster if you have added or removed a cluster member.

Click Ping Test to verify that you have entered a valid URL and that the URL is available.

See "Setting up Monitoring Clusters" below.

Setting System Definition Defaults

Access the System Defaults page.

The System Defaults page enables you to set default values for all of the monitored systems. If you intend to monitor numerous systems, you can set the default values that you need for a system. When a new systems register with the monitoring system for the first time, the system adopts the default values that you have set.

Using the System Defaults page enables you to set global values for each monitored system rather than modifying the values for each system separately.

Note. Except for the following page elements, the System Defaults page is identical to the System Definitions page, which is documented in the following section.

Agent Filter Level

Set the agent filter level for the agents of monitored systems. The default setting is 01–Standby, which means that the monitored system sends no performance information to the monitoring system.

See Setting Agent Filter Options.

Apply to Current Systems

Notifies the agents that are running in existing systems of the global configuration changes. When the agents of the existing monitored systems are notified, the existing systems adopt the new, default values.

Viewing Agent Definitions

Access the Agent Definitions page.

Agent definitions enable you to view the details about the agents in monitored systems.

System ID	Identifies each monitored system. The PeopleSoft system automatically generates this value incrementally. System definitions are created automatically when the first agent of a monitored system registers with the monitoring system.
Database Name	The name of the PeopleSoft application database that is running on the monitored system. The monitoring system automatically inserts this value when it recognizes and creates a monitored system.
Agent ID	Uniquely identifies an agent within a system. This is automatically generated by the monitor the first time an agent registers with it.
Domain Name	The name of the domain (application server or web server) in which the agent operates.
Agent Type	Indicates the type of server process the agent is monitoring.
Domain Type	Indicates whether the domain is an application server, a web server, or a Process Scheduler server domain.
Domain Monitor	Displays as Yes or No. If Yes, then this agent is responsible for sending resource events for its host or domain to the monitor at the specified sampling rate for the monitored system.
Server Instance	This number is specific to Tuxedo servers and corresponds to the Tuxedo instance number.
Domain Host/Port	The name or IP address of the server on which the domain resides, including the port number to which the domain listens for requests. Note. Web server agents register with both the HTTP and the HTTPS ports. The application server agents register with the Jolt Server Listener (JSL) port. Process Schedulers do not have ports.
Domain Directory	The directory in which the domain is installed on the server.
Inactive Agent	If this box is selected, the agent is considered inactive. That is, the agent's events and PMUs do not appear in the Performance Monitor pages showing current information. You can still view information about events and PMUs that are sent by inactive agents using the pages that display historical information. To reactivate an agent, clear the check box, and click Save. To deactivate an agent, select the check box, and click Save.

Setting Agent Filter Options

Access the Agent Filters page.

Agent filters determine the amount of performance data that is generated and sent to the monitoring system. Depending on the situation, different levels of performance data may be needed to assist in your performance-related decisions. The levels range from no information to extremely detailed information.

Each type of PMU and event is associated with a filter level, which is the lowest level at which the system generates performance data for that PMU or event.

System ID	Identifies each monitored system. The PeopleSoft system automatically generates this value incrementally. System definitions are created automatically when the first agent of a monitored system registers with the monitoring system.
Database Name	The name of the PeopleSoft application database that is running on the monitored system. The monitoring system automatically inserts this value when it recognizes and creates a monitored system.
Reset All Filters	Enables you to uniformly adjust the agent filter levels across an entire system. Select the desired level and click Apply.
Agent Filters	The Agent Type column displays the types of agents that are currently known to the monitoring system. The Last Update User ID column and Last Update Date/Time column display the user ID that last updated the filtering level and the date and time when the user made the last filtering level change. The Filter Level column contains a drop-down list box for setting the filtering level. You have the following options: 01 Standby: The monitor system sends no performance data to the monitor. Agents on this monitored system contact the monitor at an interval that is specified by the agent heartbeat interval. 02 Error: Only error events are reported to the monitoring system by the agents. 03 Warning: Only error and warning events are reported to the monitoring system by the agents. 04 Standard: This is the default level of monitoring that is adopted by agents when they first register with the monitor. In addition to errors and warnings, PMUs and events with a filter level of Standard are reported to the monitoring system. This is the recommended setting for monitoring production environments. It provides sufficient diagnostic information to isolate performance problems without inundating the network or monitoring database with performance data. 05 Verbose. In addition to errors and warnings, and standard PMUs and events, PMUs with a filter level of Verbose are reported to the monitoring system. This setting provides more detailed performance metrics and may, for some production systems, be worth the overhead that is associated with this monitoring level. 06 Debug: In addition to errors and warnings, standard and verbose PMUs and events, PMUs with a filter level of Debug are reported to the monitoring system. This setting provides extremely detailed performance metrics and is not suitable for monitoring production systems. It is intended only for development and test environments.
Save and Notify Agents	Notifies the PPMI servlet of configuration changes that are made on this page. First, the system saves the changes to the database. Notification occurs through the PeopleSoft Integration Broker gateway. The monitor servlet notifies the agents of changes when the agents next communicate with the monitor. A delay occurs in publishing changes to the monitored systems. The maximum delay is the agent heartbeat interval.

Scheduling the Reaper Program

The reaper program is a delivered PeopleSoft Application Engine program named PSPM_REAPER. The reaper program maintains the PeopleTools tables that the Performance Monitor uses to store performance data for current, real-time processing.

When the PSPPMSRV gets notified that a PMU has finished (it receives a STOP for an open PMU), it:

Flags the corresponding start and update rows in the current PMU table (PSPMTRANSCURR) for deletion.
Inserts a row for the completed PMU in the PSPMTRANSHIST table.

When the reaper program (PSPM_REAPER) runs, it:

Deletes all rows in current PMU table (PSPMTRANSCURR) that are flagged for deletion.
Sets the status to timed out for expired PMUs in the current tables.

To run the reaper program:

Select PeopleTools, Performance Monitor, Administration, Schedule Reaper.
Select or add a run control ID.
Click Run.

PeopleTools delivers a recurrence definition named PerfMon Reaper Recurrence, which is set to run every 15 minutes. Modify this recurrence definition, if necessary, and associate it with the PSPM_REAPER program to schedule the program to run at suitable intervals.

Warning! If you do not schedule the reaper program to run often enough, the PSPMTRANSCURR table will grow very large over time, and it may contain many old, open PMUs.

Scheduling Performance Data Archiving

Performance data archiving options are set per system definition. So your HCM system and your CRM system may have different archiving modes. You define your archive settings in the Archive Mode group box on the System Definition page. The performance data archiving program is a PeopleSoft Application Engine program named PSPM_ARCHIVE.

Note. The system overrides the archive options that are set in the System Definition page if you have selected the Clear PMUs & Events option on the Global Administration page.

See Setting Global System Options.

Note. PeopleSoft provides sample queries that demonstrate how to access data in the archive tables. Currently, no other delivered method of accessing the data is available in archive tables.

See Working with Performance Monitor Tables.

Running the Performance Data Archiving Program

To run the archiving program:

Select PeopleTools, Performance Monitor, Administration, Schedule Archive.
Select or add a run control ID.
On the Schedule Archive page:
- Determine whether you want to enable Run %UpdateStats at the end.
  
  If you enable this option, the system runs %UpdateStats meta-SQL on both the history and archive tables after the archive program finishes successfully.
- Click Run to launch the archive program.

Note. You should set up a recurrence definition in Process Scheduler so that the archiving program runs at regular intervals. This can help keep the performance history tables at more manageable sizes while containing the most relevant data.

Working with Aborted Program Runs

If the performance data archiving program does not finish successfully, the system automatically invokes the PeopleSoft Application Engine program named PSPM_ARCHREC. This program is designed to return the system to the state it was in before the archive program started.

During an archive program run, the PSPPMSRVs redirect incoming PMU and event data to cloned history tables. When the archive program finishes, the system moves the data in the cloned tables to the history tables and the PSPPMSRVs resume inserting data directly into the history tables. If the archive program does not finish successfully, the PSPPMSRVs continue to insert data into the cloned tables.

Populating Performance Monitor Lookup Tables

On many of the pages that are used for viewing performance information, such as the Current PMUs page, you are prompted to enter either a user ID, a component name, or a performance trace name to narrow the search to relevant performance data. Unless you are self-monitoring, the monitored system components and User IDs differ from those of the monitoring system. Therefore, the performance monitor provides its own lookup tables, and the PSPM_LOOKUP PeopleSoft Application Engine program populates these lookup tables.

To run the lookup program:

Select PeopleTools, Performance Monitor, Administration, Schedule Lookup Maintenance.
Select or enter a run control ID.
On the Schedule Lookup page, click Run to launch the lookup program.

Note. You should set up a recurrence definition in Process Scheduler so that the lookup program runs at regular intervals.

Working with Performance Monitor Tables

As with any PeopleTool or PeopleSoft application, the underlying application definitions and application data reside in a collection of database tables that are designed using Application Designer. Although most PeopleSoft applications provide data models that show the relationships between the database entities, typically, for PeopleTools, knowledge of the underlying database tables is not required.

However, with the Performance Monitor, knowledge of the underlying database tables may be required. For example, the Performance Monitor interface provides numerous options to use when you are viewing performance data, such as viewing by time range, viewing by user, viewing by component, and so on. In some cases, you may want a more customized view of your performance data than what the interface offers.

You can use PeopleSoft Query, or your SQL tool of choice, to build queries that run against the Performance Monitor tables and return the specific information that you require.

To assist you in creating custom queries, the Performance Monitor data model appears in the form of an entity relationship diagram (ERD) that is posted on Customer Connection. Refer to the Enterprise PeopleTools Release Notes for this release for the current location of the Performance Monitor ERD.

See "PeopleTools 8.45 and 8.46: Performance Monitor Database Schema and Use Cases" on Customer Connection.

Note. The Performance Monitor database schema may change in future releases.

To view the results of sample queries running against the Performance Monitor tables, select PeopleTools, Performance Monitor, History, Sample Queries. To view the definitions and SQL of these sample queries, use PeopleSoft Query Manager. The sample queries attempt to show a realistic query while using all of the tables that you may want to include in similar queries.

The sample query definitions are:

Query	Description
PPM_COMP_BUILD_CACHE	This query returns all application server requests for a specific system that had to retrieve metadata from the database as opposed to the cache. It also shows the file cache and memory cache for comparison. This query returns information from the PMU history table.
PPM_COMP_BUILD_CACHE_ARCH	This query is similar to PPM_COMP_BUILD_CACHE, except that it returns information from the PMU archive table.
PPM_TIMEOUT_SQL_REQ	This query returns information from the PMU history table while joining information that is stored in the event table. This query retrieves all PMU 400s (Tuxedo Service PCode and SQL) that were running SQL statements when an Event 500 (Jolt Service Exception) was received. It is assumed that this exception occurred because of a timeout, but it could also have been due to an application server outage or a Jolt error.
PPM_TIMEOUT_SQL_REQ_ARCH	This query is similar to PPM_TIMEOUT_SQL_REQ, except that it returns information from the PMU and Event archive tables.
PPM_APPSRV_START_COUNTS	This query returns starting counts for different server processes over a period of time for a specific domain.
PPM_APPSRV_START_COUNTS_ARCH	This query is similar to PPM_APPSRV_START_COUNTS, except that it fetches information from the event archive table.

Note. When you are running a sample query, the system prompts you to enter a date. The format for the date is MM/DD/YYYY HH:MM:SS AM/PM. For example, 09/03/2003 12:00:01AM.

Disabling Performance Monitor Agents

In some cases, you may not want the Performance Monitor agents to run or to be a possible factor in your online system. For example, if you have ten application server domains running against the same database, you may want only one application server domain reporting information to the monitoring system.

Agents in a domain whose monitor URL is "NONE" do not collect or transmit performance data. However, they periodically check the URL for changes. Disabling a domain prevents this small portion of Performance Monitor related processing from occurring. To prevent any information from being sent over the network, set the monitor URL to NONE and reboot all monitored domains. To completely disable monitor agents on your domains, deselect the Enable PPM Agents parameter and reboot all monitored domains.

Application Server and Process Scheduler Domains

For application server and Process Scheduler domains, you disable the monitor agents using the EnablePPM Agents parameter. This parameter is in the PSTOOLS section of PSADMIN. To disable the monitor agents, set the value to0. To enable the monitor agents, set the value to 1.

Reboot the application server domain for the change to take effect.

When disabled, the Monitor URL is ignored by that domain.

Web Server

For the web server, you disable agents by deselecting the Enable PPM Agents option in the Web Profile interface.

Reboot the web server for the change to take effect.

Working with Performance Monitor Web Profile Properties

This section alerts you to important web profile properties that are related to the Performance Monitor.

Enable PPM Agent	Enables a web server agent to be started on a monitored web server.
PPM Monitor Buffer Size	Sets the maximum buffer size for the buffer that is used by the monitor servlet for incoming performance data. The default size is 51200 KB (50 MB). If you notice in servlet trace files or other warnings that you regularly see buffer overflows, you may consider increasing this value.
Trace Monitoring Server	Located on the Debugging tab. Enables you to trace the ppmi servlet and the monitor servlet. The system writes the trace information to the web server log file.
Trace PPM Agent	Located on the Debugging tab. Enables you to trace web server agents on a monitored system. You enable this option on the web server of the monitored system.
PPMConsole	See Viewing Monitor Servlet Diagnostics.

Tracing Performance Monitor Agents

You can set up tracing on the:

Application server and Process Scheduler servers.
Web server.

Enabling Tracing on the Application Server or Process Scheduler Server

To enable tracing of the monitor agents on application server and Process Scheduler domains, use the TracePPM parameter in PSADMIN on the application server running on the monitored system. Set TracePPM to 1. To disable, set to 0.

When enabled, the agents write debug information on monitored systems to a log file in the application server LOGS directory. To view the information, open TRACEPPM_mmdd.LOG. The LogFence setting for application server logs has no effect on this file. Error messages (such as those that are created when the monitor URL can't be reached) go directly to the APPSRV_mmdd.LOG.

Enabling Tracing on the Web Server

To enable tracing of the monitor agents on the web server, select Trace PPM Agent on the Debugging tab in the appropriate web profile on the monitored system.

The agents write tracing information to the web server log file.

Tracing the Monitor and PPMI Servlets

In some cases, you may want to view the activity of the monitor and PPMI servlets that are running on the web server on the monitoring system.

To enable tracing for the Performance Monitor servlets, you select the Trace Monitoring Server option on the Debugging tab in the appropriate web profile. The system writes the trace results to the web server log file.

Configuring Performance Monitoring Sampling Rate

To reduce the overhead that is incurred by monitoring performance, you may not want to monitor every request that is submitted to your system. You can set a sampling rate for your monitored systems so that only one out of every N server requests generate PMUs. For the Nth request, all PMUs are generated at the filter level that is set for each agent type involved in processing the request. Examples of server requests would be browser requests to a web server or Application Designer requests to an application server (when running in a three-tier configuration). You set the sampling rate for PMUs using the Agent PMU Sample Rate option on the System Definitions page.

Note. This sampling rate applies only to PMUs, not events.

For example, if you set the sampling rate to 1/10, the system monitors the first PIA request, but does not monitor another request until the 11th request arrives at the system.

Some PMUs are always monitored regardless of the sampling rate. The PMUs that are never ignored are those that have the Enable Sampling option cleared on the PMU Definitions page. Examples of such PMUs are those related to users signing on, signing off, and being redirected to other sites.

Note. Setting the sampling rate to 0 (zero) disables sampling.

The web server and the application server maintain separate counters. The web server counts all browser requests, and the application server counts all requests that are submitted directly to the application server, such as component interfaces or Microsoft Windows workstations running Application Designer.

Viewing Monitor Servlet Diagnostics

You can view diagnostic information that is related to the monitor servlet by accessing the servlet using the following URLs.

URL	Description
http://<host>/monitor/<site>/?cmd=agents	Reveals additional statistics about the agents sending data to the monitor servlet.
http://<host>/monitor/<site>/?cmd=ppmiclients	Reveals additional statistics about the PPMI clients receiving data from the monitor servlet.

Note. By default, access to this interface is disabled. To provide access to this interface, you must add the PPMConsole property to the Custom Properties tab in the appropriate web profile. The PPMConsole property is boolean. Set the value to true to enable access to this interface. To disable access, set the value to false or remove the property entirely from the custom properties list.

Monitoring Agents

Agents refers to the agents on various monitored systems that send performance data to the current monitor servlet.

The system retrieves the agent information from the monitor's cache. If an administrator has changed any agent settings and clicked Save and Notify Agents on the System Definitions page, the agent information temporarily disappears in the Agents grid. Updated agent settings appear in the Agents grid after the agent communicates with monitor servlet.

Note. You identify the monitored system, using the system ID (PeopleSoft GUID) appearing just above each grid. To identify the agents, you need to map the system GUID and agent ID with the definitions in the monitoring database.

Note. Agents appear in the grid if they have successfully registered. The appearance of an agent does not imply that data from the agent is being successfully inserted into the monitoring database.

The following information appears in the Agents grid.

ID	The agent ID that uniquely identifies an agent within a monitored system.
Last Comm	The last time the agent contacted the monitor servlet.
Filter	The current agent filter level.
Buf-Size (buffer size)	The current maximum buffer size for the agent that is specified in the system definition.
Send-Itvl (send interval)	The current agent buffering interval.
Heartbeat	The current agent heartbeat interval
Sample-Itvl (sample interval)	The current agent event sample rate.
User Trace	Indicates whether performance trace is allowed for this agent.
Sampling Rate	The current PMU sample rate.
Sampling Filter	This column is reserved for future use.

Monitoring PPMI Clients

PPMI clients refer to the PSPPMSRV server processes that interact with the monitor servlet. The Clients grid shows all known PPMI clients.

The following information appears in the Clients grid.

Group	The system's unique identifier (PeopleSoft GUID).
ID	The internal ID assigned to this PSPPMSRV.
URL	The IP address of the PSPPMSRV.
Queue Length	The number of PMUs and events not yet sent to this PSPPMSRV.
Estimated Queue Size	The estimated size in bytes of the PMUs and events not yet sent to this PSPPMSRV.
Item Processed	The number of PMUs and events sent across this PSPPMSRV connection.
Estimated Bytes Processed	The estimated size in bytes of the PMUs and events sent across this PSPPMSRV connection.
Max Size	The maximum buffer size in bytes for the PMU and event queue reached in the lifetime of this connection.
Running Avg Size (running average size)	The running average of the estimated size in bytes of the PMUs and events not yet sent to this PSPPMSRV.
Limit	The maximum buffer size in bytes for the PMU and event queue. Data is discarded when this limit is reached.

Setting Up Monitor Clusters

The following diagram depicts the relationship between the elements involved in a monitor cluster. In this diagram, the cluster contains two web servers.

Monitor cluster elements

When implementing a monitor cluster, keep these items in mind:

A cluster must be accessed through an external third party load balancer.
The web servers in a monitor cluster share PSPPMSRV registration information using HTTP/S.
Each monitor servlet (one in each web server) load balances performance information across all PSPPMSRVs.
The host and port of the PPMI URL for a clustered environment need to be set to reflect the host and port of the load balancer.

Note. External load balancers should ensure that performance information that is related to one agent is always sent to the same monitoring servlet. When sending performance data to the monitor, agents add their agent ID to the monitor URL. For example, for agent 8, the URL appears as http://host1/monitor/ps/8. The system administrator should set up a "sticky rule" on the load balancer so that requests from the same agent are always directed to the same web server, when available. If the sticky rule is not in place, a PMU stop time may be inserted into the monitoring database before the corresponding start time. This creates misleading open PMU information and more work for the reaper program.

See Performance Monitor Security Considerations.

Note. If a cluster member shuts down, all performance data that is currently queued on that cluster member for transmission to a PSPPMSRV is lost.

To set up a performance monitor cluster:

In the monitoring system, use the host and port of the load balancer in the PPMI URL on the Global Administration page.
In the monitoring system, enter the URLs of each load-balanced host in the Performance Monitor Cluster grid on the Global Administration page.

The format of the Member Servlet URL is:

http[s]://host/ppmi/ps

Where ps is the name of your PeopleSoft site, and host is the real host and port of the host on which your cluster member is running. Even though you enter ppmi as the servlet name, failover and scalability are implemented for both the PPMI and the monitor servlets from each site.
In the monitored system, use the host and port of the load balancer in the monitor URL on the Specify Monitor page.

Using Performance Monitor Data Mover Scripts

PeopleSoft delivers a set of PeopleSoft Data Mover scripts for use in the administration of the Performance Monitor. The scripts are located in the following directory:

PS_HOME\scripts

The delivered scripts are described below.

perfmondataexport.dms

Enables you to export data from your monitoring database.

The data can be exported based on a specific system ID, between specific dates and times, or based on a specific performance trace. The default export is based on a specific system ID. The dat file that is created is named perfdata.dat.

If you need to export performance data from a specific date and time, a performance trace, or information on all monitored systems, then open the script and edit the script as described in the comments within the script.

perfmondataimport.dms

Enables you to import data from perfdata.dat, which is created by the perfmondataexport.dms script, into your monitoring database.

Warning! Do not run this file on a live monitoring system because current data may be lost. The script contains the REPLACE_DATA * command.

PerfmonPurgeAll.dms

Enables you to purge all Performance Monitor tables in the monitoring database.

Note. This script deletes both system definitions and all performance data that are associated with any monitored system.

Warning! Shut down the monitoring system before running this script.

Estimating Your Performance Database Size

This section provides an overview of estimating your performance database size overview and discusses how to:

Estimate space requirements for event data.
Estimate space requirements for PMU data.
Calculate space requirements.

Estimating Your Performance Database Size Overview

Because performance monitoring can store a significant amount of data in your performance database, you may want to estimate the amount of data to be stored in your performance database so that you have, or are able to provide, the appropriate amount of space.

Performance database sizing estimates are based on the sum of space requirements for events and performance measurement unit (PMU) performance data. Event data resides in the PSPMEVENTHIST table. PMU data resides in the PSPMTRANSHIST and PSPMTRANSCURR tables.

This section presents formulas that you can use to estimate the potential size of your performance database.

These formulas incorporate the following assumptions and considerations:

Performance Monitor is set to Standard agent filter mode.
Estimates do not include space required for Verbose or Debug agent filter mode.
Index overhead is included in the estimate.
Performance history data is purged after a number of days (see parameter D in the following section).
The archive mode of a monitored system is set to Delete Data after N days and the performance data archive program is scheduled to run daily.
The reaper program is scheduled to run at least once a day.
No performance data is stored in the archive tables (PSPMTRANSARCH and PSPMEVENTARCH).
The calculation formulas use only the parameters that are presented in this section to calculate the estimates. In all cases, the numbers are conservative. For example, the exact formula may use (App – 1) but we choose to round up and use App instead.

Estimating Space Requirements for Event Data

This section discusses two formulas that are used for estimating event data space requirements (in kilobytes).

Standard formula: Use the standard formula if the application server domain configuration is based on PeopleSoft-delivered small, medium, or large template.
Customized formula: Use the customized formula if the configuration is different from the templates.

This table describes the variables that are used in the formulas.

Notation	Description	Performance Monitor Default Value	Navigation
A	Performance Monitor agent event sampling rate.	300 seconds	PeopleTools, Performance Monitor, Administration, System Definitions
N	Number of PeopleSoft systems that are monitored by Performance Monitor. This is the number of PeopleSoft databases appearing on the System Definitions search page.	NA	PeopleTools, Performance Monitor, Administration, System Definitions
D	Performance history retention period in days. This is the value that is set for the After N days option.	NA	PeopleTools, Performance Monitor, Administration, System Definitions
W	Number of web server domains for a monitored system. This is the total number of web servers appearing on the System Performance page.	NA	PeopleTools, Performance Monitor, System Monitor, System Performance
P	Number of application server domains for a monitored system. This is the total number of application servers appearing on the System Performance page.	NA	PeopleTools, Performance Monitor, System Monitor, System Performance
App	Number of server processes running in an application server domain for a monitored system. This is the number of program names appearing on for Server Status.	Use the following number per domain template that you choose: Large = 60 Medium = 40 Small = 20	PSADMIN, Application Server, Administer a domain, Domain, Domain status menu, Server status
S	Number of monitored PeopleSoft Process Scheduler domains for a monitored system. This is the total number of Process Scheduler domains appearing on the System Performance page.	NA	PeopleTools, Performance Monitor, System Monitor, System Performance
Prcs	Number of server processes running in a PeopleSoft Process Scheduler domain for a monitored system. This is the number of program names appearing for Server status.	8 Increase this number if more than three Application Engine processes are configured.	PSADMIN, Process Scheduler, Show Status of a Process Scheduler Server, Domain, Domain status menu, Server status
MPrcs	Number of Master Scheduler for a monitored system.	1	NA
E	Number of KB per event row in the table.	Refer to the value in the following table for the target database.	NA

The following table helps you to determine the appropriate value for E (Number of KB per event row in the table).

Parameter	ANSI/Unicode	Oracle	Microsoft SQL Server	DB2 UDB	DB2/390
E	ANSI	.4	.4	.5	.6
E	Unicode	.7	.7	.9	1.1

Using the Standard Formula

The formula that you use differs depending on the template used in the application server configuration.

Large

N x D x [8 x W + 180 x P + 16 x S + 1] x 86400 / A x E

Medium

N x D x [8 x W + 120 x P + 16 x S + 1] x 86400 / A x E

Small

N x D x [8 x W + 60 x P + 16 x S + 1] x 86400 / A x E

Using the Customized Formula

Use this formula if the application server configuration is different from the standard templates.

N x D x [8 x W + 3 x P x App + 2 x S x Prcs + MPrcs] x 86400 / A x E

Note. Eight events are reported per web server domain. Two events are reported per web server (JVM status and network status), one event per web site, and five events per web site for PeopleSoft servlets (psp, psc, cs, *, and Scheduler Transfer).

If multiple systems are monitored and each is configured slightly differently, that is, the numbers of application server processes are different, then use the formula to estimate the requirement for each system separately.

Estimating Space Requirements for PMU Data

The total space requirements, in kilobytes, for PMU data that is stored in PSPMTRANSHIST and PSPMTRANSCURR tables can be estimated using the following formula:

N x [D + 1] x L x R x M x T

This table describes the variables that are used in this formula.

Notation	Description	Performance Monitor Value Default	Navigation
N	Number of PeopleSoft systems that are monitored by Performance Monitor. This is the number of PeopleSoft databases appearing on the System Definitions search page.	NA	PeopleTools, Performance Monitor, Administration, System Definitions
D	Performance history retention period in days. This is the value that is set for the After N days option.	NA	PeopleTools, Performance Monitor, Administration, System Definitions
L	Number of user sessions per day for a monitored system. A session means that a user signs on, performs a few transactions, and signs off.	NA	NA
R	Number of user interactions per session. User interactions are anything that triggers a server trip, including clicking a button, clicking TAB, and so on.	NA	NA
M	Number of PMU rows that are captured per user interaction.	9	NA
T	Number of KB per PMU row in the table.	Refer to the value in the following table for the target database.	NA

The following table helps you to determine the value for T.

Parameter	ANSI/Unicode	Oracle	Microsoft SQL Server	DB2 UDB	DB2/390
T	ANSI	1.3	1.4	1.8	2.1
T	Unicode	2.4	2.6	3.3	3.8

Calculating Space Requirements

This section presents an example of using the formulas to estimate the performance database size for a fictitious organization.

Company ABC uses Performance Monitor to monitor two PeopleSoft Enterprise Applications, Financials and HCM (N=2). Both applications use DB2 UDB Unicode databases. The company has decided that the performance history data will be kept for a 7-day period (D=7). Each system has two web server domains (W=2), two application server domains (P=2), and two PeopleSoft Process Scheduler domains (S=2). The implementation team decides to use the medium application server configuration for both domains. One Master Scheduler exists for each of the systems (MPrcs=1).

It is estimated, on the average, that 10,000 user sessions (L=10000) will be logged per day in each of the systems. During each session, 50 user interactions (clicking buttons, tab to next field or page, and so on) will occur (R=50).

This is the sample calculation for event data space (using the standard formula for a medium configuration):

N x D x [8 x W + 120 x P + 16 x S + 1] x 86400 / A x E

= 2 x 7 x [8 x 2 + 120 x 2 + 16 x 2 + 1] x 86400 / 300 x E

= 1,165,248 rows x 0.9 KB per row

= 1,024 MB

This is the sample calculation for PMU data space:

N x [D + 1] x L x R x M x T

= 2 x [7 + 1] x 10000 x 50 x 9 x T

= 72,000,000 rows x 3.3 KB per row

= 232,032 MB

This is the formula for space requirement for storing performance data on a DB2 UDB Unicode database:

1,024 MB + 232,032 MB = 233,056 MB

Company ABC decides to add a 1 TB disk.

Business is going well for ABC Company. The demand for the Financial application increased by 50 percent. The IT department decided to add new web server, application server, and PeopleSoft Process Scheduler domains for the Financials application (N=1). According to the system administrator, when the application server domain is booted, a “22 processes started” message appears (App=22), and the PeopleSoft Process Scheduler domain shows a “12 processes started” message (Prcs=12). The IT department needs to estimate whether enough disk space is available to store additional performance data.

Use the customized formula to calculate the space requirement for event data that is generated by the new configuration.

N x D x [8 x W + 3 x P x App + 2 x S x Prcs + MPrcs] x 86400 / A x E

= 1 x 7 x [8 x 1 + 3 x 1 x 22 + 2 x 1 x 12] x 86400 / 300 x E

= 153,216 rows x 3.3 KB per row

= 494 MB

System usage increased by 50 percent for the Financials application, so the total space requirement is:

233,056 MB + 494 MB + [233,032 MB/2 x 50%]

= 291,558 MB

The IT department concludes that enough space is available to store the performance data.

System Identifier	Identifies each monitored system. PeopleSoft automatically generates this value incrementally.
Database Name	The name of the PeopleSoft application database that is running on the monitored system. The monitoring system automatically inserts this value when it recognizes and creates a monitored system.
Unique Identifier	Uniquely identifies a particular PeopleSoft system. PeopleSoft assigns a unique value, referred to as a GUID, to each PeopleSoft application installation. When an agent registers with the Performance Monitor, it provides this GUID. The first time the monitoring system receives information from a monitored system, it detects the GUID. For each new GUID that is detected, the monitoring system creates a new monitored system definition. Note. When copying databases, you should delete the GUID in the new (copied) database. If the new database is monitored by the same instance of the Performance Monitor that is monitoring the source database, the monitor assumes that the agents for both systems belong to the same system. This not only doubles the data that is being stored for a particular system, but also makes it unreliable. To resolve this, set the value of the GUID field in the PSOPTIONS table to <space> in the new database. The next time an application server connects to the database, the system generates a new, unique GUID. You insert the blank value in the PSOPTIONS table using the SQL tool at your site. Note. After cloning a database and before booting the web server and application server, you should set the PPMI and monitor URL to NONE in the cloned database. This will prevent the agents of the cloned database from reporting into the monitoring system that was used previously. To reset the URLs, update the URL field to NONE in the PSURLDEFN table where the URL_ID field is'PPM_MONITOR or PPM_PPMI.
Description	A description of the monitoring system to assist recognition. The default value is the database name.
Archive Mode	The archive mode that you set specifies how the archive program (PSPM_ARCHIVE) should process the performance data that is stored in the monitoring database. The default value is set to archive nothing after zero days. The options are: After N days. If you select Archive Data or Delete Data, then you must specify a retention period, which determines the number of days during which performance data remains in the tables of the online monitoring system. Performance data that is older than the specified value gets archived or deleted (depending on your selection) when the archive program runs. Delete Data. If this option is select, the next time the archive program runs, the program deletes performance history data that is older than the retention period. Archive Data. If this option is selected, the next time the archive program runs, the program archives performance history data that is older than the retention period. The archive program moves history tables (PSPMTRANSHIST and PSPMEVENTHIST) to the archive tables (PSPMTRANSARCH and PSPMEVENTARCH). Archive Nothing. Disables performance data archiving for this monitored system. Delete System. If this option is selected, the next time the archive program runs, it deletes the system definition and its performance data. Keep in mind that deleting a system does not prevent the monitored system from continuing to send performance data. You must set the Monitor URL value on the monitored system to NONE to disable monitoring. Note. If the Archive: Clear PMUs & Events option is enabled in the Global Administration page, the archive settings are ignored. See Schedule Archive section.
Allow Performance Trace	Enables authorized users who are connected to this monitored system to launch the Performance Trace Console. By default, this option is enabled on a new monitored system unless you adjust the system defaults on the System Defaults page. See Working with the Performance Trace.
PMU Timeout	Indicates the interval in which an open PMU is considered timed out. PMU timeouts are measured in days. The PMU Timeout value can't be set to zero. After the specified interval, the system assumes that a PMU that has not finished encountered an error and should no longer be considered open. The PeopleSoft Application Engine reaper program (PSPM_REAPER) moves timed out PMUs from the current PMU tables to the history PMU tables and sets the status to Reaper Timed Out. Note. When a PMU starts, the application server agents specify an override timeout that is equal to the Tuxedo service timeout of the domain. In such cases, the reaper program uses the override value instead of the PMU Timeout that is specified here.
Agent Event Sample Rate	Specifies the rate (in seconds) that agents collect resource metrics, such as CPU usage. The default is 300 seconds (five minutes). To disable event sampling, set the value to zero. Note. Smaller sampling rate intervals will provide more frequent updates of machine and process resource utilization on your monitored systems. However, consider that by decreasing the sampling rate interval, you increase the volume of data that is sent to and stored in the performance database. This increases the overall impact of performance monitoring.
Agent Buffering Interval	Specifies the rate (in seconds) at which an agent sends performance data to the monitoring system. This value can't be set to zero. A smaller interval decreases the delay between the time when the monitored system generates performance data and the time that it is displayed on the monitoring system. Larger intervals enable more efficient transmission of performance data across the network because the system can consolidate the data into packets. The larger the interval, the greater the Agent Max Buffer size should be set. The default is 10 seconds.
Agent PMU Sample Rate	Enables you to reduce the amount of PMU data that is generated by monitoring just 1 of every N server trips. Sampling does not affect PMUs that are initiated in a performance trace. See Configuring Performance Monitoring Sampling Rate.
Agent Heartbeat Interval	This is the interval at which agents that do not have any performance data to report or that are in standby mode connect to the monitor servlet to be notified of any configuration changes. If agents post data to the monitoring system before this interval expires, they will be notified of any configuration changes and the timer will be reset. The lower the number, the greater the responsiveness of the agents to configuration changes, but the greater the network traffic. This value can't be set to zero. The default value is 300.
Agent Max Buffer Size	Determines the maximum size of the buffer containing performance data. This enables you to cap the amount of data that is being stored by the agent on the monitored system and the amount of data that is sent across your network. If this limit is reached, the agent automatically discards new performance data until the current data has been posted to the monitor servlet. The agent posts an alarm to the monitoring if the buffer size threshold is exceeded. The default is 4194304 bytes (4 MB). The minimum must be 10240 bytes (10 KB).
Save and Notify Agents	Notifies the monitor servlet of configuration changes made on this page. First, the system saves the changes to the database. Notification of the monitor servlets occurs through the PeopleSoft Integration Broker gateway. The monitor servlet notifies the agents of changes when the agents next communicate with the monitor. A delay occurs in publishing changes to the monitored systems. The maximum delay is the agent heartbeat interval. Note. The Integration Broker Gateway must be configured correctly; otherwise, you will see an error message indicating that the agents were not notified of system changes.
Versions	Enables you to view a history of the PeopleTools versions that are installed on a monitored system. The Tools Release column reveals the version numbers. The Valid From columns indicate the date and time that an agent on a particular version first communicated with the monitoring system. The Valid To columns indicate the date and time that an agent on a particular version last communicated with the monitoring system.

PPMI URL	The PPMI URL that is stored in the monitoring system's database is used by PSPPMSRV processes to locate the PPMI servlet with which to register. The format of the URL is: http[s]://<host[:port]>/ppmi/<site_name>/ For example, http://server1.peoplesoft.com/ppmi/ps/ After you specify this URL value, it is stored in the URL catalog under the ID PPM_PPMI. Note. If you select HTTPS, then the PSPPMSRVs use SSL encryption when sending the PPMI user ID and password to the PPMI servlet, but performance data sent from the PPMI servlet to PSPPMSRV is not encrypted. Because the data is not encrypted, the PSPPMSRV and the monitor servlet should reside in a secure network environment. Note. Use the Ping Test button to verify that you have entered a valid URL and that the URL is available.
PPMI User ID	The PSPPMSRV server processes pass this user ID and password to the PPMI servlet. The servlet verifies that the user ID and password are valid, and that the user has permission to access the PPMI servlet. The user ID that you specify must have a permission list with Performance Monitor PPMI Access selected in its PeopleTools permissions. PeopleTools recommends using the PTPMCLNT permission list, which is shipped expressly for this purpose. Note. The PPMI User ID and PPMI Password values are required. See Performance Monitor Security Considerations.
PPMI Password	The password associated with the PPMI user ID.
Archive: Clear PMUs & Events	Indicates to the archive program to delete all of the performance history data that is currently stored in the monitoring database. This is in the form of an unqualified DELETE on the history tables, or for those platforms for which it is supported, the tables are truncated. Note. If you select this option, the delivered archive program deletes all of the performance history data for every monitored system. Note. Deleting and truncating performance data may cause the current user count to appear artificially low. The system bases the count on events that are found in the PSPMEVENTHIST table, and rows from this table may be deleted during the archive process. Note. This option overrides any archive mode option that is set on the System Definition page. See Modifying System Definitions.
Collator Row Limit	Limits the amount of data that can be inserted into the Performance Monitor tables. Collators (PSPPMSRVs) periodically count the number of rows in each of the performance tables. If the total count of rows in PSPMTRANSHIST, PSPMTRANSCURR, and PSPMEVENTHIST is higher than this value, the PSPPMSRV does not insert any more rows into these tables until the number of rows deleted (by the archive program, the reaper program, manual intervention, or any combination of the three) brings the row count below this limit. If you set this value to 0, the PSPPMSRVs do not check for a row limit. Note. If the row limit is reached, the System Performance page will report that the agents on the monitored system have stale agent data.
Search Row Limit	Limits the number of rows that are returned and displayed in searches that are initiated from Performance Monitor pages. The system imposes this limit on all users who access the monitoring system.
Performance Monitor Cluster	To provide failover and scalability, performance monitor servlets on multiple web servers can be configured as a cluster. Entering the cluster information in the Performance Monitor Cluster grid enables the load-balanced monitor and PPMI servlets to share client registration information so that PSPPMSRV instances need not be aware of the cluster configuration. The format of the cluster member URL is http://host[:port]/ppmi/<site_name>/, where the host name is the actual web server machine. Click Save and Notify Cluster to notify the cluster if you have added or removed a cluster member. Click Ping Test to verify that you have entered a valid URL and that the URL is available. See "Setting up Monitoring Clusters" below.