Skip to content

Performance

Fast evaluations on a small footprint

The edge server answers from memory. In 5-minute load tests it held 4,550 evaluations per second on half a CPU core and 128 MiB, with a median latency of 0.2 ms.

Bar chart of evaluations per second each edge size sustained for 5 minutes, next to its breakpoint: 2,100 on 0.25 CPU, 4,550 on 0.5 CPU, 7,690 on 1 CPU and 19,250 on 2 CPU

Measured results

What one edge server sustains

Each rate held for 5 minutes against 1,000 flags and 10,000 users, with p99 at or under 50 ms and under 1% errors and dropped requests.

0.17–0.27 msMedian latency, every size, 1,000 flags
4,550/sHalf a CPU core and 128 MiB, p99 4.4 ms
19,250/s2 CPU cores and 512 MiB, p99 15.6 ms
~0.06 coresCPU per 1,000 evaluations per second (fitted)
Sustained evaluations per second, latency, CPU and memory for each edge size
Edge limitsEvaluations/sp50p99Edge CPUEdge memory
0.25 CPU, 64 MiB2,1000.24 ms1.0 ms0.15 cores54 MiB
0.25 CPU, 64 MiB, assignment cache 10,0002,6200.21 ms1.3 ms0.16 cores27 MiB
0.5 CPU, 128 MiB4,5500.20 ms4.4 ms0.32 cores83 MiB
1 CPU, 256 MiB7,6900.17 ms1.6 ms0.41 cores95 MiB
2 CPU, 512 MiB19,2500.27 ms15.6 ms1.25 cores120 MiB

Edge CPU is the average used; edge memory is the peak.

Bar chart of p50, p95 and p99 latency per edge size under steady load; p50 stays between 0.17 and 0.27 ms
Latency under steady load. The median stays under 0.3 ms on every size with 1,000 flags.
Scatter plot of edge CPU cores against evaluations per second with a straight-line fit of about 0.06 cores per 1,000 evaluations per second
CPU grows in a straight line with load. The fitted line is about 0.06 cores per 1,000 evaluations per second, across all sizes and 100, 400 and 1,000 flags.
Bar chart of average edge CPU used under steady load against each container CPU limit, from 0.15 of 0.25 cores to 1.25 of 2 cores
CPU used under steady load against each limit.
Bar chart of peak edge memory per size under steady load, from 27 MiB to 120 MiB
Peak memory under steady load stays between 27 and 120 MiB.

How we tested

The test setup

Endpoint
POST /evaluate, one random flag per request, 10 context attributes
Flags and users
1,000 deployed flags (700 boolean, 300 with variants), each with a targeting rule; 10,000 distinct users
Load
k6 at a constant arrival rate, so slow responses do not lower the offered load
Pass criteria
p99 at or under 50 ms, under 1% errors and under 1% dropped requests
Sustained rate
A freshly started edge holds 70% of its breakpoint for 5 minutes. The table shows that rate.
Host
Apple M4 Max with a Docker Desktop VM of 4 CPUs and 7.3 GiB, shared by the edge, backend, PostgreSQL and monitoring
Limits
CPU and memory limits apply to the edge container only

Read with care

What the numbers do not say

  • Each run allowed up to 1% dropped requests. The runs dropped between 0.001% and 0.25%.
  • In these tests the edge delivered at most about 2,000 evaluation events per second. Above 2,000 evaluations per second per edge, some events were dropped, so the dashboards undercount. Serving evaluations is not affected.
  • Breakpoints from 20-second steps are higher than the rates that hold for 5 minutes. The table shows the 5-minute rates.
  • These results come from one host. Your hardware, network and flag rules change them, so test with your own traffic before you size production.

Sizing

Choose an edge size

Pick the smallest size whose tested rate covers your peak traffic per edge server. Each rate was held for 5 minutes at 70% of that size’s breakpoint. Plan on about 0.06 CPU cores per 1,000 evaluations per second, from the fitted line.

Evaluations per second each edge size held in the tests, with p99 at that rate
Edge limitsHeld in tests, per secondp99 at that rateNote
0.25 CPU, 64 MiB2,1001.0 ms2,620 per second with the assignment cache set to 10,000, at 27 MiB. Analytics undercount above about 2,000 per second.
0.5 CPU, 128 MiB4,5504.4 ms
1 CPU, 256 MiB7,6901.6 ms
2 CPU, 512 MiB19,25015.6 msLimited by the test host, not the edge

The assignment cache is set with [cache] assignment_max_capacity in the edge configuration, or the EDGE_CACHE__ASSIGNMENT_MAX_CAPACITY environment variable. No size held more than 19,250 per second per edge in these tests, and setups with several edge servers were not tested.

Why it stays fast

Evaluation is an edge concern

A flag decision should not wait on admin CRUD paths. FluxGate keeps evaluation rules in edge memory, streams backend changes, and flushes analytics without blocking the response path.

Cached state

Initial snapshots and incremental updates keep edge nodes ready.

Deterministic logic

Bucketing, priority, and variants resolve predictably.

Build with ForgeOps LABS

Need feature flag delivery, platform tooling, or rollout automation?

FluxGate shows the kind of end-to-end software ForgeOps LABS builds: backend, UI, infrastructure, integration, and operational workflows.