150 million rules. ~70-microsecond decisions.

01 Why this matters to the business

For a CTO, the question behind a web gateway is operational risk: will the box that inspects every outbound request become the bottleneck — or the single point of failure — as policy grows? For a CSO, it is coverage and control: can we enforce the full breadth of threat-intel and category data we are paying for, on our own infrastructure, without shipping every lookup to a vendor cloud?

Most products force a trade-off. Cloud-rated filtering services keep the big database off-box but add a network round-trip — and an external dependency — to decisions they cannot answer from cache. On-box engines that try to hold large custom lists tend to slow down or run out of memory as the lists grow. EnforceGate vX is built to avoid both: the entire policy lives in memory on your node, and the match structure is designed so that lookup time does not grow with rule count.

02 The headline: 3× the rules, same speed

The result that matters is not raw capacity — it is that per-decision latency stays flat as the policy grows. Tripling the rule set from 50 million to 150 million leaves the common-case decision time essentially unchanged at roughly 0.23 µs in high-density mode. Capacity scales; latency does not.

To be precise, this ~0.2 µs is the rule-match step — the in-memory work of testing one URL against the loaded policy ("common case" = a destination not on any blocklist, the dominant pattern). It is the part that scales to 150 million rules without slowing down. But it is not the latency a request actually pays; for that you have to measure the whole decision — which is the next section.

03 The decision an operator actually pays for

The match step is the cheap part. A real request pays for the work around it: the connector reads the request, serializes a query and sends it to the engine over the encrypted defendr channel; the engine parses, matches and returns a verdict. That round-trip is the latency EnforceGate adds to a proxied request, and it is the figure you should size capacity against. We measure it directly — driving the shipping connector binary against a live engine under a concurrency sweep.

Measured end to end against a live engine, a single node sustains ~68,000 policy decisions per second, saturating at around 8 concurrent requests, with a median of ~70 µs and every percentile — up to p99.9 — staying under ~280 µs even at 64-way load.

04 A 150M-rule policy fits a modest server

High-density mode runs 150 million rules in under 5 GiB of steady-state memory — about 33 bytes per rule — and memory grows linearly and predictably with rule count. Capacity planning is a simple multiplication, with no cliffs or sudden jumps. The whole policy loads well within a 16 GiB budget, comfortably inside a single mid-range VM or appliance.

Provisioning a fresh 150M-rule policy takes about two minutes to compile offline and one to two minutes for the engine to cold-load on start or deploy — so a deployment that runs on a small server also provisions within minutes.

05 How the approach compares

The table below contrasts EnforceGate vX with the web-gateway architectures buyers most often weigh it against: cloud-rated secure web gateways (the cloud-delivered URL-filtering services), and the open-source proxy add-ons that teams once assembled themselves — chief among them SquidGuard, a legacy project that has been long dead (its last release was in 2009). The comparison is architectural — it reflects how each approach is designed to work, not a head-to-head lab benchmark of any specific product.

06 How it was measured

So the numbers can be trusted and reproduced, the benchmark exercises the complete production path — author, compile, cold-load, enforce, and decide end to end — using the shipping parser, storage layer, match engine and connector, not a model or simplified stand-in.

• Real product code. The same components that ship in the product produced these figures.
• Realistic corpus. Rules are unique, realistically-shaped domain names, generated deterministically so any run is reproducible.
• Honest memory measurement. Memory is read from the operating system's own accounting of the engine process (resident set size), capturing both steady state and the transient load peak.
• Correctness-gated. Before any figure is accepted, the run verifies that a large random sample of rules resolves correctly and that non-rule traffic correctly does not match. A failure invalidates the run.
• Single node, single core for the match step. Match latencies come from one commodity x86-64 system (specified below) and are single-threaded, so multi-core nodes match proportionally more.
• End-to-end via the real binaries. The decision round-trip figures come from a separate harness that spawns N real connector processes against a live engine over the encrypted defendr wire (TLS on), times each request's full round-trip and reports throughput plus latency percentiles per concurrency level. Warm-up is excluded, so the numbers are steady-state.

Test system

For full transparency, the figures in this paper were produced on a single, off-the-shelf commodity x86-64 machine — no specialised accelerators, no exotic hardware:

The 150-million-rule policy uses under 5 GiB in high-density mode, so memory capacity was never the limiting factor on this host — the headroom simply confirms the footprint figures. Lookup latencies reflect a single core; a production node serving traffic across all available cores scales throughput proportionally.

07 Scope & caveats

• Figures are lab-measured on a single commodity machine (see Test system) under controlled conditions; production numbers vary with hardware, traffic mix and co-located workloads.
• Two distinct latencies are reported, deliberately. The ~0.2 µs figure is the in-memory rule-match step; the ~70 µs / ~68,000-per-second figures are the end-to-end decision — the full connector⇄engine round-trip EnforceGate adds to a request. Quote the end-to-end number for request-latency and throughput claims; the match number is a component of it, not a substitute.
• The end-to-end figure is EnforceGate's own overhead — it does not include the client TLS handshake, payload decryption or Squid's processing (OpenSSL / Squid / kernel costs). A full proxy-level (Gbps, wire-to-wire) benchmark is a separate, recommended exercise.
• The "flat latency" result is for the common (permitted) path — the dominant case. Decisions for blocked destinations are also sub-3 µs but do rise modestly with scale.
• "Rules" here are domain-policy entries — the dominant high-volume rule type. Regular-expression URL rules have different, lower-cardinality characteristics and are not the subject of this 150M claim.
• The benchmark measures load, lookup, and the end-to-end decision round-trip under a concurrency sweep; it is not yet a multi-hour production-traffic soak. A sustained-load endurance test is a recommended follow-up before publishing hard SLAs.