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.

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, but unable to hand the entity downstream because the next component has no room. A blocked server cannot start new work, which is how congestion travels backwards through a model.

Mostly waiting means the server is starved and the bottleneck is upstream. Mostly busy means it is the bottleneck. Mostly blocked means the bottleneck is downstream and this server is being held up by it — 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 — processed and dropped entities per second over time. Entities are dropped here when the server finishes work it cannot hand on before its wait expires.