Oninit® Snooper — SQLI Protect Mode: Performance Under Load

What was measured

An open-loop load generator — a real IBM Informix client, not a synthetic mock — drove a fixed request schedule against a real Informix engine at increasing connection counts, run three ways: direct (no proxy), through Snooper in monitor mode, and through Snooper in --protect mode. Reporting percentiles (p50/p99/p99.9/max), not means, because the concern with an inline proxy is tail latency, not the typical case.

The headline result — steady up to 100 connections, then a gap opens

Across most workloads tested, Protect Mode's latency tracks monitor mode's closely at every connection count tried — the two are within noise of each other. One workload is the exception: a heavy, large-payload statement pattern run at 100 and 150 concurrent connections, where Protect Mode's tail pulls noticeably ahead of monitor mode's:

At 150 connections, Protect Mode's p99 is roughly a quarter worse than monitor mode's for this workload. Both configurations are already far worse than the unproxied baseline at this connection count — most of the increase is proxying overhead in general, present with or without protection enabled — but the protect-vs-monitor gap itself is the part attributable to protection.

These numbers come from a modest test system, not dedicated benchmark hardware — the absolute millisecond values will look different on production-scale infrastructure. What should transfer is the shape of the result: flat through 100 connections, then a widening gap.

Why this workload specifically

Snooper's own internal timing shows no difference between Protect Mode and monitor mode in the cost of validating a request or waiting on any internal lock — both are a fraction of a microsecond, even under this load. What does differ, measurably, is how many write operations Protect Mode performs to do the same work: roughly 22% more than monitor mode for this workload.

This follows directly from how Protect Mode is designed: it forwards once per validated request rather than once per network read, which costs more system calls for a write-heavy workload like this one — a deliberate trade-off of the validation guarantee, not an inefficiency. On constrained hardware, the extra system calls under high connection counts are the most plausible source of the tail-latency gap measured here.

Caveats

• Every customer deployment should still start in detect mode. --protect-detect reports exactly what enforcement would have done, including timing, without ever blocking a connection — the supported way to see this workload's actual behavior against your own traffic before enabling enforcement.