SAPFree calculatorPDF, Excel, Word exportSAP ECC / S/4HANA

SAP Dialog Work Process Sizing Calculator for ABAP Systems

Too few dialog work processes and users queue; too many and you burn memory for nothing. This calculator gives a defensible first number from the workload you can read in your own statistics, and shows how it scales with users.

Your numbers

users

Users actively working at the peak hour, not named users.

steps

A step is one screen round trip. Check ST03N workload statistics for your average.

ms

Time a work process is held per step, roughly response time minus front-end and queue time.

How much busier the worst quarter hour is compared with the hour average.

60 %

Keep headroom so queues stay short.

WP

Your current rdisp/wp_no_dia value per instance, summed over instances.

Your results

Dialog work processes needed
7
Peak utilisation with current setup
20%
Average steps per second
6.6667
Average busy processes
2.6667
Offered load, from Little's law.
Peak busy processes
4
Processes to add (negative is surplus)
-13

A first-pass estimate based on Little's law. SAP sizing for a new landscape should use Quick Sizer and your Basis team. Memory, CPU and database limits can bind before work process count.

Save results:

Dialog work processes needed by active users

Sweeps Active dialog users from 50 to 2000, holding your other inputs fixed.

Want a second pair of eyes on your sizing?

Optional: send your ST03N figures and we will sanity check the work process and memory assumptions.

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

How to use it

Open ST03N, pick the peak period and read dialog steps per hour and average response components. Divide steps by active users to get steps per user per hour. Work process occupancy is the part of the response time spent inside the work process, so subtract front-end and wait time from the total response. Enter your configured work processes to see current peak utilisation, or leave the value and read the needed count. The chart shows how the requirement grows with the user base.

  • Use peak-hour numbers from ST03N, not daily averages
  • Do not count idle logged-in sessions
  • Include all instances when summing configured processes

Method: offered load

Average busy processes equal arrival rate times service time, which is Little's law. The arrival rate is users times steps per hour divided by 3,600. The service time is the occupancy per step in seconds. Multiply by a peak factor, then divide by the utilisation you want to run at. Targeting 60 percent leaves room for bursts so the dispatcher queue stays short. A system running above 80 percent in the peak quarter hour will show queueing in SM66 and rising wait times in ST03N.

  • Busy = steps per second x occupancy in seconds
  • Needed = ceil(peak busy / target utilisation)
  • Check queue and wait time, not just utilisation

Reading the result

If the result is above your configured count, look first at the occupancy time before adding processes. A few slow custom transactions can hold work processes for seconds each and distort the whole system. Fixing them is cheaper than adding processes and more memory. Also check that the extra processes fit within the instance memory, since each can use extended and heap memory. Separate dialog from background and update processes in your thinking: this tool sizes dialog only.

  • Find long-running dialog steps in ST03N top lists
  • Verify memory per instance before raising rdisp/wp_no_dia
  • Size update and background processes separately

Frequently Asked Questions

Where is the number of dialog work processes set?

In the instance profile with the parameter rdisp/wp_no_dia, together with the other work process types. Changing it needs an instance restart unless you use dynamic work process switching for some types.

What utilisation should I aim for?

Many teams aim for roughly 50 to 70 percent at peak. Above that, small bursts create queues and visible wait time. The right figure depends on how bursty your workload is.

Is this the same as SAP Quick Sizer?

No. Quick Sizer sizes a landscape from business volumes and is the proper tool for new projects. This calculator uses measured statistics from a running system for a quick check.

Why do more work processes sometimes not help?

If the bottleneck is the database, locks or a single slow transaction, extra processes just wait in parallel. Memory pressure can also get worse. Find the cause in ST03N and ST05 first.

If response time complaints point at custom code, Netray can help profile the heaviest transactions and reduce their work process time rather than just adding hardware.

Talk to an ExpertExplore More Free Tools

Related Tools

SAP

ABAP Background Job Runtime and Batch Window Calculator

Estimate batch job duration from record volume, per-record time, commit frequency and parallel processing, and test it against your batch window.

SAP

ABAP FOR ALL ENTRIES vs SELECT in LOOP Runtime Calculator

Model the database cost of a SELECT inside a LOOP against FOR ALL ENTRIES and see how the gap grows with the driver table size.

SAP

ABAP Internal Table Memory Size Calculator

Estimate the memory an internal table needs, check it against a session limit and find the safe row count before you hit a short dump.

SAP

SAP Number Range Exhaustion Calculator

Forecast how many years remain in a number range interval, including growth and numbers lost to buffering after restarts.

More SAP tools

See all
Back to All Tools