Has anyone got any views on multi-threading to improve payroll performance. We are currently running on 4 threads but are looking to increase this. I have heard that depending on the infrastructure there is an optimum number above which you don't really gain anything.

Any info greatly received.

Delboy

Hi Delboy,

We're currently running on 8 threads here and it has meant our payroll processesing, especially in the area of retropay, is much quicker.

Marina

Thanks Marina,

I will give it a try.

Delboy

An awful lot depends on the hardware / OS platform that your DB is running on. There is no magic "one size fits all" when i comes to performance tuning / thread analysis etc. I guess this is why top-notch performance specialists charge such high fees for their services.

Certainly in the early days, the rule of thumb used to be max threads = 2 x number of CPU's on your server. Once you went past this number the overhead costs of time sharing /slicing between the threads was more than the gain you got by the larger number of threads.

Of course a lot also depends on what other loading is on your machine at payroll runtime. A well-known National Health Service tend to allocate processing to payroll runs out-of core hours (ie from 4pm through to 6am etc) in the assumption that there would be fewer people using the system then. This is a gross generalisation of the set-up there, but the basic premise is sound.

I would suspect you will need to experiment to see what number gives your a reasonable run time.

Hoe this helps

Regards

Barry

Thanks Baz,

That is helpful.

Cheers,

Delboy

you also may need to considere additional RAM...
Regards,
Jairo

Basically agree with Baz in terms of the max 2 Threads per CPU

You really need to identify what gains you want/need. The improvement is approximatley linear If 4 threads was 1 hr, 8 Threads would be 30 min..and so on although this is not absolute.

It is also highly likely you may have to carry out some other SQL tuning / Database tuning as well, as you may find you start to getting locking of records

The only way to find out is to try it and see.

I seem to remember there was a big exercise around this at a well-known custodian of the nation's health up at Warwick about 8 or 9 years ago now...

I recall at the time there was a paper or similar, put together by Andy McGhee, which set out the things to consider when multi-threading payroll (and other processes). I am struggling to remember what I did yesterday, so you can guess how much of the content of that I retained. It might however be beneficial to have a root around in Metalink for it, or failing that try tapping the man up to see if he'll point you in its direction?

I have a somewhat sketchy image of having some pay action parameters to set, as well as ensuring that relevant tables are enabled for multi-threading *right from the outset*, e.g. PAY_ASSIGNMENT_ACTIONS, PAY_RUN_RESULTS, PAY_RUN_RESULT_VALUES etc - again, the details of that have escaped me all too easily.

Sorry, not a huge amount of use I admit.

What's yesterday ??!!

Historically you did have to enable tables for mult-threading nowadays I am not sure you have to do it.

There are multitiude pay_actiona_parameters you can set

THREADS is the main one which tells apps how many threads you want to use.

Other paramters are used for error handling / tuning.

It can be worth setting LOW_VOLUME to 'Yes' irrespective of the size of the DB as it actually relates to the sql that is running I beleive is still 'Rule' for many of the main payroll processes

There a multitude of papers rolling around on the Parameters

Despite Oracle's best efforts to Deprecate RULE it is still used in a lot of the core payroll (and HR) processes