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

SAP Dialog Work Process Estimator

Too few dialog work processes cause queueing and slow screens, too many waste memory. This estimator applies a simple queueing relationship to your own user and request numbers so you can see how the answer moves with processing time.

Your numbers

Named users

users

Concurrently active users at peak

15 %

Users actively sending requests during the busiest hour, not logged on.

Dialog steps per active user

per min

Screen interactions per minute, from workload statistics.

Average dialog processing time

400 ms

CPU plus database time in the work process, not network or front end time.

Burst factor over hourly average

Target work process utilisation

60 %

Your results

Dialog work processes needed

Named users per work process

133

Concurrent active users

300

Average dialog step rate

Dialog steps per second.

Burst step rate

22.5

Average busy work processes

Little's law: arrival rate times service time.

Queueing estimate based on averages. Use SAP workload monitor (ST03N) statistics and SAP Quick Sizer for the official sizing, and validate with load tests for large changes.

Save results:

Dialog work processes needed vs processing time (ms)

Sweeps Average dialog processing time from 100 to 2000, holding your other inputs fixed.

Get a performance baseline review

Share your workload statistics summary for a short written opinion. Optional.

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

How to use it

Start with named users and the share who are actually working during your peak hour. Enter steps per active user per minute and the average dialog processing time from your workload statistics. Add a burst factor, since traffic is uneven within the hour, and choose a utilisation target. The result is the number of dialog work processes for one system and a rough users per process figure.

Take concurrency from measured peak data, not logged-on counts
Use processing time without front end and network time
Set the burst factor from the busiest five minutes
Size per application server when users are spread across several

The relationship

Little's law says the average number of busy servers equals the arrival rate multiplied by the average service time. Here arrival rate is concurrent users times steps per minute, divided by 60 and multiplied by the burst factor, and service time is the dialog processing time. Dividing the busy servers by the target utilisation leaves headroom so that queues stay short at peak, since queue length rises sharply as utilisation approaches 100 percent.

Worked example

2,000 named users at 15 percent concurrency gives 300 active users. At 3 steps per minute that is 15 steps per second, and with a burst factor of 1.5, 22.5. At 400 ms processing time the average busy count is 9 work processes. At 60 percent target utilisation you need 15. Move the processing time to 1,200 ms in the chart and the need triples, which shows why tuning slow transactions can matter more than adding processes.

Common mistakes

Many teams confuse logged-on users with active users and over-size by a large factor. Others use total response time from the front end, which includes network and rendering, and double count. Remember also that dialog work processes are only one resource: memory, roll and extended memory, and the database must keep up. A long running dialog step holds a work process, so check for custom reports run online that belong in batch.

Frequently Asked Questions

Which profile parameter controls this?

The number of dialog work processes is set by the instance profile parameter rdisp/wp_no_dia. Change it per application server with care, and confirm memory and operation mode settings, since a restart is generally needed.

Where do I get the inputs?

The workload monitor (ST03N) shows dialog steps, response time components and users by hour. Use a representative peak period such as month-end for finance, and take processing time as CPU plus database time.

Is this a replacement for Quick Sizer?

No. It is a quick sanity check for an existing system with measured data. Quick Sizer is the official sizing tool for new systems and major changes, and load testing is the best check for big projects.

What if my result is very large?

Check the processing time first. A few slow transactions can inflate the average. Splitting users across several application servers also changes the per-server number you actually configure.

Netray can help surface slow dialog steps and heavy online reports from workload statistics in a private, read-only assistant on your own infrastructure.

Talk to an Expert Explore More Free Tools

Related Tools

SAP

More SAP tools

See all

Back to All Tools