Aralez: Reverse proxy/ Load balancer

[u/sadoyan]

Hello Folks.

I have create a new Reverse Proxy/ Load Balancer for Linux on Cloudflare's proxy lib : Pingora. The project is till on 0.x.x version, but I'm working on standardizing everything.

It have fantastic proxy performance, even beats nginx in performance/stability tests with many thousands of concurrent connections.

It would be great to have a human review and suggestions .

This is the link for ingress documentation : https://aralez.rs/docs/quickstart/

An the link to main project in GitHUB: https://github.com/sadoyan/aralez

Thanks

[u/CynepMyx]

Read through the docs. Solid feature set for a 0.x: hot reload of upstreams, ACME, active health checks, a built in rate limiter, and Consul/Kubernetes discovery is more than most projects have at this stage. Since you asked for a real review, here is what I would want before putting it in front of production traffic.

Passive health checks. Active probing tells you the backend answers HEAD /health. It does not tell you that the same backend is returning 502 for actual requests, which is the failure mode you meet most often. Ejecting an upstream after N consecutive errors on live traffic, then probing it back, catches things active checks structurally cannot see.

Graceful binary upgrade. Config reload is covered, but what happens when I replace the aralez binary itself? Pingora has zero downtime restart with socket handoff, and if you expose that, it becomes a genuine argument over nginx for anyone who upgrades often.

ACME looks like HTTP-01 only. That means port 80 has to be reachable from the internet and wildcards are off the table. DNS-01 would cover internal services and wildcard certs, which is most of the homelab and internal platform use.

Metrics. Prometheus is mentioned but not documented, and that is what decides whether this is operable. Per upstream latency histograms, response codes and health check state are the minimum needed to alert on it. Without documented metric names nobody can build a dashboard.

On the benchmark: you do document the setup, four machines, Xeon, three nginx upstreams, 800 concurrent users, three workload types, which is more than most projects bother to show. What is missing for reproducibility is the configs themselves: the nginx and traefik files you compared against, and the exact load generator command. "Tuned as much as I could" is the part nobody can verify, and it is the first thing anyone who has tuned nginx will question. Put those three files in a bench/ folder and the numbers stop being arguable.

One more thing worth stating plainly in the README: the access log format. If it can emit combined or JSON, existing log stacks pick it up with no work, and that removes a real migration objection.

[u/sadoyan → u/CynepMyx]

hi u/CynepMyx . Thanks for you time and detailed response. Here are my comments :

Passive health checks. Health checks works exactly as you have described. Connection refused and 5xx responses returned by upstreams, make it dead and no traffic will be forwarded to it. If on next check it will give normal response (from 100 to 499 codes) it will be back on pool.

Graceful binary upgrade. This is supported by PIngora and of course supported by Aralez. Will document the procedure and update. The procedure is almost exactly the same as in Pingora's official documentation here : https://github.com/cloudflare/pingora/blob/main/docs/user_guide/graceful.md Of course I will make some helper scripts to make the procedure more easy.

ACME looks like HTTP-01 only. Yes at this moment only HTTP-01 is supported. Need to do to DNS as well . It's on my road-map. But as there are quite many DNS providers, each of which have it's own API, I'll need time to deal with different APIs.

Metrics. Prometheus. Rewrote documentation to make it looks more informative and nicer . https://aralez.rs/docs/metrics/

On the benchmark. I put all raw results and config files in documentation. https://aralez.rs/docs/perf/

• Raw results: GitHub
• Config files: GitHub

Regarding different log formats, we are working on it . The biggest challenge here is to make robust and structured logging without affecting performance. This is a serious challenge ad logs should be generated on each request, so in 10-20-30k requests per second, this will become a huge performance bottleneck .

[u/CynepMyx → u/sadoyan]

Good, that clears up most of it. The passive behaviour was the one I got wrong: ejecting on refused connections and 5xx is exactly what I meant, it just was not visible in the docs, which is now fixed. The benchmark repo with raw results and configs is the part that changes the conversation, that is what makes the numbers arguable in a good way.

On logging: agreed it is the hard one. Worth looking at how nginx handles it, buffered writes plus a flush interval, so the request path only touches memory. Structured output does not have to be per-request synchronous.

Nice work, and thanks for taking review seriously.