AstonJ
Which webserver do you use?
We had a thread here recently that mentioned webservers in PHP, and it got me curious about the options in the BEAM world and what everyone is using. Which webservers do you use or plan to use in your apps? 
You can select as many options as you like:
- Ace
- Bandit
- Chatterbox
- Cowboy
- Elli
- Erlang’s built in inets/httpd
- Mist
- Mochiweb
- Yaws
- Other - please say in thread!
Ace (Elixir)
HTTP web server and client, supports http1 and http2.
https://github.com/CrowdHailer/Ace
Bandit (Elixir)
Bandit is an HTTP server for Plug and Sock apps.
https://github.com/mtrudel/bandit
Chatterbox (Erlang)
HTTP/2 Server for Erlang.
https://github.com/joedevivo/chatterbox
Cowboy (Erlang)
Small, fast, modern HTTP server for Erlang/OTP.
https://github.com/ninenines/cowboy
Elli (Erlang)
Simple, robust and performant Erlang web server.
https://github.com/elli-lib/elli
Erlang’s built in inets/httpd
The HTTP server, also referred to as httpd, handles HTTP requests as described in RFC 2616 with a few exceptions, such as gateway and proxy functionality. The server supports IPv6 as long as the underlying mechanisms also do so.
Mist (Gleam)
A (hopefully) nice, pure Gleam web server.
https://github.com/rawhat/mist
MochiWeb (Erlang)
MochiWeb is an Erlang library for building lightweight HTTP servers.
https://github.com/mochi/mochiweb
Yaws (Erlang)
Yaws webserver
Trending in Polls
Other Trending Topics
Latest on Elixir Forum
Sponsor Spotlight
Error tracking, logs, APM, uptime and cron monitoring in one dev-friendly platform. Find and fix problems before your users notice.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #elixirconf-us
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #metaprogramming
- #hex
- #performance
Our Sponsors
Build Elixir applications with speed and confidence.
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.
Bringing learning, work and compliance together since 1987.
Enabling companies to succeed by building software people love.
The deployment platform built for Elixir: PaaS ease, VPS control.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
First 10 of 16 Posts
AstonJ
Glad you selected Elli @Tristan! Not sure where I heard it now but I’m sure I heard someone say it is one of the most (if not the most) performant Erlang web servers around (think it might have be @lpil on EFS).
Do you know if there’s a Plug adapter for it? If not do you know if anyone from the Elli team are planning one?
Wonder if anyone has benchmarked all the above? Wonder how that’d pan out?
lpil
Great idea, I’d love to see some benchmarks of all of them.
We have some slightly out-of-date ones for some of the above here.
Mist came out fastest of the BEAM servers, and could sometimes beat Go depending on request body size.
One thing that really surprised me was how badly Cowboy handled request bodies. JavaScript was beating it as soon as there was a reasonable amount of data to read!
tristan
There was a Plug but I don’t think it was ever updated for the last major release of Plug.
My understanding is it won’t work as a Plug anymore because it works different from Cowboy. I vaguely recall looking once, not too deeply, and think it was technically possible but would be a hack.
It also is “fast” because it isn’t completely general purpose – it only supports bodies up to a staticly defined size and requires a plugin to include the datetime in the response, things like that.
Other reason it is fast is it uses the builtin Erlang http parser (C code). But Cowboy replaced this with cowlib for a reason, scaling. cowlib will scale up on cores and keep better latency as concurrent requests go up.
tristan
I’d expect to see similar numbers in a benchmark for Bandit and Elli since they both use Erlang’s http parser – which also means Bandit will have the same scaling issue Cowboy hit years ago that resulted in cowlib being created.
But for many many use cases Elli (or Bandit I suppose) work great
lpil
I was under the impression that Bandit does not use the Erlang http parser, and I couldn’t find it being used in the source code. Are you sure it does? I might have been looking in the wrong place.
tristan
It uses
decode_packetwith typehttpas far as I can tell bandit/lib/bandit/http1/adapter.ex at be794eb707acc91fd864a5d479e4258af10fba58 · mtrudel/bandit · GitHublpil
Ah yes! Thanks!
mtrudel
Bandit author here. Late to the party, but a couple of things:
I’ve looked for historical evidence of decode_packet’s supposed scalability issues but I can’t seem to find anything. Can you point me at some references?
Performance numbers in (synthetic) benchmarks suggest quite the opposite regarding the scalability of cowlib vs. decode_packet. When I was building out GitHub - mtrudel/network_benchmark · GitHub I had to give up on higher concurrency tests as I was unable to get Cowboy to complete them without massive error counts, whereas Bandit hummed along just fine (and indeed grew the performance gap even more on higher concurrency tests).
m.
tristan
It recall it was described by Loic on the Erlang mailing list. A user was hitting this issue that resulted in the creation of cowlib.Its probably like a decade ago at this point, but should be online in the archives.
This was before cowboy was supporting HTTP 2 and maybe there are some issues in that. Could try a benchmark against cowboy 1 to see what happens.
mtrudel
The only references I can find specifically to decode_packet being replaced by cowlib dates back to 2013: https://groups.google.com/g/erlang-programming/c/C9OYrllYkpI/m/DeKOVx3rqEAJ
Some perf assertions also from that era: https://groups.google.com/g/erlang-programming/c/tJnDTcgb9L8/m/zd2fpAnCIyYJ
Considering the vintage of those assertions (R16-era), I don’t think they’re terribly relevant any longer, at least not without being corroborated by more contemporary comparisons. This proverbial ‘best before’ date is even more apparent given that benchmarks done both by me and Rawhat (GitHub - rawhat/http-benchmarks: benchmarks for mist, and other webservers · GitHub) indicate that Cowboy’s performance hasn’t kept up.
The 0.6 release train of Bandit is going to be focused entirely on observability, performance and reproducible benchmarking. I expect to get an additional 20% or so perf gains out of Bandit based on this work, which should make it the fastest game in OTP town by a pretty significant measure. Expect work to start late 2022.
m.