OracleFree calculatorPDF, Excel, Word exportOracle E-Business Suite

Oracle EBS Concurrent Manager Queue Wait Calculator

Most concurrent manager complaints come down to one question: how many target processes does this queue need? This calculator treats the manager as a multi-server queue and shows utilization and expected wait for your arrival rate and runtime.

Your numbers

per hour

Average arrival rate during the busy window, not the daily average.

minutes

Mean run time of requests handled by this manager (Running phase only).

20 processes

The Processes value on the manager definition in Concurrent > Manager > Define.

Your results

Manager utilization
80%
Above 100% the queue grows without limit.
Average wait in Pending/Normal
0.3 min
Approximate mean queue wait, capped at 120 minutes when the queue is unstable.
Offered load
16
Average number of processes kept busy, in erlangs.
Average turnaround
4.3 min
Wait plus runtime, what the submitter experiences.

Uses the Sakasegawa approximation for an M/M/c queue. Real workloads have bursty arrivals, specialization rules and incompatibility rules, so treat the result as a sizing guide and confirm with FND_CONCURRENT_REQUESTS history.

Save results:

Average queue wait vs target processes

Sweeps Target processes from 10 to 40, holding your other inputs fixed.

Concurrent queue review

Send us a month of request history summary and we will point out which queues look undersized or mixed.

Optional. The tool and every export work without this. No spam.

How to use it

Pick one queue at a time, for example the Standard Manager or a custom manager for a heavy program. Enter the number of requests per hour that reach that queue during the busy window and the average runtime in minutes. You can pull both from FND_CONCURRENT_REQUESTS using actual_start_date, actual_completion_date and requested_start_date. Then move the processes slider and watch utilization and wait. The chart sweeps the process count so you can see where the curve flattens.

  • Use the month-end or payroll peak, not a quiet Tuesday.
  • Separate long running programs into their own manager using specialization rules.
  • Remember that each process costs database sessions and memory.

The method behind the numbers

Offered load is arrival rate times service time. Utilization is offered load divided by the number of servers. For queue wait the tool uses the Sakasegawa approximation for M/M/c systems: Wq = rho^(sqrt(2(c+1)) - 1) / (c (1 - rho)) times the service time, where c is the process count and rho the utilization. It is accurate to a few percent for moderate loads and shows the characteristic cliff as utilization approaches 100%. A queue at 70 to 80% utilization usually keeps waits small, while 95% produces long waits even though the manager looks nearly idle on average.

Reading the result and common mistakes

If wait is small but users still see Pending/Normal, check for incompatibility rules, a Conflict Resolution Manager backlog or requests scheduled in the future. If the tool shows an unstable queue, adding processes is the first lever, but also look at whether a few long reports are blocking many short jobs. Another common mistake is averaging runtimes across very different programs. A mix of 1 minute jobs and 3 hour jobs is better modeled as two queues.

  • Do not confuse Pending/Standby (incompatibility) with Pending/Normal (no free process).
  • Cache size should be at least twice the process count for busy queues.
  • Re-check after adding processes, since database load may become the limit.

Frequently Asked Questions

How many processes should the Standard Manager have?

There is no universal number. Size it from your busy-window arrival rate and mean runtime, aim for roughly 70 to 80% utilization, then confirm against database CPU and session limits. Moving long programs to their own manager often helps more than adding processes.

Does this model incompatibility rules?

No. Incompatibility rules and the Conflict Resolution Manager add waiting that is independent of process count. If requests sit in Pending/Standby, review the program incompatibilities instead of raising processes.

Why does wait jump sharply near 100% utilization?

Queueing theory shows wait grows very quickly as utilization approaches 100%, because any burst of arrivals has no spare capacity to absorb it. Small increases in processes near that point can cut waits dramatically.

Where do I get arrival rate and runtime?

Query FND_CONCURRENT_REQUESTS joined to FND_CONCURRENT_PROGRAMS for a period, count requests per hour by queue and average the difference between actual completion and actual start dates for completed requests.

If you want queue backlog and runtime trends pulled straight from your EBS tables and explained in plain language, we can set that up on-prem so no data leaves your network.

Talk to an ExpertExplore More Free Tools

Related Tools

Oracle

Oracle EBS Concurrent Program Load Planner Worksheet

List your scheduled concurrent programs with runtime and frequency, then see total busy minutes and the processes needed to carry the load.

Oracle

Oracle EBS Database Growth Forecast Calculator

Project EBS database size from monthly growth and a one-time purge, and see how many months of storage headroom remain.

Oracle

Oracle EBS Maintenance Window and Backup Time Calculator

Work out how long the outage needs to be, including a backup, the work itself, validation and a contingency buffer, and how long a rollback restore would take.

Oracle

Oracle EBS AP Invoices on Hold SQL Generator

Fill in operating unit, lookback days and optional hold code to get ready-to-run SQL for unreleased holds in Oracle Payables.

More Oracle tools

See all
Back to All Tools