---
title: Performance
description: >-
  Super is Proksi on hyper: the core that does most of the work of each request
  (parsing, connection pooling, I/O) is its own, and it costs far less CPU per
  request than Proksi's Pingora.
---
> ## Documentation Index
> Fetch the complete documentation index at: https://docs.page/luizfonseca/super/llms.txt
> Use this file to discover all available pages before exploring further.

Super is [Proksi](https://github.com/luizfonseca/proksi) rebuilt on [hyper](https://hyper.rs) instead of [Cloudflare Pingora](https://github.com/cloudflare/pingora). Most of the work of each request (parsing, connection pooling, I/O) happens in its core, `super_core`, which keeps Pingora's request phases; the routing, plugins, forwarded headers, metrics and logging on top of it are Proksi's.

The core allocates nothing on the hot path where it can, keeps upstream connections per thread (borrowing another thread's idle one when it has none), and by default keeps each connection on the thread that accepted it.

### Compared to nginx and Proksi

All proxies forward plain HTTP and HTTPS requests to the same nginx upstream, with the same certificate (RSA 2048), access logs disabled and keep-alive connections to the upstream. The load comes from [oha](https://github.com/hatoo/oha) with 50 connections, on the same machine.

```bash
# Linux (arm64, 8 CPUs), nginx 1.26.3, medians of 3 alternating rounds
# Threads: worker_threads (Proksi, Super), worker_processes (nginx)
# Memory: the proxy's private memory (without its executable's pages)
```

**1 thread**

| | Requests/s (HTTP / HTTPS) | CPU per request (HTTP / HTTPS) | Latency p99 (HTTP) | Memory (idle → under load) |
| --- | ---: | ---: | ---: | ---: |
| nginx | 112k / 85k | 8.9 / 11.7 µs | 0.68 ms | 7 → 10 MB |
| Proksi | 50k / 41k | 20.1 / 24.6 µs | 1.54 ms | 10 → 17 MB |
| **Super** | 72k / 61k | 14.0 / 16.4 µs | 1.06 ms | 5 → 10 MB |

**4 threads**

| | Requests/s (HTTP / HTTPS) | CPU per request (HTTP / HTTPS) | Latency p99 (HTTP) | Memory (idle → under load) |
| --- | ---: | ---: | ---: | ---: |
| nginx | 412k / 353k | 8.2 / 10.2 µs | 0.35 ms | 22 → 26 MB |
| Proksi | 85k / 80k | 40.1 / 43.5 µs | 1.06 ms | 10 → 20 MB |
| **Super** | 318k / 261k | 12.0 / 14.7 µs | 0.33 ms | 5 → 12 MB |

**Other workloads** (4 threads)

| | nginx | Proksi | Super |
| --- | ---: | ---: | ---: |
| A new connection for each request (HTTP) | 193k req/s | 63k req/s | 140k req/s |
| A new connection for each request (TLS) | 20k req/s | 14k req/s | 16k req/s |
| 1 MB downloads | 10.4 GB/s | 2.6 GB/s | 19.4 GB/s |
| 10 MB downloads | 7.8 GB/s | 2.4 GB/s | 21.0 GB/s |
| 1 MB uploads | 7.0 GB/s | 13.9 GB/s | 23.0 GB/s |
| HTTP/2, 10 connections × 10 streams | 409k req/s | 99k req/s | 336k req/s |

With TLS, most of a new connection's cost is OpenSSL's handshake (RSA, and the post-quantum key exchange Proksi and Super build with).

These numbers come from a single machine, where the proxy, the upstream and the load generator share the same CPUs. Treat them as a comparison, not as the throughput you will get in production.

### Worker threads

By default, each connection stays on the thread that accepted it, which costs far less CPU per request. With `work_stealing = true`, idle threads take over each other's connections instead (Proksi's default):

- Keep the default when Super's threads each get a CPU.
- Turn it on when Super gets less CPU than it has threads (a container with a CPU limit below `worker_threads`, or a machine busy with other work): requests then don't wait for a busy thread.

```hcl
server {
  work_stealing = true
}
```

### Every pull request

Every pull request is benchmarked against `main` on the same GitHub runner (requests per second, latency, CPU per request and peak memory, for plain HTTP and HTTPS). The results are posted as a comment on the pull request, so changes in performance are visible before they are merged. See [repository](/contributing/repository#performance-checks) to run it locally.



### CDN performance

Using the following configuration we can see that Proksi holds its own in regards to performance (a test of Proksi's, before Super).

```hcl
cache {
  enabled = true
  path = "/tmp"
  cache_type = "disk"
}
```

1 minute test using 4000 concurrent clients.

![Results of a 1 minute test with 4000 concurrent clients](/assets/one_minute_test.png)