Performance Characteristics

Measured and estimated performance characteristics for TameFlare components. All numbers are from local testing on commodity hardware (4-core CPU, 16 GB RAM, SSD).

Note
TameFlare has not been independently benchmarked. These numbers are internal measurements and should be validated in your environment.

Proxy latency (Gateway)

The gateway adds latency to every proxied request. This is the overhead TameFlare introduces on top of the upstream API's response time.

| Metric | HTTP | HTTPS (with TLS interception) | |---|---|---| | p50 | ~1-2ms | ~3-5ms | | p95 | ~3-5ms | ~8-12ms | | p99 | ~8-15ms | ~15-25ms |

What contributes to latency

| Step | Time | Notes | |---|---|---| | Connector lookup (domain → connector) | <0.1ms | In-memory map | | Action parsing (HTTP → structured action) | ~0.5-1ms | Regex matching on URL/method | | Permission check (SQLite lookup) | ~0.5-2ms | Cached after first lookup | | Credential injection | <0.1ms | In-memory vault | | TLS termination + re-encryption | ~2-5ms | Per-domain cert generation cached after first request | | Traffic log write (SQLite) | ~0.5-1ms | Async, non-blocking |

First request to a new domain

The first HTTPS request to a new domain takes ~20-50ms extra because the gateway generates a TLS certificate for that domain (signed by your local CA). Subsequent requests to the same domain reuse the cached certificate.

Policy evaluation (Control plane)

For SDK advisory mode (Mode B), the control plane evaluates policies:

| Policies | Rules per policy | Evaluation time | |---|---|---| | 1-5 | 1-10 | <1ms | | 10-20 | 5-20 | 1-3ms | | 50+ | 10+ | 5-15ms |

Policy evaluation is O(policies × rules × conditions) — linear, not exponential. There is no recursion or backtracking.

Gateway resource usage

| Metric | Idle | Under load (100 req/s) | |---|---|---| | RAM | ~20-30 MB | ~40-80 MB | | CPU | <1% | ~5-15% (4-core) | | Goroutines | ~10 | ~200-500 | | Open file descriptors | ~20 | ~300-500 |

The gateway is a single Go binary with no external dependencies. Memory usage scales linearly with concurrent connections.

Control plane resource usage

| Metric | Idle | Under load | |---|---|---| | RAM | ~200-300 MB | ~300-500 MB | | CPU | <1% | ~10-20% (4-core) |

The control plane is a Next.js application. Most of the RAM is the Node.js runtime + React server components. Dashboard pages are server-rendered.

SQLite performance

| Operation | Throughput | Notes | |---|---|---| | Traffic log insert | ~5,000-10,000/s | WAL mode, async writes | | Audit event insert | ~2,000-5,000/s | Synchronous (append-only) | | Permission lookup | ~10,000-50,000/s | Simple indexed query | | Policy query | ~5,000-20,000/s | Full table scan (small tables) |

SQLite is single-writer. Write throughput is limited by disk I/O. For most TameFlare deployments (< 1,000 req/s), SQLite is not the bottleneck.

Cold start

| Component | Time | Notes | |---|---|---| | Gateway binary | ~50-200ms | Binary startup + SQLite + vault decrypt + CA load | | Control plane (production) | ~500ms-1s | Next.js server start + DB connection | | Control plane (development) | ~2-5s | Next.js dev server with hot reload | | First proxied request | +10-50ms | Connector init + first TLS cert generation |

Scaling limits

| Dimension | Practical limit | Bottleneck | |---|---|---| | Concurrent agents | ~50-100 per gateway | Port allocation (one port per agent) | | Requests per second | ~500-1,000 per gateway | SQLite write throughput for traffic logs | | Policies | ~100-200 | Evaluation time grows linearly | | Audit events | ~10M rows before queries slow | SQLite full-table scan. Use AUDIT_RETENTION_DAYS to prune. | | Traffic log size | ~1 GB per ~5M requests | Disk space. Prune via maintenance endpoint. |

For higher throughput, run multiple gateway instances on separate hosts (each with its own SQLite). The control plane can be shared via Turso (cloud SQLite).

Next steps