# SAP Dialog Work Process Estimator

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

## Short answer

Estimate dialog work processes from named users, concurrency, requests per minute and average dialog processing time.

## Category

sap

## Erp

SAP ECC and S/4HANA

## Audience

- SAP Basis administrator
- SAP performance analyst

## Tool

**Kind:** calculator

**Inputs:**

#### Named users

**Key:** named

**Type:** number

**Default:** 2000

**Min:** 0

**Step:** 50

**Unit:** users

#### Concurrently active users at peak

**Key:** conc_pct

**Type:** slider

**Default:** 15

**Min:** 1

**Max:** 60

**Step:** 1

**Unit:** %

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

#### Dialog steps per active user

**Key:** req_min

**Type:** number

**Default:** 3

**Min:** 0

**Step:** 0.5

**Unit:** per min

**Help:** Screen interactions per minute, from workload statistics.

#### Average dialog processing time

**Key:** resp_ms

**Type:** slider

**Default:** 400

**Min:** 100

**Max:** 2000

**Step:** 50

**Unit:** ms

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

#### Burst factor over hourly average

**Key:** peak

**Type:** number

**Default:** 1.5

**Min:** 1

**Max:** 5

**Step:** 0.1

#### Target work process utilisation

**Key:** target_util

**Type:** slider

**Default:** 60

**Min:** 30

**Max:** 90

**Step:** 5

**Unit:** %

**Outputs:**

#### Concurrent active users

**Key:** conc

**Expr:** named * conc_pct / 100

**Format:** integer

#### Average dialog step rate

**Key:** rate

**Expr:** conc * req_min / 60

**Format:** decimal

**Description:** Dialog steps per second.

#### Burst step rate

**Key:** peak_rate

**Expr:** rate * peak

**Format:** decimal

#### Average busy work processes

**Key:** busy

**Expr:** peak_rate * resp_ms / 1000

**Format:** decimal

**Description:** Little's law: arrival rate times service time.

#### Dialog work processes needed

**Key:** wp_need

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

**Format:** integer

**Primary:** true

#### Named users per work process

**Key:** per_wp_users

**Expr:** named / wp_need

**Format:** integer

**Primary:** true

**Chart:**

#### Dialog work processes needed vs processing time (ms)

**Type:** line

**X:** resp_ms

**From:** 100

**To:** 2000

**Steps:** 20

**Series:**

- wp_need

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

## Content

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

**Sections:**

#### How to use it

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

**Bullets:**

- 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

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

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

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

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

**Faq:**

#### Which profile parameter controls this?

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

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

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

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

## Search terms

sap dialog work process calculation, how many dialog work processes sap, sap rdisp/wp_no_dia sizing, sap concurrent users estimate, sap dialog response time capacity, sap work process queue sizing, sap application server sizing users, sap dialog workload estimate

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