«

»

Apr 03

Print this Post

Global Payroll system tuning tips

The Global payroll calculation is a batch process and performance tuning is complex and very specific to each customer’s environment. I have consolidated some points which cover some technical and functional areas regarding the GP process tuning.

Technical side:

Check your hardware configuration if that is capable enough to take care of density of employees for which the payroll process is running.

Start looking from the root, i.e. Database. Configurations are environment specific, like in Oracle; you may wish to check with your DBA if the right parameters/option is/are there in init.ora file. For example, if some extra parameters have been included for tuning etc. Also, let be on the latest DB fix/patch for enhanced performance (until and unless there would be any specific issue to be on that).

First step is to Update Statistics. If it is not possible to update all statistics regularly due to DB/table size etc., you may choose specific GP tables (GP_RSLT_ERN_DED, GP_RSLT_ACUM etc…) which needs attention before any batch run.

Index plays a crucial role. Corrupt Index, missing Index on the tables accessed by payroll SQL statements can make payroll tremendously slow. Don’t loose any points for missing INDEX etc.

Analyse SQL statements in case of any issue(s) with GP processing. You/DBA may use a Performance Monitor utility.

Check with the administrator if the App server domain(s) is/are properly configured to take up the load/processing… memory used/available etc.

You can activate tracing on COBOL to find out the cause.

Consider archiving the old data. Making achieve strategy depends upon business to business. Release 9.0 is being delivered with Data Archive Manager for GP too.

— Process Scheduler:

There is no special/different configuration specifically mentioned for any module. As already mentioned, it depends on one’s environment/infrastructure.
However, below are couple of point you wish to look at.

1. Though, this is more to do with configuration of the same component, sometimes you may check accessibility of this with DB (zones etc. of DB machine and the machine where scheduler is running).

2. Check whether this has been configured properly to take up the desired processing load, machine resources etc. Have a dry run and check with admin to see the performance etc.

3. Load balancing plays an important role here. You may ask your admin to configure one scheduler DOMAIN specific for COBOLs. Say for example, there are two domains load balanced. What can be done is, make a new third domain specifically for COBOL and in those two earlier domains; configuration can be done not to
entertain any COBOL requests. By this way, all COBOL specific requests will be entertained by one domain.

4. There is something specific to module like ePay etc information on which you can find from the installation guides of specific tools release. Like, in ePay, When running the payslip report process, the ePay Application Engine process will cache the entire payslip report into memory. If Java is not allocated enough memory- the process will abend with error: java.lang.OutOfMemoryError. To increase the memory for Java edit the psprcs.cfg file of each process scheduler server intended to be used for payslip report generation. Under the [PSTOOLS] section in psprcs.cfg, modify the JVM configuration option to increase the memory allocated.

Functional side:

Needs to be current with updates and fixes.

SETUP: Simple/complex, rules etc…(Review the Pay, Absence and auto-generated accumulators, retro processing, historical rules etc…)

Paygroups: You may want to adjust the size of Paygroups setup– very large Paygroups have an impact on performance. You can process multiple Paygroups
within the same Pay Run ID — i.e., you can still pay all employees at one time (in one pay run) even if they are associated with a number of different Paygroups. The Single Check/Multiple Job feature can significantly impact performance; the degree of performance degradation will increase considerably with larger paygroups; performance can be improved by breaking the employee population into a number of smaller paygroups.

Pay Calc and Pay Confirm process by Pay Calendar entries (basically by PayGroup) and include restart logic. You do not want to go with “all or nothing” processing a single huge PayGroup; organize your employees into smaller Paygroups in order to create smaller “units” of work for both processing and restart in the payroll batch programs.

GP Streaming: As such, one process can only run on one CPU at any one time. Therefore, to reduce processing time, and to make full use of a multi-CPU machine it is necessary to run a number of processes in parallel. Streaming is the term that PeopleSoft uses to describe the act of breaking the set of employees for whom
Payroll is to be calculated into a number of subsets and processing each subset in a separately. Each of these processes can then be run in parallel. The ‘streaming’ facility is a part of the GP product delivered by PeopleSoft. Using it is not a matter of application customisation, but rather one of configuration.

NOTE: I have taken some points from metalink3.

Look for the docs on customer connection (now Metalink3):
Tuning and Administration (Admins)
GP Streaming (Functionals)


As always… comment(s)/suggestion(s) are always welcome…

Permanent link to this article: http://alokbhardwaj.com/oracle-peoplesoft/2009/04/03/global-payroll-system-tuning-tips/

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>