Which webserver do you use?

Wikis, Polls & Dev Envs Polls
, , , , , , , , ,
1

We had a thread on EF 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? :003:

You can select as many options as you like:

Which webserver/s do you use or plan to use? (Select as many as you like)
  • Ace
  • Bandit
  • Chatterbox
  • Cowboy
  • Elli
  • Erlang’s built in inets/httpd
  • Mist
  • MochiWeb
  • Yaws
  • Other - please say in thread!
0 voters

Ace (Elixir)

HTTP web server and client, supports http1 and http2.

Bandit (Elixir)

Bandit is an HTTP server for Plug and Sock apps.

Chatterbox (Erlang)

HTTP/2 Server for Erlang.

Cowboy (Erlang)

Small, fast, modern HTTP server for Erlang/OTP.

Elli (Erlang)

Simple, robust and performant Erlang web server.

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.

MochiWeb (Erlang)

MochiWeb is an Erlang library for building lightweight HTTP servers.

Yaws (Erlang)

Yaws webserver

2

For those of you using Erlang’s httpd (looking at you @mmin and @kuna.prime :lol:) how are you finding it? Do you feel you are missing anything from any of the others? Do you find it a more performant option? More/less hassle to use?

1 Like
3

Well, first of all, it’s part of OTP so I prefer this over the others (as long as it fits my needs). I find it pretty simple to use, but there should be some upgrades for sure.

I’d like to point this out: Httpd connection header bug
This got me into troubles sometimes, especially with “connection” header. I’d like to contribute to this, but I’d need some more experienced Erlangers to guide me.

Solution could be that header value is either string or list of strings. But that also implies some changes on the whole app. What do you think? :smiley:

1 Like
4

Mist! It has a few rough edges but all Gleam and it’s a ton faster than Cowboy :grin:

2 Likes
6

That’s awesome, thanks for sharing your experience :smiley:

I see that @starbelly and @max-au have stated they use it too (and I wonder if Max selecting it means WhatsApp are using?)

I’m personally interested in hearing when you might want one of the other options over it :blush:

I wonder if we need a ‘Contributing & Mentorship’ section like we have on EF here as well - I’ll get it set up on the weekend, perhaps if you post in there someone might be able to help :003:

That’s awesome Louis, have you got any benchmarks you can share? :smiley:

1 Like
7

httpd seems like very light weight and low level server lib for embedding http capability in applications that needs that for secondary purpose. Compared with yaws that I also use in embedded mode it is lacking a lot of features but “workflow” or middleware style that httpd offers lends itself to composability and flexibility.

Regarding performance we still didn’t do proper testing so I don’t have any hard data now but will gladly share some when we do stress tests and comparisons as we intend to do.

And as @mmin already said being part of OTP reduces our dependency area which, at least for me is great value.

1 Like
8

How Mist can be faster than Cowboy? Any benchmark to sustain this claim?

2 Likes
9

There is the benchmark at the end of the README.

1 Like
10

Well… I’m not saying that this statement is wrong, but the benchmarks that support the claim are way too few and too simple to allow for such a very general statement to be made IMO.
It’s like saying that walking is generally faster than driving because walking over to your neighbors’ house is faster than getting into your car, driving over and getting out of your car again.

I’m willing to be convinced, though, but I request more evidence :stuck_out_tongue_winking_eye:

5 Likes
11

Interesting. Does Gleam generate BEAM files directly or does it generate Erlang source code (.erl + .hrl) which is then compiled to BEAM?

1 Like
12

My understanding is that it generates Erlang source code.

3 Likes
13

If you want more evidence of Cowboy’s performance you could also check out Bandit’s benchmarks, they don’t include Mist but they do have the same results for Bandit vs Cowboy.

Cowboy uses 2 processes to handle a request so all data has to be copied from one to the other, which is expensive. Mist, Bandit, Ace and Elli all use 1 so there is no extra copying.

I’m personally quite happy about this discovery! It means we can level up the entire ecosystem with a new generation of BEAM webservers, and there’s opportunity to improve other aspects of Cowboy’s design too.

2 Likes
14

During last 20 years that I’m in software development, I see cycle by cycle:

we are going to reimplement this simple task with a new lightweight approach

after 2 years

seems, that we have reimplemented previous solution, because we need to handle all corner cases and achieve the same stability of work.

So the question is: does Mist provides the same level of preemptiveness, functionality and memory consumption as cowboy does? Because if no, then I do not understand how can be peformance compared.

2 Likes
15

I don’t think there’s anything overly novel in Bandit or Mist, Elli has been using a similar design for over a decade and has been happily used in production by many during this time. Cowboy just uses processes in an inefficient way that results in a good amount of extra copying.

RE correctness, Bandit actually scores better in HTTP2 compliance tests and would error less frequently during benchmarks than Cowboy, so I think there’s room for Cowboy to improve there too.

I think we’ve been a Cowboy monoculture for too long and we’ve stopped innovating in this area as a result. Competition is good for the ecosystem, and there’s more to gain here. Very exciting! :purple_heart:

2 Likes
16

To be fair I can see both sides - there seems to be an unwritten law that all projects end up a little more bloated or slower due to feature-creep or once you account for all or most eventualities, but also that with advancements in our understanding and use-cases new innovative approaches can sometimes yield fantastic (or sometimes even phenomenal) results.

I think it’s awesome that we’ve got some solid, stable choices - as well as cool fresh ones emerging :003:

2 Likes
17

Maybe you got me wrong here :sweat_smile: I’m definitely not saying or even suggesting that the numbers in the benchmark that compares Mist with the alternatives are wrong/faked/whatever :wink:

What I object to is that your statement “Mist is a ton faster than Cowboy” conveys the impression that, no matter what you do, it will be faster if you use Mist/Bandit/Elli/etc instead of Cowboy. That may or may not be the case, however the benchmarks do not prove that, they only compare simple request/response times. What I really asked for were not more benchmarks for request/response times but benchmarks that compare more than just that.

To stay with my previous analogy… so we got the idea that walking is faster than driving because walking over to your neighbors house was faster than getting in your car, driving over, and getting out of your car again. And when your neighbor walked vs drove over to his neighbor, it was pretty much the same. Proof! :smiley_cat:
But unless you try out the same with a destination in the next city, chances are that you are in for a surprise later. Know what I mean? :wink:

I agree and disagree :smile_cat: Having choices is good, yes. One-size-fits-all often just doesn’t work.

OTOH, in this case the alternatives are in no way drop-in replacements for each other, things that you can just swap out. You will have to make a pretty definitive choice early in your project.

To make an informed choice, mere comparison of performances is not enough. What about features? Limitations? Maintainability? Robustness? Support? Etc etc?
Performance is of course something to consider, but it may not be at the top of your list. I mean, if you can have speed, who would say no to that, but if there is some critical feature missing in the fast thingie that the slower thingie has, that may be more important.

tl;dr: What I’m missing is an extensive, unbiased, up-to-date (and maintained) comparison of the choices, not just in speed but also in features :slightly_frowning_face:

Polls like this don’t help much in that regard, I’m afraid (sorry @AstonJ :sweat_smile:)
But how about that: All the maintainers of the mentioned projects are in this forum? How about you stick your heads together and compile such a list, to help people like me make the best of choices for their specific use cases? :hugs:

3 Likes
18

I think this might be the case! I’ve not managed to find a situation in which Cowboy is faster, and Bandit has the same featureset as Cowboy but errors less frequently. They’re all better OTP citizens imo as well, being library applications rather than mutable application applications, and I find the code in them much easier to understand than in Cowboy. I think overall Bandit is likely the best option available to us today as a web server generally and as a stand-in for Cowboy specifically.

Are there other benchmarks you’d want to see beyond what the Cowboy and Mist folks have been doing?

1 Like
19

I think this is more about how does the server you’re using fit in with the rest of your stack. When it comes to using a webserver in Erlang Cowboy won out over other options and has been the leading option for quite some time. This being an Erlang forum I expect the majority of respondents for this poll to be working primarily with Erlang, not Elixir, Gleam or any other BEAM lang.

It would be fantastic if Bandit were written in Erlang with a thin Elixir API layer so it could easily be used in both languages (like a few other projects out there), but unfortunately it’s not.

4 Likes
20

Show me everything you have! :grin:

But seriously, I’m not trying to advocate for anything here, though it might look like it. I guess it is just some reflex that kicks in and makes me doubt when the provided evidence covers only a small part of a big claim (and let’s be honest, “Superior to Cowboy!” is a claim that needs some living up to :wink:). I see it as a nice counterbalance to the WYSIATI effect on my behalf (“What You See Is All There Is”, coined by Daniel Kahneman I think, ie the tendency to assume that what you are shown is all there is to see).

That is actually due to the nature of Ranch, Cowboy is just a set of handlers (ranch_protocols) in that regard, but yes :wink: Ranch can also be run in “Embedded Mode” as part of an applications’ supervision tree, with some restrictions.

21

But they can still be super useful and interesting Maria :blush: and the conversations that ensue (like the one in this thread) can be informative and educational :smiley: They’re also great for:

  • Getting an idea of what different options are available
  • Seeing which ones are currently most used and/or which ones might be up and coming
  • Allowing a discussion to take place that hopefully encourages innovation (even if helping keep older solutions from becoming stagnant or complacent)

I wasn’t even aware of Chatterbox and Erlang’s built in httpd until @tsloughter mentioned it for instance, and I was also pleased to see the interest in some of the other options as it shows there is a healthy choice available. Of course the conversation has been super interesting as well :003:

This is probably a little bit easier in Elixir because most people will use them via Plug, and so each web server would require a Plug adapter.

Plug is:

  1. A specification for composing web applications with functions
  2. Connection adapters for different web servers in the Erlang VM
2 Likes