# SAP Dialog Work Process Sizing Calculator for ABAP Systems

> Source: https://netray.co/tools/abap-dialog-work-process-sizing-calculator
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: Free Tools

## Short answer

Turn active users, dialog steps per hour and work process time into the number of dialog work processes needed at peak.

## Category

sap

## Erp

SAP ECC / S/4HANA

## Audience

- SAP Basis administrator
- ABAP developer
- SAP architect

## Tool

**Kind:** calculator

**Inputs:**

#### Active dialog users

**Key:** users

**Type:** number

**Default:** 400

**Min:** 1

**Step:** 25

**Unit:** users

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

#### Dialog steps per user per hour

**Key:** steps_hr

**Type:** number

**Default:** 60

**Min:** 1

**Step:** 5

**Unit:** steps

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

#### Work process occupancy per step

**Key:** wp_ms

**Type:** number

**Default:** 400

**Min:** 10

**Step:** 25

**Unit:** ms

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

#### Peak-to-average factor

**Key:** peak

**Type:** number

**Default:** 1.5

**Min:** 1

**Step:** 0.1

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

#### Target peak utilisation

**Key:** target_util

**Type:** slider

**Default:** 60

**Min:** 30

**Max:** 90

**Step:** 5

**Unit:** %

**Help:** Keep headroom so queues stay short.

#### Configured dialog work processes

**Key:** current_wp

**Type:** number

**Default:** 20

**Min:** 1

**Step:** 1

**Unit:** WP

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

**Outputs:**

#### Average steps per second

**Key:** steps_sec

**Expr:** users * steps_hr / 3600

**Format:** decimal

#### Average busy processes

**Key:** busy_avg

**Expr:** steps_sec * wp_ms / 1000

**Format:** decimal

**Description:** Offered load, from Little's law.

#### Peak busy processes

**Key:** busy_peak

**Expr:** busy_avg * peak

**Format:** decimal

#### Dialog work processes needed

**Key:** wp_needed

**Expr:** ceil(busy_peak / (target_util / 100))

**Format:** integer

**Primary:** true

#### Peak utilisation with current setup

**Key:** util_now

**Expr:** busy_peak / current_wp * 100

**Format:** percent

**Primary:** true

#### Processes to add (negative is surplus)

**Key:** gap

**Expr:** wp_needed - current_wp

**Format:** integer

**Chart:**

#### Dialog work processes needed by active users

**Type:** line

**X:** users

**From:** 50

**To:** 2000

**Steps:** 30

**Series:**

- wp_needed

**Disclaimer:** 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.

## Content

**Intro:** 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.

**Sections:**

#### How to use it

**Body:** 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.

**Bullets:**

- 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

**Body:** 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.

**Bullets:**

- 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

**Body:** 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.

**Bullets:**

- 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

**Cta:** 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.

**Faq:**

#### Where is the number of dialog work processes set?

**Answer:** 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?

**Answer:** 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?

**Answer:** 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?

**Answer:** 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.

## Search terms

sap dialog work process sizing, how many dialog work processes, rdisp/wp_no_dia sizing, sap work process calculator, sap application server sizing, sm50 work process utilization, sap dialog step response time, sap concurrent users sizing

---
Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json