How far one engine goes

A worker calls a function another worker hosts. The call goes to the engine, the engine routes it to the host, and the answer comes back the same way: four WebSocket frames per call.

Callers keep more and more calls in flight, from 1 to 2,048. Throughput grows while the engine has CPU to spare, up to a peak: the size’s capacity.

Every function is observable. Here each called function gains 1 to 64 observers without a filter, so every call activates all of them, fire-and-forget, while 64 callers keep calling.

An activation is a call the engine makes on its own, and it costs about as much as one. So the engine splits the same CPU between the calls and their activations: the more observers per call, the fewer calls fit.

A source like cron or a database hands each event to the observers that asked for it, with obs.emit(). We offer a steady rate, from 1k to 500k events a second over 16 observers, and count what arrives.

Up to some rate, everything does. That rate is the size’s sustained capacity, and past it the engine does not fall over: it delivers what it can and drops the rest, counted.

Observers usually filter: a cron expression, a table, a tenant. Here one function has 16 to 4,000 observers, each filtering on a different value, and every call matches exactly one of them.

What grows is the filtering, not the deliveries: the engine checks every observer’s filter on every call to the function.

The engine’s resident memory at rest as idle workers connect and observers pile up. Each VM size’s memory cap is drawn across: where a line would cross it, that size runs out.

Fits: the size’s cap, less the engine at rest, over the measured cost of one. Real workers register more functions, and real observers carry bigger filters.

Observers whose target takes 20 ms, behind calls that come far faster. Each observer runs 64 activations at a time and queues up to 1,024 more; past that, events are dropped and counted.

The calls hold at 64 in flight while slow observers are added: 4, 64, 256. Every one of them keeps a full queue. A queued event is held once, however many observers wait on it, and all the queues together are capped at 64 MiB of events.

A worker calling a function it hosts runs it in its own process. The engine hears about such a call only when an observer’s filter matches it, in batched reports.

16 tasks in one worker call its own function as fast as they can: unobserved, with an observer matching 1% of the calls, and with one matching them all.

Everything on this page comes from one open-source tool that runs the same way on your machine as in CI, and every number links back to the run that produced it.