OpenEng Labs

Executor · Benchmarks

Performance you can hold it to.

Eight engineering benchmarks define how small, how fast, and how exact the Open Engineering Executor is. Each one below is stated with the conditions it is measured under.

Request early accessExecutor overview
oee · performance specifications8 of 8

  • NFR-BIN-01

    < 3.0 MB

    Supervisor binary overhead

  • NFR-LAT-01

    < 15 ms

    Startup overhead

  • NFR-RES-01

    < 6 MB RSS

    Supervisor footprint at run time

  • NFR-STP-01

    < 5 ms

    Immediate stop latency

  • NFR-CAP-01

    ≤ 2%

    Strict cap accuracy

  • NFR-SCL-01

    < 1 ms

    Load balancer overhead

  • NFR-SCL-02

    < 1 s

    Scale-out reaction

  • NFR-SEC-01

    1 byte

    Manifest and payload integrity

01 · 2 specifications

Footprint

What the supervisor adds to a binary, and what it costs while the workload runs.

  • NFR-BIN-01

    Supervisor binary overhead

    < 3.0 MB

    Added to each wrapped executable by the core supervisor; under 6.0 MB for the extended variant

    Specification
    Less than 3.0 MB of stripped static Rust supervisor overhead per wrapped executable for the core variant, and less than 6.0 MB for the extended variant (message brokers, webhook, auto-scaler, load balancer).
    Measured under
    Stripped static build of oee-stub, compiled with lto = "fat", codegen-units = 1 and panic = "abort" against musl on Linux and the static CRT on Windows. oee build always selects the smallest variant that satisfies the manifest.
  • NFR-RES-01

    Supervisor footprint at run time

    < 6 MB RSS

    Supervisor memory, at under 0.1% CPU, while polling an exit event every minute

    Specification
    Less than 6 MB RSS memory footprint and less than 0.1% CPU utilization at a 1-minute HTTP exit-event polling interval.
    Measured under
    Measured for the core variant with no load-balancer connections; proxied connections are budgeted separately by NFR-SCL-01.

02 · 2 specifications

Startup and stop

How much time the Executor adds when the binary starts, and how fast it ends a whole process tree.

  • NFR-LAT-01

    Startup overhead

    < 15 ms

    Warm startup overhead; under 350 ms on the first, cold run

    Specification
    Less than 15 ms of overhead for wrapped native Go and Rust binaries and for warm-cached Python and JVM workloads; under 350 ms on a first run with cold-cache extraction.
    Measured under
    Warm means the content-addressed runtime cache (default ~/.cache/oee/runtimes/<blake3-merkle-root>/, overridable with OEE_CACHE_DIR) already holds the verified runtime and application; cold means the first extraction of Segments 3 and 4.
  • NFR-STP-01

    Immediate stop latency

    < 5 ms

    From exit-event evaluation to a fully terminated tree of 50 worker processes

    Specification
    Under 5 ms from exit-event evaluation to complete process-tree termination in IMMEDIATE mode across 50 concurrent child worker processes.
    Measured under
    IMMEDIATE stop mode (the graceful signal and drain stages are skipped), 50 concurrent child worker processes in the guest tree.

03 · one specification

Cap enforcement

How exactly a strict CPU and memory cap holds.

  • NFR-CAP-01

    Strict cap accuracy

    ≤ 2%

    Maximum CPU overshoot over any 1-second window; memory never exceeds its cap

    Specification
    With kernel enforcement, measured CPU usage of the capped tree never exceeds the limit by more than 2% over any 1-second window, and memory usage never exceeds the limit at all. Percentage limits resolve to the exact documented values, for example 10% of 10 cores = 1.0 core.
    Measured under
    strict mode with a kernel-enforced hard limit: cgroups v2 cpu.max and memory.max (swap disabled, group OOM) on Linux, Job Object hard caps on Windows.

04 · 2 specifications

Scaling and load balancing

What the built-in load balancer adds per connection, and how quickly a new replica takes traffic.

  • NFR-SCL-01

    Load balancer overhead

    < 1 ms

    Added median latency per proxied connection; under 20 KB per idle connection

    Specification
    Less than 1 ms of added median latency per proxied connection on loopback, and less than 20 KB of supervisor memory per idle proxied connection in tcp mode.
    Measured under
    Built-in load balancer inside oee-stub, connections proxied on loopback; the memory figure applies to idle connections in tcp mode.
  • NFR-SCL-02

    Scale-out reaction

    < 1 s

    To launch a new replica; traffic reaches it within 100 ms of passing readiness

    Specification
    A new replica is launched within 1 s of the scale-out window elapsing, and receives traffic within 100 ms of passing readiness.
    Measured under
    Measured from the end of the configured scale_out_after window to replica launch, and from a passed readiness check (TCP connect or HTTP GET) to the first routed request.

05 · one specification

Integrity

What it takes for a modified binary to be rejected.

  • NFR-SEC-01

    Manifest and payload integrity

    1 byte

    Any single changed byte fails verification before the guest starts

    Specification
    Any byte modification to the oee-stub, the embedded oee.yaml policy, or the bundled runtime archive fails BLAKE3 and Ed25519 verification before guest execution begins.
    Measured under
    Verification of the 32-byte BLAKE3 Merkle root across Segments 1 to 4 and the 64-byte Ed25519 detached signature in the 128-byte OEE! footer, at every start.

Specification table

Every figure, its condition, and its identifier.

The identifiers are the non-functional requirement IDs of the Executor’s product specification.

  • NFR-BIN-01

    Metric
    Supervisor binary overhead
    Specification
    Less than 3.0 MB of stripped static Rust supervisor overhead per wrapped executable for the core variant, and less than 6.0 MB for the extended variant (message brokers, webhook, auto-scaler, load balancer).
    Measured under
    Stripped static build of oee-stub, compiled with lto = "fat", codegen-units = 1 and panic = "abort" against musl on Linux and the static CRT on Windows. oee build always selects the smallest variant that satisfies the manifest.

  • NFR-LAT-01

    Metric
    Startup overhead
    Specification
    Less than 15 ms of overhead for wrapped native Go and Rust binaries and for warm-cached Python and JVM workloads; under 350 ms on a first run with cold-cache extraction.
    Measured under
    Warm means the content-addressed runtime cache (default ~/.cache/oee/runtimes/<blake3-merkle-root>/, overridable with OEE_CACHE_DIR) already holds the verified runtime and application; cold means the first extraction of Segments 3 and 4.

  • NFR-RES-01

    Metric
    Supervisor footprint at run time
    Specification
    Less than 6 MB RSS memory footprint and less than 0.1% CPU utilization at a 1-minute HTTP exit-event polling interval.
    Measured under
    Measured for the core variant with no load-balancer connections; proxied connections are budgeted separately by NFR-SCL-01.

  • NFR-STP-01

    Metric
    Immediate stop latency
    Specification
    Under 5 ms from exit-event evaluation to complete process-tree termination in IMMEDIATE mode across 50 concurrent child worker processes.
    Measured under
    IMMEDIATE stop mode (the graceful signal and drain stages are skipped), 50 concurrent child worker processes in the guest tree.

  • NFR-CAP-01

    Metric
    Strict cap accuracy
    Specification
    With kernel enforcement, measured CPU usage of the capped tree never exceeds the limit by more than 2% over any 1-second window, and memory usage never exceeds the limit at all. Percentage limits resolve to the exact documented values, for example 10% of 10 cores = 1.0 core.
    Measured under
    strict mode with a kernel-enforced hard limit: cgroups v2 cpu.max and memory.max (swap disabled, group OOM) on Linux, Job Object hard caps on Windows.

  • NFR-SCL-01

    Metric
    Load balancer overhead
    Specification
    Less than 1 ms of added median latency per proxied connection on loopback, and less than 20 KB of supervisor memory per idle proxied connection in tcp mode.
    Measured under
    Built-in load balancer inside oee-stub, connections proxied on loopback; the memory figure applies to idle connections in tcp mode.

  • NFR-SCL-02

    Metric
    Scale-out reaction
    Specification
    A new replica is launched within 1 s of the scale-out window elapsing, and receives traffic within 100 ms of passing readiness.
    Measured under
    Measured from the end of the configured scale_out_after window to replica launch, and from a passed readiness check (TCP connect or HTTP GET) to the first routed request.

  • NFR-SEC-01

    Metric
    Manifest and payload integrity
    Specification
    Any byte modification to the oee-stub, the embedded oee.yaml policy, or the bundled runtime archive fails BLAKE3 and Ed25519 verification before guest execution begins.
    Measured under
    Verification of the 32-byte BLAKE3 Merkle root across Segments 1 to 4 and the 64-byte Ed25519 detached signature in the 128-byte OEE! footer, at every start.

Sizes and resolutions

The other numbers that shape a binary.

Segment sizes and cap resolutions from the binary layout, the runtime matrix, and the capping specification.

  • ~2.2 MB

    The oee-stub supervisor segment (ELF, PE, or Mach-O) at the head of every binary

  • 128 B

    The fixed OEE! footer: segment offsets and sizes, a 32-byte BLAKE3 Merkle root, a 64-byte Ed25519 signature, and the magic trailer

  • 0 B

    Runtime segment for native Go, Rust, C, and C++ binaries: nothing to extract

  • 35–50 MB

    Typical minimal stripped JRE assembled with jlink and jdeps for a JVM workload

  • 1.0 core

    What "10%" CPU resolves to on a 10-core host; 0.5 core on a 5-core host

  • 2.4 GB

    What "10%" memory resolves to on a 24 GB host

How to read these figures

Conditions matter.

  • Variants

    The core supervisor carries integrity verification, sandboxing, capping, and every exit event except message brokers and the inbound webhook. The extended supervisor adds Kafka, MQTT, NATS, Redis, the webhook listener, the auto-scaler, and the load balancer. A manifest that uses none of those always gets core.

  • Warm and cold

    Interpreted and VM workloads extract their runtime and application once into a read-only, content-addressed cache. Later starts reuse the verified cache; the cold figure covers that first extraction.

  • Kernel enforcement

    Cap accuracy is stated for kernel-enforced strict caps: cgroups v2 on Linux and Job Objects on Windows. Where a supervisor governor enforces the cap instead, its sampling tolerance applies.

Figures from the Executor’s product specification.

See it on your own workload.

Early access is open on request. Tell us the runtime, the platform, and the limits you need at hello@openeng.ai.

Request early accessSee downloads