Server

How it works#

The Server pulls an entity from its source, holds it for a service time, then pushes it downstream. It stands for a request handler, a worker thread, a database, a cashier — anything that can only be busy with one thing at a time.

That last point matters when you size a system: one server serves one entity at a time. To model a pool of N parallel workers, place N servers behind the same queue — each pulls independently, so the queue is drained by whichever server frees up first.

Service times are exponentially distributed around the rate you set, so individual jobs vary widely even though the average is fixed. Compare that rate with the arrival rate feeding it to get the utilisation of the system: as the two approach each other, queue lengths and waiting times climb sharply — long before utilisation reaches 100%.

A server must have an incoming connection. Its outgoing side is optional: with nothing connected, entities it finishes count as completed and leave the model, which makes the last server in a chain a natural exit point. With several connections on either side, it alternates round-robin between them.

Settings#

Service Rateentities per second — default 3

The mean rate μ at which the server completes work. Each service time is drawn from an exponential distribution with mean 1/μ, so most jobs are short and a few take much longer — the behaviour real request handlers usually show.

Wait Timeoutplanned

Shown greyed out. Nothing waits today: a finished entity the next queue has no room for is dropped on the spot, and the server moves on to its next job.

The service rate can be changed while the simulation runs — the fastest way to see how much headroom a stage actually needs.

Server states#

A server is always in one of three states, and which one it spends its time in tells you what to fix.

Waiting

Idle — asking its source for an entity and getting nothing back.

Busy

Serving an entity for the duration of its service time.

Blocked

Finished serving and handing the entity downstream. Since a full queue now refuses at once, this takes no time and the state reads zero; it will matter again once a producer can wait for space.

Mostly waiting means the server is starved and the bottleneck is upstream. Mostly busy means it is the bottleneck. If the server is busy but its dropped rate is climbing, the bottleneck is downstream: the queue after it is full, and adding capacity here would change nothing.

Statistics#

• Server state probability — the share of time spent waiting, busy and blocked. This single chart is usually enough to locate the bottleneck in a chain of servers.
• Entity rate — completed and dropped entities per second over time. Entities are dropped here when the server finishes work the queue after it has no room for.
• After a batch run, the share of time busy, waiting and blocked, and the completed and dropped rates, each as a mean per run with a confidence interval.