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 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 the Exit Rule sets — unless you change it, 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 Overflow Policy decides what becomes of an arriving entity. Unless you change it, the entity waits outside the queue for as long as its sender's Wait Timeout allows, and is dropped if no room appears in that time. The other two policies never keep anything waiting: the queue drops an entity of its own choosing instead. A full queue is where a model loses work, and the capacity is what decides how much.

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 and stays full.

Settings#

Capacityentities — default 10

The most entities the queue holds. It can be changed mid-run. Raising it admits entities that are waiting outside. Lowering it below what the queue holds drops nothing: the queue keeps its entities and admits no more until it has drained below the new capacity.

Exit Ruledefault FIFO

The order in which entities leave the queue. FIFO — first in, first out: the entity that arrived first leaves first. LIFO — last in, first out: the newest arrival leaves first.

Overflow Policydefault NO_OVERRIDE

What a full queue does with an arriving entity: NO_OVERRIDE, Overwrite Oldest or Drop Newest.

Overflow policies

NO_OVERRIDE

Nothing already queued is dropped. The arriving entity waits outside the queue for as long as its sender's Wait Timeout allows, and leaves the model if no room appears. The drop is counted against the sender, not the queue.

Overwrite Oldest

The queue drops the entity that has waited longest and takes the arriving one, so its length does not change. Oldest always means first to arrive, whatever the Exit Rule. The drop is counted against the queue.

Drop Newest

The queue takes the arriving entity and drops it. The drop is counted against the queue.

Every drop, whoever it is counted against, also counts in the model-wide dropped total. The Exit Rule and the Overflow Policy are fixed for the length of a run.

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 cuts the drops, 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 the queue held on average over the chart window, plotted as the simulation runs. Good for spotting bursts and how long the queue takes to recover from one. A line that sits at the capacity means the buffer is the bottleneck; one that sits at zero means it is larger than it needs to be.
• Dropped entities — the rate at which the queue itself drops entities, plotted as the simulation runs. It is zero under NO_OVERRIDE, because those drops belong to the sender.
• Mean length and Dropped — after a batch run, the time-average length and the entities the queue dropped per second, each as a mean per run with a confidence interval.