Hacker News Reader

Comment by udfalkso | Hacker News Reader

I recently rewrote an (admittedly old and stale) django app from the ground up with Elixir/Phoenix. The website gets quite a bit of traffic.

I went from an elaborate multi-tier caching setup, with varnish and memcache, to a ZERO caching setup. The amount of complexity reduced by doing this is huge.

The Elixir app hits the postgres db for nearly every request and I'm getting average response times around 45ms. Quite a bit of that is database wait time. It's super stable and efficient. And I'm running it on a dirt cheap, tiny node in the cloud, where before I needed two small EC2 instances to keep up with peak loads.

Also, now that I've gotten the hang of it I think it's actually more efficient with regards to development than either Django or Rails.

Here are the google crawler response times directly before/after the switch to Phoenix: http://imgur.com/a/FASyJ

View on HN

You and blatyo are convincing me. :-) I really appreciate your openness in sharing these stats. I don't need to serve 2 million concurrent websockets. But I need to render HTML/JSON based on some database queries, under moderate traffic, and I'd like to get it under 200ms without trying so hard.

I mostly agree with DHH that response time is dominated by database queries and Rails is "fast enough". Most problems you can fix by improving your query patterns or doing some SQL tuning. And yet . . . Rails is still awfully slow! Most companies don't have time for Russian-doll caching, let alone making the designers consider that at design time. I would love to use something as effortless as Rails that still gave me snappy performance well into the app's maturity.

I'm fairly confident Elixir can do that, but it's hard to look at these benchmarks and come on HN and hear the Elixir folks saying, "Just trust me." There is a strong temptation to walk away thinking it just doesn't live up to the hype. So having some hard numbers is a great reassurance. Thank you!

One note on database time. If you're loading multiple related records, Ecto is able to do some of those requests concurrently. For example, if you get a user and their posts and comments, the fetch of user happens, and then posts and comments can be fetched concurrently.

Also, when I used rails, quite a bit of time was spent wrapping the data into active record objects, whereas Ecto returns simple data structures, which seems to be much faster.

The performance aspect also makes a huge difference in development. The application boots fast and the live reloading experience is rewarding. Having a 100 test cases that hit your endpoint+database running in less than a second is pure joy.

Yes. Tests run so quickly!

Urg, I'm so sick of waiting for rails to boot up. It takes like 30-45 seconds at work...

I can't stress how important that is. We have about 1.5k tests in our Phoenix app and they almost all hit the database - they run in 30 seconds. I compare this to a Rails app where 1k tests run 8 minutes. Having a fast test suite makes development so much easier and makes you rely more on tests.

Reply on news.ycombinator.com