Queue

How it works#

The Queue holds entities that have arrived but cannot be served yet. It models anything with a bounded waiting area: a thread pool's work queue, a connection pool, a message broker's backlog, a line of customers at a counter.

A queue is passive — it never initiates anything, it only answers the components on either side of it. Entities leave in the order they arrived. When a consumer is already waiting the moment an entity arrives, the entity is handed straight over without being stored: an empty queue costs nothing and adds no delay.

When the queue is full, the producer is held rather than losing its entity, and released as soon as a slot frees up. This is what makes back-pressure visible in a model: a server upstream of a full queue goes blocked, stops taking new work, and the congestion propagates backwards until the generator starts recording rejections.

A queue must have an incoming connection; the simulation will not start while one is missing. Its outgoing side is optional, but nothing drains a queue by itself — a queue with no consumer simply fills to capacity.

Settings#

Capacityentities — default 10

The maximum number of entities the queue holds. Capacity can be changed while the simulation runs: lowering it drops the entities that no longer fit, raising it immediately admits producers that were waiting for space.

Exit RuleFIFO

The order in which entities leave the queue. First-in-first-out is available today; LIFO is planned.

Overflow PolicyBlocking (Wait)

What happens when an entity arrives at a full queue. Blocking makes the producer wait for space instead of losing the entity — it is released as soon as a slot frees up, or rejected when its own wait timeout expires. Overwrite Oldest and Drop Newest are planned.

Capacity is the dial you will reach for most, and it can be changed mid-run. Watch what that trade actually buys: a bigger buffer absorbs bursts and postpones rejections, but the entities it holds are waiting, so the time entities spend in the system stretches. Sizing a queue is choosing between dropping work and delaying it.

Statistics#

• Queue length over time — how many entities are waiting as the simulation runs. Good for spotting bursts and how long the queue takes to recover from one.
• Queue size probability — the share of time the queue spent at each length. This is the one to judge sizing by: a distribution pressed up against the capacity limit means the buffer is the bottleneck, while one sitting at zero means it is larger than it needs to be.