Understanding Elixir/Phoenix performance

Must see performance in real world .

If you want serving to Over 300K request per second in a single Machine, and this serving is real-time Searching or transaction processing with Database

Elixir
Phoenix
Mnesia ( in-memory, extermely Fast DB )

Is single Solution in The world

Correcting my own post: I realized I was technically incorrect in the sense that EEx is not using IO data and does not support it out of the box, but the Phoenix.HTML EEx engine implements it (sorry for the confusion). Also I should have included this other interesting post on the topic.

I think it hasn’t come up in this thread yet, but part of why it is so good with IO is that Elixir (Erlang) can avoid wasting a lot of CPU and RAM by avoiding doing expensive string concatenations in the first place (which is a very common need for web servers). The ecosystem (e.g. EEx, Phoenix…) is heavily relying on IO data instead of simple strings/binaries, which allows some critical parts like templating to be blazing fast and memory efficient. Although quite technical, the Template of Doom article is definitely worth reading.

Nice !

Now what if we spawn a different process for working over each directory and then collected the result, after all of them are done, something like the async_stream/3 function of the Task module might help. This although not a fair comparison with other languages, but might lead to huge performance benefits.

Yeah, we all have to resort to such hacks every now and then I am not objecting to that too much. It’s just that for the 6 years I worked with RoR this has been the rule and not the exception and at one point you start asking yourself “isn’t there a better way?”.

Turns out, there is – Elixir.

I meant to mention that in my first post here, but spaced and forgot it. ActiveRecord is incredibly heavyweight. In fact, I’ve benchmarked a JSON API that returns a lot of detail records spending something like 99% of time in AR. Simply wrap the query in PG so that it returns JSON directly, then have RoR fetch and return that 1-col 1-row result directly, POOF! a 10x speedup

I don’t see this as being relevant at all for any comparison between any two languages and/or frameworks? Sorry if I misunderstood, you were probably making a bigger point.

Because, it turns out, Elixir is not magic per se. It requires craftsmanship and playing to its strengths (which is actually very easy and I get frustrated when people treat Elixir as if it’s a mind-reader or Skynet-level general AI that will write their programs for them). But then again, needing craftsmanship skills applies to all technologies. Golang is derided in many programming circles yet the professional Golang devs can make wonders with it, both in terms of reliability and speed.

(EDIT: Still though, just by writing idiomatic Elixir – which isn’t hard and is times easier compared to Go or Rust – the average response time of my Phoenix apps is anywhere between 5x to 120x quicker than similar Rails or PHP or Python apps.)

Yep, agreed! Many of us are acutely aware of the strengths and weaknesses of Elixir (or any other tech we use, for that matter). I have factually and measurably observed that in 99% of my projects the app is waiting on a network or disk. However, Rails’ ActiveRecord wastes a lot of time serializing data from/to the DB while Ecto doesn’t. Additionally, outside of Rails and Laravel I didn’t hear about many frameworks that actually help you get productive quickly (maybe Rocket in Rust, still haven’t tried it but looks promising).

So for most webapps work Elixir clearly wins – in my eyes at least, because it can juggle a metric ton of I/O and CPU work without lagging or putting OS process pools in your face (as most of Ruby’s production servers force you to). Hosting costs are smaller as well, and things break much, much less frequently.

As usual, it’s about tradeoffs. If somebody finds themselves angry at the speed of a dynamic language then, well, obviously it’s time to learn C, C++, Go or Rust.

There are definitely cases where Ruby will outperform Elixir. For example, Ruby’s compact is implemented in C, while in Elixir we have to iterate a linked list in Elixir code. Ruby will inevitably work faster here (though Elixir will have some other benefits, such as non-blocking code).

Another thing going for Ruby’s performance is mutability. Yes, mutability is usually bad, and even though I’ve spent more than half of my programming life happily working with mutable data, I agree that immutable is a saner default in most cases. Regardless, there are occasional scenarios where mutability will do wonders for performance.

So I wouldn’t generalize that either is faster, and TBH it usually doesn’t matter. As I like to say (and I already said it here), if proper algorithmical and technical optimizations are done, the differences between any two languages frequently become irrelevant in practice. At least that’s my own limited experience. If the performance is still not good enough and we want to squeeze out every nanosecond, than neither Ruby nor Elixir are likely good choices, and hence the comparisons of their performances is IMO usually not very interesting or useful

Well, my numbers come from comparing carefully-designed comparables, with the db co-located on the machine and accessed via domain socket

I wouldn’t even say that is why people are always arguing over performance.

Real life example, we deployed an App last week, a rewrite of a Ruby (Sinatra) app, in Phoenix w/o assets etc (pure JSON API). We noticed that response times were about 150ms slower than with the Sinatra app.
After further investigation, it turns out the apps compare very different on localhost. Phoenix would be much faster on localhost, with differences as big as Phoenix returning in 3ms and Sinatra in 80ms, but in other instances Sinatra being faster. Both in development mode, mind you.
My best guess would be GC, DB connections being reestablished, maybe some caching etc kicking in at different times.

Further investigation turned out that the delay on the production server was a pretty consistent 80ms times X. Guess what, production app was slower because of the distance between app server to database server, meaning that a database query had to go from Singapore to the US based DB server, then back, with every database query. The old server was in the US, so there was no reasonable speed comparison.

Network connection is real, and in my experience usually a huge factor in how fast/snappy a web app can be. 120ms from Japan to US West coast is considered fast, do that 5 times, and there goes half a second. It’s usually a much bigger factor than the (lets say) 100ms Elixir could give you over Ruby.

Even if Elixir was slower than Ruby, it would have an easier time spawning new processes over Ruby (especially Rails) instantiating new instances, but you would not notice until you hit a certain concurrency level.

Languages have their weaknesses. PHP is the grumpy Grandpa shouting at clouds. C is the fastest way into the next wall - like a racing car with no breaks. Ruby is the nicest way to shoot yourself in the knee in a shiny way. Elixir is the worst way of improving speed coming from Ruby - “I built this boat exactly as I did my car, why does it not go fast!”. Go is Google.