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:
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.
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)
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.
@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 )
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?
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.
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…