mmmrrr
I tested reverse proxying implementations of different technologies on my local development machine and I noticed that the different Elixir Variants I tried add significant (as in: measurable) overhead to the request.
Just as an example, in Haskell I used http-reverse-proxy which came closest to what I need from a performance for feature ratio.
What I basically want to achieve is: read a session cookie, validate some stuff and inject data into the request and then pass it on (read: proxy authentication).
My Elixir implementation tests used :reverse_proxy_plug and a self grown controller method that just sets of a new Http request:
%HTTPoison.Response{
body: body,
headers: headers,
status_code: status
} = HTTPoison.get!("http://localhost:3000/" <> tail)
After inspecting, :reverse_proxy_plug the implementations seem fairly similar. Of course this approach is naive and it is not suprising that the request will take at least twice the time of the other solutions I tested since I basically have the overhead of two HTTP requests.
So:
- Is there a usable, high performance reverse proxy in Elixir (or Erlang) that I could peek at?
- Is there any chance to use such a solution while keeping all the niceties of Plug and/or Phoenix.Router?
- (meta) If the answer to 1. is no: can someone recommend resources on the basics of reverse proxying?
(Nota bene: the difference in my, admittedly basic, tests was ~16ms vs. ~4ms and only the Elixir solutions showed that behaviour, for the other implementations (esp. Rust and Haskell) the overhead was not measurable in ms)
Related, but old topic:
Where Next?
Trending in Questions
Other Trending Topics
Latest on Elixir Forum
Sponsor Spotlight
Deploy Phoenix to your own VPS with PaaS ease: push-to-deploy, zero downtime, auto SSL, managed Postgres. 14-day free trial at potions.io
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #ai
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #blog-post
- #elixirconf-us
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #elixirconf-eu
- #api
- #forms
- #security
- #metaprogramming
Our Sponsors
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Practical resources that improve the lives of professional developers.
Bringing learning, work and compliance together since 1987.
**Building the future of software with AI, trust, and human connection.**
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 7- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
entone
We use Ambassador as in ingress gateway on k8s. Ambassador has a hook for authentication, every request basically hits a separate service, our elixir service, just cowboy and plug, passing only the headers. We do some basic “auth” and ip checking, all the backing data sits in a local ETS table, maybe moving to persistent terms eventually. We see an average of 100 microseconds overhead per request.
acrolink
I recommend having a look at Nginx and Lua.
mmmrrr
Hey thanks for your answers!
@entone that’s interesting. But if I understand your setup correctly, all the http lifting is done by ambassedor, which calls a service that returns something and then hands the request to the next target in the chain, correct? If so, it is a little different to what I’d like to achieve since I’d want to have cowboy forward the request directly.
@acrolink thanks for the suggestion. I know about OpenResty. I could use it but it increases the complexity of the system significantly. Also it gets harder to decide what to implement where, since you could theoretically completely replace the Elixir stack with it. And then I could also just use Haskell, Go, Rust, etc. and relearn new framework semantics from scratch.
So what I’m after is more of a “what is Nginx doing that makes it so efficient to use as a reverse proxy and how can we emulate that behavior in Elixir”.
(And hopefully: here is how Mr./Mrs. Niceperson has done it in the past in Erlang/Elixir
)
entone
Yeah, that makes sense. But there’s no reason you can’t get really low latency. But as soon as you start reaching out to external services you’re at the mercy of the network and downstream services. Keep as much local as possible. Persistent terms and ets are your friends
It might also be worth looking at using something like Mint to manage the downstream/proxy connections. It’s process-less, so could save you a bit of overhead and use the same incoming request process to handle the proxy connection.
Are you serializing/deserializing anything at the proxy level? Other than headers?
mmmrrr
I don’t think I need to process more than the headers…
Mint looks really promising. I’ll check out if using it helps in my situation. But
use the same incoming request process to handle the proxy connectionsounds like the exact thing I want to achieve.ityonemo
Definitely listening to this space. There’s a place in my deployment where I’ll need to proxy a one-way encrypted https inbound connection to a two-way encrypted https connection. I can do this with nginx but I’m a little bit scared about reloading nginx configs when I need to dynamically add a new route, (Maybe that’s silly). I know it should be possible in elixir, but am curious as to why or why not use the BEAM as a reverse proxy.
mmmrrr
So I tried a few more things and it really seems that the best solution is
reverse_proxy_plug(read: the naiive approach of starting a new httpoison request).I would say one could probably achieve better results by utilizing mint, but the amount of work necessary is significant. So what I’ll do is: start with this slow(ish) approach and optimize once this starts to become a real problem in production…
Thanks for all the input, everyone